www.fuchsfelge.com

Bugsink: https://bugsink.cytrus.de/issues/issue/8d8561b8-e633-44b1-8756-923789ea4bdf/event/last/

Typ: NEW issue

Projekt: www-fuchsfelge-com

Bugsink Alert

TYPO3\CMS\Core\Error\Exception: PHP Warning: unserialize(): Error at offset 0 of 9 bytes in /var/www/fuchsfelge.de-2026/htdocs/vendor/typo3/cms-core/…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Der Fehler unserialize(): Error at offset 0 of 9 bytes in AbstractUserAuthentication.php:977 bedeutet, dass TYPO3 versucht, einen korrupten oder ungültigen Serialisierungs-String aus einem User-Authentication-Cookie (fe_typo_user oder be_typo_user) zu deserialisieren.

Konkrete Ursache:
Das Cookie enthält nur 9 Byte ungültige Daten. Serialisierte PHP-Daten beginnen typischerweise mit O:, a:, s: etc. Ein 9-Byte-String ist entweder:

• Ein beschädigtes Cookie (teilweiser Schreibfehler, Race-Condition beim Schreiben der Session-Datei/Cookie-Daten)
• Ein Cookie, das nicht durch serialize() erzeugt wurde (z.B. Base64, JSON oder rohe Binärdaten)
• Ein Cookie, das durch einen Redirect oder Caching-Mechanismus verfälscht wurde

Der Aufruf in AbstractUserAuthentication.php (ca. Zeile 977) ist typischerweise:

$this->user = unserialize($this->getCookie());

Ohne vorherige Validierung des Cookie-Inhalts.

2. Fix beschreiben (konkret)¶

Sofortige Behebung:¶

# Cookie im Browser löschen (fe_typo_user / be_typo_user)
# Oder per CLI:
php vendor/bin/typo3 cache:flush

Code-Fix in der betroffenen Installation:¶

Option A — Cookie-Inhalt validieren vor unserialize():

// In AbstractUserAuthentication.php oder einer eigenen Override-Klasse
$rawCookie = $this->getCookie();
if (empty($rawCookie) || !preg_match('/^[osi]:/', $rawCookie)) {
    $this->user = null;
    $this->setCookie('', 0); // Altes Cookie löschen
    return;
}
$this->user = unserialize($rawCookie);

Option B — Error-Suppression + Fallback (minimaler Fix):

$this->user = @unserialize($rawCookie) ?: null;

Option C — TYPO3 Core-Patch (empfohlen für Produktivsysteme):
Die Core-Datei an der Stelle mit einem try/catch oder @-Operator absichern, oder besser: via ext_localconf.php eine eigene User-Authentication-Klasse registrieren, die das deserialisieren sicher kapselt.

Zusätzlich prüfen:

• Sind die Session-Speicher-Berechtigungen korrekt (/var/www/fuchsfelge.de-2026/ Dateisystem)?
• Wird ein Reverse Proxy / Load Balancer verwendet, der Cookies inkonsistent verteilt?
• Läuft ein CDN/Varnish zwischen Browser und TYPO3, das Cookies manipuliert?

3. Betroffene TYPO3 Extension nennen¶

Der Fehler liegt im TYPO3 Core (cms-core) selbst – konkret in der AbstractUserAuthentication-Klasse. Allerdings deutet die Art des Fehlers darauf hin, dass eine Drittanbieter-Extension oder ein Custom-Extension (möglicherweise im Projekt fuchsfelge.de-2026) den Cookie-Inhalt auf nicht-kompatible Weise geschrieben hat.

Am wahrscheinlichsten betroffen sind:

• felogin (Core-Extension) – Frontend-Login-Plugin, schreibt fe_typo_user-Cookie
• sf_event_mgt oder ähnliche Extensions mit eigenem Login-System
• Eine Custom-Extension des Projekts fuchsfelge, die eigene Session/Cookie-Logik implementiert

Hinweis: Ohne Kenntnis der konkreten installierten Extension-Liste kann nicht mit 100%iger Sicherheit gesagt werden, welche Extension den korrupten Cookie erzeugt hat. Die Ursache liegt aber im Zusammenspiel zwischen dem TYPO3 Core-Authentication-System und einer Extension, die Cookie-Daten schreibt.

4. Confidence (0–100%)¶

Gesamt-Confidence: 85%

Die hohe Confidence beim Root Cause ergibt sich aus dem klaren Fehlerbild: unserialize() an Offset 0 mit 9 Bytes ist ein klassisches Zeichen für einen korrupten oder ungültigen Serialisierungs-String in einem User-Cookie. Die geringere Confidence bei der Extensions-Zuordnung resultiert daraus, dass ohne die konkrete Extension-Liste des Projekts nicht eindeutig identifiziert werden kann, welcher Drittanbieter-Code den falschen Cookie geschrieben hat.