www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/4f47fbff-6103-4051-985c-ddda3f7fe545/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026--1 OR 5*5=25-01) at position 4 (-): Unexpected character

---

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Der Fehler entsteht, weil irgendwo ein Request-Wert als Datum an PHPs DateTime-Parser übergeben wird:

2026--1 OR 5*5=25-01

PHP erwartet vermutlich ein Datum wie:

2026-01-01

Stattdessen kommt:

2026--1 OR 5*5=25-01
       ^^

Fehlerposition 4 bedeutet: Nach 2026 folgt ein ungültiges -, weil kein gültiger Monat kommt.

Der Teil

OR 5*5=25

ist ein klassisches SQL-Injection-/Scanner-Muster. Sehr wahrscheinlich wurde ein Datum-Parameter manipuliert, z. B.:

?datum=2026--1 OR 5*5=25-01
?startDate=2026--1 OR 5*5=25-01
?filter[date]=2026--1 OR 5*5=25-01

Wichtig: Das ist primär kein TYPO3-Core-Datum-Fehler, sondern ein ungültiger bzw. manipuliert eingespielter Request-Wert, der nicht sauber validiert wurde, bevor er in DateTime, DateTimeImmutable, strtotime() oder createFromFormat() landet.

---

2. Fix konkret¶

Sofortmaßnahme¶

Im Access-Log oder TYPO3-Log den vollständigen Request finden:

grep -R "2026--1 OR 5*5=25-01" /var/log/nginx/ /var/log/apache2/

bzw. encoded suchen:

grep -R "2026--1" /var/log/nginx/ /var/log/apache2/

Dann prüfen, ob der Wert aus Query-String, POST-Body, Cookie oder Header kommt.

---

Code-Fix¶

Vor jedem Datum-Parsing strikt validieren.

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

use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Core\Http\JsonResponse;

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

if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $date)) {
    throw new \TYPO3\CMS\Core\Http\BadRequestException(
        'Invalid date parameter',
        1710000001
    );
}

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

if ($dateTime === false || \DateTimeImmutable::getLastErrors() !== false) {
    throw new \TYPO3\CMS\Core\Http\BadRequestException(
        'Invalid date parameter',
        1710000002
    );
}

Für Datum mit Uhrzeit entsprechend:

$dateTime = \DateTimeImmutable::createFromFormat('!Y-m-d H:i:s', $value);

Nicht machen:

new \DateTimeImmutable($rawInput);
strtotime($rawInput);

ohne vorherige Validierung.

---

TYPO3/Extbase-spezifisch¶

Falls Extbase-Argumentkonvertierung genutzt wird:

• DateTime-Argumente explizit validieren.
• dateFormat im TypeConverter setzen.
• Custom Validator verwenden, wenn nur bestimmte Formate erlaubt sind.
• Ungültige Eingaben mit 400 Bad Request beantworten, nicht als 500er durchlaufen lassen.

Beispiel Validator-Logik:

if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $value)) {
    $this->result->forProperty('startDate')
        ->addError(new \TYPO3\CMS\Extbase\Error\Error('Invalid date format', 1710000003));
}

---

Optional: Hardening¶

Da der Wert wie ein SQL-Injection-Scan aussieht:

• Webserver/WAF-Regel gegen offensichtliche SQLi-Patterns prüfen.
• Keine SQL-Strings per Rohinput zusammenbauen.
• Query Builder/Prepared Statements继续使用.
• Stacktrace in Produktion nicht öffentlich anzeigen.

---

3. Betroffene TYPO3 Extension¶

Aus dem gelieferten Stack ist keine Projekt-Extension sichtbar.

Sichtbar ist nur:

typo3/cms-core

insbesondere HTTP-Middleware:

VerifyHostHeader
NormalizedParamsAttribute
ResponsePropagation

Diese Frames bedeuten aber nur, dass der Fehler durch die TYPO3-Request-Pipeline gelaufen ist. Der eigentliche Datum-Parse fehlt im gelieferten Trace.

Betroffene Extension daher:

Keine Extension sicher identifizierbar.
Aus dem Stack nur TYPO3 Core / typo3/cms-core sichtbar.

Wenn eine Extension den Parameter einliest und als Datum parst, steht deren Frame nicht im bereitgestellten Ausschnitt.

---

4. Confidence¶

Confidence: 90%

Begründung: Die Ursache als ungültiger/manipulierter Datumswert ist sehr klar. Die exakte verantwortliche Extension ist aber nicht sicher benennbar, weil im Stack kein Extension-Frame enthalten ist.