www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/3b153b45-dce2-4ee0-ade2-86b04f1726c3/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-01ymIuWJrl'; waitfor delay '0:0:15' -- -01) at position 7 (y): The timezone could not…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Das ist kein echtes Timezone-/Database-Problem, obwohl die PHP-Fehlermeldung so klingt.

Der geparsete Wert ist:

2026-01ymIuWJrl'; waitfor delay '0:0:15' -- -01

Das ist kein gültiges Datum, sondern eindeutig ein manipuliertes Datum mit einem SQL-Injection-Payload:

'; waitfor delay '0:0:15' --

waitfor delay ist typisch für SQL-Server-basierte Time-Based-SQL-Injection-Tests, oft von Scannern wie sqlmap.

TYPO3/PHP versucht offenbar, diesen Request-Wert als Datum zu parsen, z. B. über:

new \DateTime(...)
new \DateTimeImmutable(...)
TYPO3\CMS\Core\Type\DateTime
f:format.date
DateTime::createFromFormat()

und scheitert bei Position 7, also beim y nach:

2026-01

Die sichtbaren Frames zeigen nur TYPO3-Core-Middleware. Das bedeutet: Die Exception läuft durch den TYPO3-Core durch, aber die eigentliche auslösende Stelle ist im gezeigten Stack nicht sichtbar.

2. Fix konkret¶

Sofortmaßnahme¶

Den Rohwert aus Request/GET/POST/Cookie/Header niemals direkt an DateTime übergeben.

Stattdessen vorher strikt validieren.

Beispiel für ein Datum im Format Y-m-d:

use DateTimeImmutable;
use TYPO3\CMS\Extbase\Mvc\Exception\InvalidArgumentValueException;

private function parseDateStrict(string $value): DateTimeImmutable
{
    if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) {
        throw new InvalidArgumentValueException('Ungültiges Datum', 1710000001);
    }

    $date = DateTimeImmutable::createFromFormat('!Y-m-d', $value);
    $errors = DateTimeImmutable::getLastErrors();

    if (
        !$date
        || (($errors['error_count'] ?? 0) > 0)
        || (($errors['warning_count'] ?? 0) > 0)
        || $date->format('Y-m-d') !== $value
    ) {
        throw new InvalidArgumentValueException('Ungültiges Datum', 1710000002);
    }

    return $date;
}

Wichtig: Nicht „bereinigen“ und weiterverarbeiten, sondern bei solchen Payloads klar mit 400 Bad Request oder Extbase-InvalidArgumentValueException reagieren.

Zusätzlich prüfen¶

Im Projekt nach solchen Mustern suchen:

rg "new DateTime|DateTimeImmutable|DateMalformedStringException|createFromFormat|format.date" typo3conf/ext

Besonders prüfen:

• Custom Extensions
• Controller-Action-Parameter
• Formulare
• Filter-/Facetten-Parameter
• Fluid-Templates mit f:format.date
• Custom Middleware
• QueryBuilder-/SQL-Stellen

Falls der Wert später in eine SQL-Abfrage gelangt, zusätzlich sicherstellen:

$queryBuilder
    ->createNamedParameter($date->format('Y-m-d'))

verwenden und keine String-Interpolation im SQL.

Also nicht:

$sql = '... WHERE date >= "' . $rawDate . '"';

sondern:

$queryBuilder->expr()->gte(
    'date',
    $queryBuilder->createNamedParameter($date->format('Y-m-d'))
);

3. Betroffene TYPO3 Extension¶

Aus dem gelisteten Stack ist keine benutzerdefinierte Extension eindeutig erkennbar.

Sichtbar ist nur:

typo3/cms-core

Der Core ist hier aber sehr wahrscheinlich nur die Durchlauf-/Propagation-Schicht. Die eigentliche Ursache liegt vermutlich in einer Extension oder Custom-Code-Stelle, die einen Request-Parameter als Datum interpretiert.

Wenn keine eigene Extension im Full-Stack erscheint, sollte der vollständige Stack geprüft werden. Der gezeigte Ausschnitt reicht nicht, um die Extension sicher zu benennen.

4. Confidence¶

95%

Sehr hohe Confidence, dass es sich um einen manipulierten/maliciösen Requestwert handelt, der als Datum geparst wird. Die Extension selbst ist aus dem Ausschnitt nicht sicher bestimmbar.