www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/9a5ddce2-0bf6-4466-a4d2-341072e854a5/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Die Exception entsteht, weil ein ungültiger, manipulierten Datums-/Jahreswert an einen PHP/DateTime-Parser übergeben wird:

-1' OR 5*5=26 -- -01-01

Das ist kein normaler Datumswert, sondern ein klassischer SQL-Injection-Payload:

-1' OR 5*5=26 --

Wahrscheinlich erwartet irgendeine Extension einen Parameter wie year, date, from, until o. Ä. und baut daraus intern einen Datumsstring, z. B.:

$year . '-01-01'

Aus dem manipulierten Wert wird dann:

-1' OR 5*5=26 -- -01-01

DateTime/strtotime kann das nicht parsen und wirft:

DateMalformedStringException

Die gezeigten TYPO3-Core-Frames sind nur die Propagation durch den HTTP-Middleware-Stack. Der eigentliche Auslöser liegt sehr wahrscheinlich nach ResponsePropagation, also in einer Extension, einem Plugin oder einer Site-spezifischen Middleware.

2. Fix konkret¶

Nicht im TYPO3-Core fixen. Der Core zeigt hier nur die Exception. Fix muss an der Stelle passieren, die den Parameter einliest und als Datum interpretiert.

Konkrete Schritte:

1. Vollständigen Stacktrace prüfen, besonders Frames nach:

TYPO3\CMS\Core\Middleware\ResponsePropagation::process

Dort steht die tatsächliche Extension/Controller-Methode.

2. Code-Stellen suchen, die Datumswerte bauen, z. B. nach folgenden Mustern:

grep -R "DateTime\|DateTimeImmutable\|strtotime\|dateStringToTimestamp\|'-01-01'\|\"-01-01\"" typo3conf/ext

3. Parameter vor dem Parsen strikt validieren, z. B. für Jahresparameter:

$year = trim((string)($request->getQueryParams()['year'] ?? ''));

if (!preg_match('/^(19|20)\d{2}$/', $year)) {
    // 400 oder 404 zurückgeben, nicht parsen
    throw new \TYPO3\CMS\Core\Http\PropagateResponseException(
        $responseFactory->createResponse(400),
        400
    );
}

$date = \DateTimeImmutable::createFromFormat('!Y-m-d', $year . '-01-01');

4. Exception abfangen, falls der Wert trotzdem ungültig ist:

try {
    $date = new \DateTimeImmutable($dateString);
} catch (\DateMalformedStringException $e) {
    // ungültige Anfrage sauber behandeln
    // z. B. 400 Bad Request oder Parameter verwerfen
}

5. Falls der Wert in SQL eingeht: keine String-Interpolation, sondern TYPO3 QueryBuilder mit Parametern:

$queryBuilder
    ->expr()
    ->gte('start_date', $queryBuilder->createNamedParameter(
        $date->format('Y-m-d H:i:s'),
        \TYPO3\CMS\Core\Database\Connection::PARAM_STR
    ));

6. Kurzfristige Absicherung: WAF/Request-Filter oder Webserver-Regel, die Anfragen mit Payloads wie

' OR
--
UNION SELECT
SLEEP(

blockiert oder loggt.

3. Betroffene TYPO3 Extension¶

Aus dem gelieferten Trace ist keine konkrete Dritt-Extension erkennbar.

Sichtbar ist nur:

typo3/cms-core

also TYPO3-Core-Middleware.

Die auslösende Extension ist sehr wahrscheinlich eine Custom- oder Dritt-Extension, die einen Datums-/Jahresparameter verarbeitet. Typische Kandidaten wären Extensions mit Archiv-, Kalender-, News- oder Filterfunktionen, aber das ist aus diesem Trace nicht belegbar.

Antwort: Betroffene Extension laut Trace: typo3/cms-core als sichtbare Systemextension.
Tatsächliche fachliche Ursache: vermutlich eine nicht genannte Extension/Custom-Code-Stelle, die einen manipulierten Datumsparameter unparsed an DateTime übergibt.

4. Confidence¶

Confidence: 90%

• Sehr hoch, dass es sich um einen manipulierten/ungültigen Datumsparameter handelt.
• Sehr hoch, dass der Payload SQL-Injection-artig ist.
• Mittel bis niedrig, welche konkrete Extension betroffen ist, da der relevante Stacktrace-Abschnitt fehlt.