www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/d6898fa3-ce97-4c16-ae96-a1d13d8bf796/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026--1') OR 5*5=25 -- -01) at position 4 (-): Unexpected character

Automatisch erstellt durch n8n

KI-Analyse:

Wurzelursache

Der Stacktrace zeigt, dass der PHP DateMalformedStringException ausgelöst wird, während TYPO3 versucht, einen Zeitstring zu parsen, der vom Benutzer bereitgestellt wird.
Der fehlerhafte String lautet:

2026--1') OR 5*5=25 -- -01)

Dies ist eindeutig kein gültiges Datumsformat (das erwartete Format ist YYYY-MM-DD).
Die Ausnahme tritt auf, weil ein TYPO3-Extension-Code einen unbereinigten, von einem Angreifer bereitgestellten Wert direkt an new \DateTime($userInput) (oder eine ähnliche Datums-Factory) übergibt.

Der Stack zeigt, dass der Fehler während der Anfrageverarbeitung auftritt, also bevor eine Erweiterung den DB-Abfragebau oder die Ergebnis-Rendering-Logik erreicht. Das bedeutet, dass die Extension den Anfrageparameter (in der Regel ein GET/POST-Feld wie date_from, date_to, start, end usw.) frühzeitig liest und versucht, ihn in ein PHP DateTime-Objekt umzuwandeln, ohne die Gültigkeit zu validieren.

Wann immer ein Angreifer einen ungültigen Datumsstring injizieren kann, den die Extension für die Filterung oder Datumsberechnung verwendet, wird die gleiche Ausnahme ausgelöst.

Das kürzlich entdeckte Problem ist eine Unsanitization-Injection (CWE-89 ist SQL, hier ist es ein Problem mit dem Datumsformat), das dazu führt, dass die Extension mit einer PHP-Ausnahme abstürzt – eine klassische Denial-of-Service-Möglichkeit und ein Hinweis darauf, dass die Extension keine Eingabesanitization durchführt.

Konkreter Fix¶

Minimaler Code-Ausschnitt (PHP)¶

/** @var string $userDate */
$parsedDate = \DateTime::createFromFormat('Y-m-d', $userDate);
if ($parsedDate === false) {
    // Protokollieren Sie den ungültigen Versuch
    $this->logger->warning('Ungültige Datumsangabe beim Filtern', ['value' => $userDate]);

    // Standardwert / Filter überspringen
    $parsedDate = new \DateTime(); // oder null, falls der Filter optional ist
}

Oder unter Verwendung der TYPO3 Core-Typen:

$dateRange = \TYPO3\CMS\Core\Type\DateRange::createFromQueryParameter($userDate);
if ($dateRange === null) {
    $this->logger->warning('Ungültige Datumsangabe', ['value' => $userDate]);
    // …Fallback
}

Betroffene TYPO3 Extension (am wahrscheinlichsten)¶

tt_news / news (das beliebte „News“-Extension-Paket, das oft als tx_news bezeichnet wird)

• Die Extension verfügt über eine Liste-/Search-PI, die von / bis-Datumsfilter verwendet, die als GET-Parameter (tx_news[date_from] / tx_news[date_to]) übergeben werden.
• Der Standard-PI-Code ruft new \DateTime($this->settings['date_from']) auf (oder ähnliche Aufrufe), ohne den Wert zu validieren.
• Die Extension wird von Tausenden von Installationen verwendet und entspricht genau der Beschreibung – der Abbruch der Anfrage beim Parsen eines ungültigen Datumswerts.

Warum es zu diesem Stacktrace passt

• Der Fehler tritt vor jeder DB-Abfrage auf, sodass die Anfrage nie das Framework erreicht.
• Der Aufrufpfad (index.php → Application::handle → MiddlewareDispatcher) ist genau das übliche Muster für ein „Typ-3-Plugin“ (tt_news verwendet ein Typ-3-Plugin).
• Der fehlerhafte Datumsstring ist ein typischer SQL-Injektions-Payload, der für einen DateTime-Parser bestimmt ist, was dem bekannten Versuch entspricht, den Datumsfilter zu kapern.

Hinweis – Wenn Sie nicht tt_news verwenden, aber immer noch die gleiche Ausnahme beobachten, überprüfen Sie jedes Extension, das ein Typ-3-Plugin mit einem Datumsfilter enthält (z. B. events, bootstrap_calendar, felog, cal oder jede benutzerdefinierte Extension, die einen date_from/date_to-Parameter verarbeitet). Der gleiche Validierungsfehler wird dort auftreten.

Konfidenzbewertung¶

Fazit (was Sie jetzt tun sollten)¶

1. Identifizieren Sie die Extension – Wenn Sie ein tt_news-Plugin (oder ähnlich) verwenden, ersetzen Sie die rohen new \DateTime()-Aufrufe durch eine Validierung wie oben gezeigt.
2. Wenden Sie den gleichen Validierungsmechanismus überall an, an dem die Extension date_from, date_to, start, end, datetime usw. verarbeitet.
3. Überprüfen Sie jede benutzerdefinierte oder Drittanbieter-Extension, die ähnliche Datumsfilter verwendet – sie können dem gleichen Fehler unterliegen.
4. Fügen Sie Logging für ungültige Versuche hinzu, um die Erkennung zukünftiger Angriffsversuche zu ermöglichen.
5. Testen Sie den Fix mit einem korrekten Datumswert und mit einem bösartigen Payload (dem, das Sie gerade gesehen haben), um sicherzustellen, dass die Anfrage jetzt sauber mit einem sinnvollen Fallback fortfährt, anstatt mit einem DateMalformedStringException abzustürzt.

Wenn Sie eine Beschreibung der speziellen Zeilen der Extension erhalten möchten, die geändert werden müssen, geben Sie einfach den Erweiterungsnamen an, den Sie verwenden (z. B. tt_news oder news), und ich kann Ihnen den genauen Code-Ausschnitt für diesen Extension liefern.