www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/ee76acec-0801-4128-8d05-7322aca47343/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

DateMalformedStringException: Failed to parse time string (2026-01-1)) OR 937=(SELECT 937 FROM PG_SLEEP(15))---01) at position 9 ()): Unexpected char…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Das ist sehr wahrscheinlich kein TYPO3-Core-Fehler, sondern ein ungültiger/ manipulierten Datumswert aus einem Request, der an einer Stelle als Datum geparst wird.

Der geparsete String ist:

(2026-01-1)) OR 937=(SELECT 937 FROM PG_SLEEP(15))---01)

Auffällig:

• 2026-01-1 ist bereits kein vollständiges ISO-Datum.
• Danach folgt klarer SQL-Injection-Payload:

OR 937=(SELECT 937 FROM PG_SLEEP(15))---

• PG_SLEEP(15) deutet auf einen time-based SQL-Injection-Versuch hin, spezifisch für PostgreSQL.
• Die DateMalformedStringException entsteht, weil dieser Payload in Code landet, der ein Datum erwartet, z. B.:

new \DateTime($userInput);
strtotime($userInput);
DateTimeImmutable::createFromFormat('Y-m-d', $userInput);

Die TYPO3-Core-Frames zeigen nur, dass der Fehler durch den normalen HTTP-Bootstrap/Middleware-Stack bubbling. Die eigentliche Ursache liegt sehr wahrscheinlich in einer Extension oder einem Plugin, das einen Request-Parameter als Datum verwendet.

2. Fix konkret¶

Der betroffene Request-Parameter muss vor dem Parsen validiert werden. Kein roher GET/POST/Route-Parameter darf direkt an DateTime, strtotime() oder SQL-Queries übergeben werden.

Beispiel für sichere Validierung:

use Psr\Http\Message\ServerRequestInterface;
use TYPO3\CMS\Core\Http\BadRequestException;

private function parseIsoDateParameter(ServerRequestInterface $request, string $name): ?\DateTimeImmutable
{
    $rawValue = trim((string)($request->getQueryParams()[$name] ?? ''));

    if ($rawValue === '') {
        return null;
    }

    if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $rawValue)) {
        throw new BadRequestException('Invalid date parameter', 1710001);
    }

    $date = \DateTimeImmutable::createFromFormat('!Y-m-d', $rawValue);
    $errors = \DateTimeImmutable::getLastErrors() ?: [
        'error_count' => 0,
        'warning_count' => 0,
    ];

    if (
        !$date
        || ($errors['error_count'] ?? 0) > 0
        || ($errors['warning_count'] ?? 0) > 0
        || $date->format('Y-m-d') !== $rawValue
    ) {
        throw new BadRequestException('Invalid date parameter', 1710002);
    }

    return $date;
}

Danach nur noch mit dem validierten Datum weiterarbeiten:

$date = $this->parseIsoDateParameter($request, 'date');

if ($date !== null) {
    $dateString = $date->format('Y-m-d');

    $queryBuilder
        ->createNamedParameter($dateString);
}

Wichtig:

• Keine SQL-Teile aus Request-Daten zusammenbauen.
• Keine Rohwerte in SQL interpolieren.
• QueryBuilder/Doctrine-Parameter verwenden:

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

Wenn es eine Extbase-Extension ist, zusätzlich Argument-Validierung nutzen, z. B. per Validator/Annotation für Y-m-d.

Kurzfristige Absicherung:

• Payloads wie PG_SLEEP, SELECT ... FROM, OR 937= in WAF/ModSecurity blockieren.
• Aber: Das ist nur eine Absicherung, nicht der eigentliche Fix.

3. Betroffene TYPO3 Extension¶

Aus dem gelieferten Stack ist keine Extension sicher identifizierbar.

Es gibt keinen Frame unter:

typo3conf/ext/...

Die sichtbaren Frames sind nur TYPO3-Core-HTTP-Middleware.

Die betroffene Extension ist daher diejenige, die den Datumswert aus dem Request entgegennimmt – vermutlich ein Frontend-Plugin mit Datumsfilter, Event-Suche, News-Archiv o. Ä.

Ohne Request-URL, Query-Parameter oder vollständigen Stack kann die Extension nicht seriös benannt werden.

Nicht ursächlich:

typo3/cms-core

Der Core ist hier nur die Laufzeitumgebung, durch die die Exception nach oben läuft.

4. Confidence¶

• Ursache: 95%
• Konkrete Extension: nicht sicher bestimmbar aus den Frames
• Gesamteinschätzung: 95%, dass es sich um einen SQL-Injection-Versuch gegen einen ungeprüften Datum-Parameter handelt.