www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/982b6b94-6083-4081-a9b2-13d0d3753172/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-(select DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)CHR(98)CHR(98),15) from dual)-01) at positio…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse¶

1. Ursache¶

Dies ist ein SQL-Injection-Angriffsversuch, der als DateMalformedStringException sichtbar wird. Der Angreifer injectet einen Oracle-typischen Blind-SQL-Payload (select DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15) from dual) in einen Datumsparameter. Das Format 2026-(payload)-01 versucht, das Date-Format YYYY-MM-DD vorzutäuschen, um Validierungschecks zu umgehen.

PHP's DateTime wirft die Exception bei Position 4 (- nach 2026), weil das kein gültiges Datum ist. Der Angriff wurde durch die Date-Parsing abgefangen, bevor er die Datenbank erreichte.

Der Eintrittspunkt liegt wahrscheinlich in einem Extension-Frontend (z.B. Formular, GET/POST-Parameter), das Datumswerte entgegennimmt und diese ungefiltert in Datenbankqueries verwendet.

2. Fix (konkret)¶

// Statt direktem Parsen von User-Input:
$date = DateTime::createFromFormat('Y-m-d', $userInput);
if (!$date) {
    throw new \InvalidArgumentException('Ungültiges Datumsformat');
}

// Zusätzlich: Prepared Statements für alle DB-Queries
$connection->executeQuery(
    'SELECT * FROM tx_extension_table WHERE date_field = :date',
    ['date' => $userInput],
    ['date' => \PDO::PARAM_STR]
);

Zusätzlich:

• Input Validation mit Regex /^\d{4}-\d{2}-\d{2}$/ vor dem Parsen
• htmlspecialchars() / Typkonvertierung für alle GET/POST-Parameter
• TYPO3 Core auf aktuellste Version updaten

3. Betroffene Extension¶

Die Stacktrace-Frames zeigen primär typo3/cms-core (Middleware NormalizedParamsAttribute). Der Eintrittspunkt ist aber mit hoher Wahrscheinlichkeit eine Drittanbieter-Extension, die Datumsfelder aus User-Input verarbeitet (z.B. Event-Extension, Form-Extension, Repository mit Custom Query). Ohne Zugriff auf den vollständigen Stacktrace / Application-Code lässt sich die Extension nicht sekundensicher benennen – prüfe vendor/ nach nicht-core Extensions mit Datumsfeldern.

4. Confidence¶

• Angriffserkennung: 98% — klarer SQLi-Pattern in Date-String
• Betroffene Extension: 55% — ohne vollständigen Trace nicht eindeutig identifizierbar
• Schadensereignis: 20% — Attacke wurde durch Date-Exception abgefangen, Datenbank wurde nicht kompromittiert

Empfehlung: HTTP-Request-Logs prüfen, um den genauen Endpoint / die Extension zu identifizieren. ModSecurity/WAF-Regeln für SQLi-Patterns ergänzen.