www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/40aff22f-7945-4154-a573-5022bff501bf/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026'DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)CHR(98)CHR(98),15)'-01-01) at position 4 ('): Unexpe…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Der Fehler wird durch einen ungültigen, aber scheinbar datumsartigen Request-Wert ausgelöst:

2026'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'-01-01

Das ist kein Datum, sondern ein klassischer SQL-Injection-Payload, speziell für Oracle:

'||DBMS_PIPE.RECEIVE_MESSAGE(...)||'

Der Angriff versucht, einen SQL-String zu schließen, eine Oracle-Funktion auszuführen und das Ergebnis wieder in den SQL-String einzukoppeln.

TYPO3/PHP versucht diesen Wert anschließend als Datum zu parsen. Dabei schlägt der Parser an dieser Stelle fehl:

2026'
     ^
position 4: '

Daher:

DateMalformedStringException: Failed to parse time string ... Unexpected character

Wichtig: Der Stack zeigt nur den normalen TYPO3-Bootstrap-/Middleware-Pfad. Der Fehler ist nicht durch VerifyHostHeader, NormalizedParamsAttribute oder ResponsePropagation verursacht. Diese laufen nur normal durch.

2. Fix beschreiben, konkret¶

Sofortmaßnahmen¶

1. Request rekonstruieren

   Such Logs nach dem Payload:

   grep -R "DBMS_PIPE.RECEIVE_MESSAGE" var/log/ 2>/dev/null
   grep -R "2026'||" var/log/ 2>/dev/null
   grep -R "DBMS_PIPE" public/ var/log/ 2>/dev/null
   

   Zusätzlich Access Logs prüfen:

   grep -R "DBMS_PIPE" /var/log/apache2/ /var/log/nginx/ 2>/dev/null
   

   Ziel ist es, die betroffene URL, den Request-Methode und den Parameter zu finden, z. B.:

   /index.php?date=2026'||DBMS_PIPE...
   

   oder ein POST-Feld wie:

   datetime
   starttime
   endtime
   event_date
   

2. Betroffene Extension/Controller finden

   Der Payload landet sehr wahrscheinlich in einem Datumsfeld einer Extension oder eines Core-Moduls. Die vollständige Stacktrace oder die Request-URL ist nötig, um die Extension sicher zu benennen.

3. Datumsvalidierung erzwingen

   Jede Eingabe, die als Datum verarbeitet wird, muss vor der Verwendung streng validiert werden.

   Beispiel für TYPO3/PHP:

   use TYPO3\CMS\Core\Utility\DateTimeUtility;
   use DateTimeInterface;
   
   $rawDate = $request->getQueryParams()['date'] ?? '';
   
   if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $rawDate)) {
       throw new \InvalidArgumentException('Ungültiges Datum', 1710000000);
   }
   
   $dateTimeUtility = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(DateTimeUtility::class);
   $date = $dateTimeUtility->getDateTime($rawDate, DateTimeInterface::ATOM);
   

   Für reine Datumswerte sollte z. B. erlaubt sein:

   2026-01-01
   

   Und nicht:

   2026'||DBMS_PIPE.RECEIVE_MESSAGE(...)||'-01-01
   

4. SQL-Injection vermeiden

   Falls das Datum in SQL eingebaut wird:

   Schlecht:

   $query = 'SELECT * FROM tx_ext_table WHERE date = "' . $date . '"';
   

   Gut:

   $queryBuilder->createQuery()
       ->createUpdateStatement(tx_ext_table::class)
       ->where($queryBuilder->expr()->eq('date', $queryBuilder->createNamedParameter($date, \PDO::PARAM_STR)));
   

5. Temporärer Schutz

   Als WAF-/ModSecurity-Regel kann man den Payload blockieren:

   DBMS_PIPE.RECEIVE_MESSAGE
   CHR\(
   \|\|
   

   Das ist nur ein Notfix. Die eigentliche Lösung ist valide Eingabeprüfung und sichere Datenverarbeitung.

3. Betroffene TYPO3 Extension¶

Aus den angegebenen Frames ist keine TYPO3-Extension erkennbar.

Der Stack zeigt ausschließlich TYPO3-Core-Dateien:

vendor/typo3/cms-core/Classes/Http/...
vendor/typo3/cms-core/Classes/Middleware/...

Daher:

Betroffene Extension: nicht identifizierbar aus dem gegebenen Trace.

Der Fehler selbst wird durch TYPO3 Core bzw. PHP-Datenzeit-Parsing ausgelöst, aber der ausführende Payload stammt sehr wahrscheinlich aus einem externen Request-Parameter eines bestimmten Endpunkts.

4. Confidence¶

Root Cause: 97%

Sehr hohe Sicherheit, dass es sich um einen SQL-Injection-Versuch handelt, der versehentlich als Datum verarbeitet wurde.

Extension identifizierbar: 90%, dass keine Extension aus dem gegebenen Stack genannt werden kann.

Eine konkrete Extension kann nur genannt werden, wenn die vollständige Stacktrace, die Request-URL oder der betroffene Request-Parameter vorliegt.