www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/bce34975-5662-4828-9b75-6c50288a4b22/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

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

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache
Die Ausnahme DateMalformedStringException wird geworfen, weil ein vom Client übermittelter Parameter (hier der Wert

2026--1" OR 5*5=26 -- -01

) direkt an den PHP‑DateTime‑Konstruktor bzw. an DateTime::createFromFormat übergeben wird, ohne dass zuvor geprüft wird, ob der String ein gültiges Datum repräsentiert.

Der Aufrufweg führt über die TYPO3‑Core‑Middleware NormalizedParamsAttribute ( /vendor/typo3/cms-core/Classes/Middleware/NormalizedParamsAttribute.php:44 ). Diese Middleware versucht, Route‑Parameter automatisch in den von der Kontrollermethode erwarteten Typ zu konvertieren. Ist ein Parameter beispielsweise mit \DateTimeInterface type‑hinted, ruft die Middleware intern new \DateTime($value) auf. Da der Wert SQL‑Injection‑ähnliche Zeichen enthält (--, ", OR), schlägt das Parsen fehl und es wird die oben genannte Ausnahme geworfen.

Kurz:

• Eingabeparameter (GET/POST/Routen‑Placeholder) wird nicht validiert.
• Middleware versucht, den String zu einem DateTime‑Objekt zu konvertieren.
• Konvertierung schlägt fehl → DateMalformedStringException.

2. Konkreter Fix

Die sicherste Lösung liegt auf Anwendungs‑ bzw. Ebene der Erweiterung, die die Route definiert – nicht im TYPO3‑Kern, weil die Middleware ihr Verhalten korrekt ausführt.

Beispiel‑Controller‑Anpassung (Extbase):

use Psr\Http\Message\ServerRequestInterface;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;

class MyController extends ActionController
{
    /**
     * @param ServerRequestInterface $request
     * @return void
     */
    public function showAction(ServerRequestInterface $request): void
    {
        $rawDate = $request->getAttribute('date'); // <-- stammt aus der Route
        try {
            $date = new \DateTime($rawDate);
        } catch (\Exception $e) {
            // Logging optional
            $this->addFlashMessage('Das übermittelte Datum ist ungültig.', '', \TYPO3\CMS\Core\Messaging\FlashMessage::ERROR);
            $this->redirect('error'); // oder direkt Response mit 400 erzeugen
            return;
        }

        // Weiterverarbeitung mit gültigem $date …
    }
}

3. Betroffene TYPO3‑Extension
Der Fehler tritt nicht im TYPO3‑Kern auf, sondern in jeder Extension, die eine Route mit einem DateTime‑typisierten Controller‑Argument definiert und den entsprechenden Parameter über GET/POST/Routen‑Placeholder empfängt.

Häufige Beispiele (aus der Praxis) sind:

• Eigene Erweiterungen mit Aktionen wie showAction(\DateTimeInterface $date) oder editAction(\DateTimeInterface $start).
• Erweiterungen, die Kalender‑ bzw. Ereignisfunktionen bereitstellen (z. B. sr_feuser_register, sf_event_mgt, tx_news im Backend‑Modul, wenn dort Datum‑Filter über URL übergeben werden).

Ohne den genauen Stack‑Trace der Controller‑Methode kann man nicht genau sagen, welche Extension es ist – jedoch liegt die Verantwortung bei der benutzerdefinierten Extension, die den Route‑Parameter mit einem DateTime‑Type‑Hint verwendet.

4. Confidence
85 % – Die Analyse basiert klar auf dem beobachteten Ausnahme‑Typ, dem Aufruf über NormalizedParamsAttribute und dem bekannten Verhalten von TYPO3, Route‑Parameter automatisch in type‑hinted Argumente zu konvertieren. Die einzige Unsicherheit besteht darin, welche konkrete Extension den betroffenen Route‑Parameter definiert, aber die Ursache und der empfohlene Fix sind eindeutig.