www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/6ed5edeb-d63d-4a99-8798-303555dd1939/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¶

Der Fehler wird durch einen manipulierten Request-Wert ausgelöst, der als Datum interpretiert wird:

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

Das ist kein gültiges Datum, sondern ein typisches SQL-Injection-Scanner-Payload. PHP versucht diesen Wert via DateTimeImmutable / DateTime / strtotime o. ä. zu parsen und bricht mit DateMalformedStringException ab.

Wichtig: Der Stacktrace zeigt nur TYPO3-Core-Middleware. Das bedeutet: Der fehlerhafte Wert wird sehr früh im Request-Lifecycle verarbeitet oder läuft durch Middleware/Core durch, bevor eine Extension sichtbar wird.

Es gibt keinen Hinweis auf erfolgreiche SQL-Injection — der Wert schlägt bereits beim Datumsparsing fehl.

2. Fix konkret¶

Der konkrete Fix ist: Request-Inputs vor dem Datumsparsing strikt validieren und ungültige Werte abfangen, statt sie direkt an DateTime zu übergeben.

Beispiel für einen erwarteten Datumsparameter Y-m-d:

use DateTimeImmutable;
use DateTimeZone;
use DateMalformedStringException;

function parseDateParameter(mixed $raw): ?DateTimeImmutable
{
    if (!is_string($raw) || trim($raw) === '') {
        return null;
    }

    $raw = trim($raw);

    if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $raw)) {
        throw new \InvalidArgumentException('Invalid date parameter', 171001);
    }

    try {
        $date = DateTimeImmutable::createFromFormat(
            '!Y-m-d',
            $raw,
            new DateTimeZone('UTC')
        );
    } catch (DateMalformedStringException $e) {
        throw new \InvalidArgumentException('Invalid date parameter', 171002, $e);
    }

    $errors = DateTimeImmutable::getLastErrors();

    if (
        $date === false ||
        ($errors && ($errors['warning_count'] > 0 || $errors['error_count'] > 0)) ||
        $date->format('Y-m-d') !== $raw
    ) {
        throw new \InvalidArgumentException('Invalid date parameter', 171003);
    }

    return $date;
}

Zusätzlich:

• Zugriff auf Webserver-/TYPO3-Logs prüfen: Wo taucht 5*5=26 oder -- -01-01 im Request auf?
• Typische Quellen: GET/POST-Parameter, Route-Parameter, Cookie, Header.
• Im Projekt suchen nach:

  grep -R "new DateTime\|DateTimeImmutable\|strtotime\|createFromFormat" typo3conf/ext
  

• Ungültige Werte sollten mit 400 Bad Request beantwortet oder ignoriert werden.
• Keine Core-Vendor-Dateien patchen.
• TYPO3 und PHP auf aktuelle Patchversionen aktualisieren.

3. Betroffene TYPO3 Extension¶

Aus dem gegebenen Stacktrace ist keine projektbezogene Extension sicher identifizierbar.

Sichtbar ist nur:

typo3/cms-core

Also betroffen im Stacktrace: TYPO3 Core / Middleware-Layer, nicht nachweisbar eine Extension aus typo3conf/ext.

Falls der Datumswert aus einem Plugin-Parameter stammt, wäre die eigentlich betroffene Extension diejenige, die diesen Parameter ausliest und parsed — sie erscheint hier aber nicht im Trace.

4. Confidence¶

88%

Ursache als manipuliertes/malformed Datum sehr wahrscheinlich. Die konkrete Extension ist aus diesem Stacktrace nicht sicher ableitbar.