www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/16651a72-3683-40b9-98d8-5b1e63f5f79e/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

---

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache¶

Die Exception entsteht beim Parsen eines Datumsstrings:

(-1 OR 5*5=25-01-01)

Das ist kein gültiges Datum, sondern sieht wie ein SQL-Injection-/Fuzzing-Payload aus, der in einen Kontext gelangt ist, in dem TYPO3/PHP ein Datum erwartet.

Der relevante Teil ist:

-1 OR 5*5=25

Das ist eine typische Boolean-basierte SQL-Injection-Testzeichenfolge. Dahinter wurde scheinbar ein Datum angehängt:

-01-01

TYPO3 versucht diesen Wert als Datum zu interpretieren, z. B. über DateTimeImmutable, strtotime() oder eine interne Datumsnormalisierung. Da an Position 6 ein unerwartetes Zeichen kommt, wirft PHP:

DateMalformedStringException

Die Frames zeigen nur TYPO3-Core-Middleware:

VerifyHostHeader
NormalizedParamsAttribute
ResponsePropagation

Das deutet darauf hin, dass der fehlerhafte Wert sehr wahrscheinlich aus dem HTTP-Request stammt, z. B. aus einem Query-Parameter, Header oder Cookie. Die Exception wird nicht direkt durch die Core-Middleware verursacht, sondern der Core stürzt beim Verarbeiten eines manipulierten Request-Werts ab.

---

2. Fix, konkret¶

Sofortmaßnahme¶

Den konkreten Request-Wert identifizieren, der diesen String enthält.

Prüfe Logs / Access Logs / TYPO3 Debug-Logging nach:

-1 OR 5*5=25

oder:

OR 5*5=25

Mögliche Quellen:

• Query-Parameter, z. B. ?date=-1 OR 5*5=25-01-01
• Header, z. B. If-Modified-Since
• Cookie
• POST-/GET-Parameter einer Extension
• User-Agent- oder Referrer-Fuzzing

Dann muss die Stelle gefunden werden, an der dieser Parameter ungeprüft als Datum verwendet wird.

Typische problematische Muster:

new \DateTimeImmutable($request->getQueryParams()['date'] ?? null);

oder:

strtotime($request->getQueryParams()['tx_ext_filter']['from']);

oder:

DateTimeUtility::dateTimeFormatToTimestamp($value);

Korrekte Validierung¶

Vor dem Parsen explizit validieren.

Beispiel:

$value = $request->getQueryParams()['date'] ?? null;

if (!is_string($value) || !preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) {
    throw new \InvalidArgumentException('Invalid date value', 123456);
}

$date = new \DateTimeImmutable($value);

Noch besser für TYPO3-Filterparameter:

$date = DateTimeUtility::normalizeDateTime(
    $day,
    $month,
    $year
);

oder getrennte Parameter für Tag/Monat/Jahr verwenden.

Falls freie Datumseingaben erlaubt sind:

try {
    $date = new \DateTimeImmutable($value);
} catch (\DateMalformedStringException $e) {
    throw new \InvalidArgumentException('Invalid date value', 123456, $e);
}

Falls der Wert aus einem Header kommt¶

Insbesondere bei Caching-/Conditional-Request-Headern nicht roh parsen.

Beispielhafte Absicherung:

$value = $request->getHeaderLine('If-Modified-Since');

if ($value === '') {
    // kein Header, normal weiterverarbeiten
} else {
    try {
        $date = new \DateTimeImmutable($value);
    } catch (\DateMalformedStringException $e) {
        // ungültigen Header ignorieren
        $date = null;
    }
}

Wenn es eine Extension ist¶

Die betroffene Extension muss ihre Filter-/Parameter-/Header-Auswertung absichern. Kein externer Request-Wert darf direkt in strtotime(), DateTimeImmutable, DateTime, mktime() o. ä. gegeben werden.

---

3. Betroffene TYPO3 Extension¶

Auf Basis der angegebenen Frames ist keine Drittanbieter-Extension eindeutig identifizierbar, weil der Stack nur TYPO3-Core-Dateien enthält.

Allerdings ist die Ursache sehr wahrscheinlich eine Extension, die einen Request-Parameter als Datum verwendet. Kandidaten sind Extensions mit:

• Kalenderfunktion
• Veranstaltungslisten
• Filtern nach Datum
• News-Filtern
• Download-/Cache-Headern
• Custom Middleware
• eigenen Query-Parametern wie date, from, to, timestamp, datetime

Wenn kein eigener Custom-Code vorhanden ist, besonders prüfen:

• news
• calendarize
• eventnews
• sb_event
• ke_search / Suchfilter mit Datumsfacetten
• eigene Listing-/Filter-Extensions

Aber: Aus dem gegebenen Stack lässt sich die Extension nicht sicher ableiten.

---

4. Confidence¶

75%

Begründung: Der Fehler ist eindeutig ein ungültiger Datumsstring, und der Inhalt wirkt wie ein SQL-Injection-/Fuzzing-Payload. Nicht eindeutig ist jedoch die genaue Quelle des Parameters und die betroffene Extension, da im Stack keine Extension-Datei auftaucht.