TYPO3-EXT-SA-2026-013 (CVE-2026-46725): Unsichere Deserialisierung in „Content Element Selector“ (ceselector) — unauthentifizierte RCE, Fix in 6.0.1/5.0.1/4.0.2/3.0.3

TL;DR — 90 Sekunden

Betroffen?

Die TYPO3-Drittanbieter-Extension „Content Element Selector“ (mmc/ceselector) in Version ≤6.0.0, ≤5.0.0, 4.0.0–4.0.1 sowie ≤3.0.2 — und dort ausschließlich Content-Elemente, die mit „Persistent Mode: Static“ konfiguriert sind.

Risiko?

CVSS 4.0 Critical (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H). Die Extension übergibt ein Cookie ungeprüft an unserialize(). Das ermöglicht PHP Object Injection; ein öffentliches Detection-Template zeigt bereits eine funktionierende Gadget-Chain über Monolog-Klassen, die auf praktisch jeder TYPO3-Instanz per Composer verfügbar sind — also unauthentifizierte Remote Code Execution.

Sofortmaßnahme?

composer require mmc/ceselector:"^6.0.1" (bzw. die passende Minor-Version der eingesetzten Linie). Ohne sofortiges Update: alle Content-Elemente mit ceselector von „Persistent Mode: Static“ auf eine andere Persistenzart umstellen oder die Extension deaktivieren.

Empfehlung?

Wer ceselector mit Persistent Mode: Static produktiv und öffentlich erreichbar einsetzt, patcht heute — das ist genau die Konfiguration, für die bereits ein öffentliches Erkennungs-/Exploit-Template kursiert.

Kritikalität?

critical — unauthentifiziert, netzwerkweit erreichbar, laut CVSS-Vektor volle Kompromittierung von Vertraulichkeit, Integrität und Verfügbarkeit möglich, öffentliches Detection-Template verfügbar.

Was ist das Problem?

„Content Element Selector“ (mmc/ceselector) ist eine Drittanbieter-Extension für TYPO3, die Redakteur:innen einen erweiterten Auswahldialog für Content-Elemente bereitstellt. Ein Konfigurationsmodus des betroffenen Content-Elements heißt „Persistent Mode: Static“ — in diesem Modus hält die Extension Auswahl-/Zustandsinformationen über ein Cookie fest, das bei jedem Request ausgewertet wird.

Laut TYPO3-Security-Team (TYPO3-EXT-SA-2026-013, CWE-502) liest die Extension diesen Cookie-Wert und übergibt ihn direkt an PHPs unserialize() — ohne Validierung, ohne Allowlist für zulässige Klassen (kein allowed_classes-Parameter), ohne Rückgriff auf ein sichereres Format wie JSON. Da PHPs unserialize() beliebige Objekte instanziieren kann, deren Konstruktoren und Magic Methods (__wakeup, __destruct, __toString u.a.) beim Deserialisieren automatisch ausgeführt werden, entsteht damit eine klassische PHP-Object-Injection-Schwachstelle: Ein Angreifer kann durch Manipulation des Cookie-Werts beliebige im Autoloader verfügbare Klassen instanziieren.

Ob daraus tatsächlich Code-Ausführung wird, hängt davon ab, ob eine sogenannte Gadget-Chain verfügbar ist — eine Kette von Klassen, deren Zusammenspiel beim Deserialisieren einen gefährlichen Seiteneffekt auslöst (Datei schreiben, Befehl ausführen, SSRF). Das öffentlich verfügbare Detection-Template für diese Lücke demonstriert genau eine solche Kette über Monolog\Handler\GroupHandler und Monolog\Handler\BufferHandler, deren Processor-Konfiguration bis zu einem Aufruf von PHPs system() durchgereicht wird. Monolog ist in nahezu jeder TYPO3- und Symfony-basierten Installation als Abhängigkeit vorhanden — die Lücke ist damit nicht nur theoretisch, sondern auf einem Großteil der betroffenen Instanzen praktisch ausnutzbar, ganz ohne Authentifizierung.

Wer ist betroffen?

Ist ceselector im Einsatz, aber kein Content-Element auf „Persistent Mode: Static“ konfiguriert, besteht für diesen konkreten Angriffsweg kein Risiko — ein Update auf die gepatchte Version bleibt trotzdem empfehlenswert, da die Konfiguration jederzeit geändert werden kann und die Extension selbst dann weiterhin ungeprüft deserialisiert.

Auswirkungen

Der CVSS-4.0-Vektor (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) bewertet den Impact als vollständig: Netzwerkweit erreichbar, geringer Angriffsaufwand, keine Nutzerinteraktion, keine Authentifizierung nötig, volle Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. In der Praxis bedeutet das bei erfolgreicher Ausnutzung über eine verfügbare Gadget-Chain: beliebiger Code läuft mit den Rechten des PHP-Prozesses — typische Folgen sind das Ablegen einer Webshell, Diebstahl von Datenbank- und Umgebungs-Credentials, Lateral Movement innerhalb der Infrastruktur und im schlimmsten Fall Ransomware oder Defacement.

Aber auch ohne eine bekannte Gadget-Chain zu einem konkreten „Befehl ausführen“ ist PHP Object Injection kein rein theoretisches Risiko: Bereits das unkontrollierte Instanziieren beliebiger Klassen kann über __destruct- oder __wakeup-Methoden unerwartete Seiteneffekte auslösen — Dateien löschen oder überschreiben, interne Zustände korrumpieren, Denial-of-Service durch Ressourcenerschöpfung, oder je nach verfügbaren Klassen im Autoloader auch Server-Side-Request-Forgery. Da die Schwachstelle über ein Cookie ausgelöst wird, ist sie zudem leicht automatisiert und in großer Zahl gegen viele Instanzen gleichzeitig ausnutzbar.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … ceselector produktiv und öffentlich erreichbar im Einsatz ist und mindestens ein Content-Element auf „Persistent Mode: Static“ konfiguriert ist.
• Mit Priorität prüfen, wenn … ceselector im Einsatz ist, die Persistent-Mode-Konfiguration der einzelnen Content-Elemente aber nicht dokumentiert oder unklar ist.
• Im nächsten regulären Fenster, wenn … ceselector nicht installiert ist oder nachweislich ausschließlich mit einer anderen Persistenzart als „Static“ konfiguriert ist.

Schritt 1 — auf die gepatchte Version aktualisieren

# aktuelle Version prüfen
composer show mmc/ceselector

# aktualisieren, je nach eingesetzter Linie:
composer require mmc/ceselector:"^6.0.1"   # bzw. "^5.0.1", "^4.0.2", "^3.0.3"

# Cache leeren
vendor/bin/typo3 cache:flush

Schritt 2 — Sofort-Workaround, falls ein Update nicht sofort möglich ist

# Option A: betroffene Content-Elemente im Backend umkonfigurieren
# (Content-Element bearbeiten → Persistent Mode → von "Static" auf
#  eine andere verfügbare Persistenzart umstellen)

# Option B: Extension vorübergehend deaktivieren (nach Backup/Test)
composer remove mmc/ceselector
# bzw. im Classic-Mode:
vendor/bin/typo3 extension:deactivate ceselector

# Option C: WAF-/Reverse-Proxy-Regel gegen den Angriffsvektor
# Cookies mit Namen "T3_ceselector_*" blocken, deren Wert mit
# "O:" bzw. URL-encodiert "O%3A" beginnt (PHP-Serialisierungs-Präfix
# für Objekte):
# Beispiel nginx (vereinfachte Illustration, im echten Setup als
# map/if-Kombination oder auf WAF-Ebene umsetzen):
# if ($http_cookie ~* "T3_ceselector_[^;]*=O%3A") { return 403; }

Die WAF-Regel ist ein Notbehelf, kein Ersatz für den Patch — Angreifer können den Payload zusätzlich obfuskieren oder das Cookie anders benennen, falls die Extension das zulässt.

Detection / Prüfung

Version und Konfiguration prüfen

# installierte Version feststellen
composer show mmc/ceselector

# Content-Elemente mit Persistent Mode: Static aufspüren
# (Backend: Seite → Content-Element bearbeiten → Persistent Mode,
#  oder direkt in der Datenbank/über die Extension-Konfiguration prüfen,
#  je nachdem wie ceselector den Modus speichert)

Logs auf den Angriffsvektor durchsuchen

# Access-/Application-Logs nach dem Cookie-Namen durchsuchen und auf
# PHP-Serialisierungs-Präfixe ("O:" bzw. URL-encodiert "O%3A") prüfen
grep -r "T3_ceselector_" /var/log/nginx/access.log* 2>/dev/null | grep -E "O%3A|O:"
grep -r "T3_ceselector_" /var/log/apache2/access.log* 2>/dev/null | grep -E "O%3A|O:"

Auf Spuren erfolgreicher Ausnutzung prüfen

# kürzlich veränderte/neu angelegte Dateien im Web-Root aufspüren
find fileadmin/ typo3temp/ public/ -type f -mtime -30 -newer composer.lock 2>/dev/null

# nach verdächtigen PHP-Dateien außerhalb bekannter Extension-Pfade suchen
find fileadmin/ typo3temp/ -iname "*.php" -o -iname "*.phtml" 2>/dev/null

Aktiv gegen die eigene Instanz testen

# Nur gegen eigene/autorisierte Systeme! Das öffentliche
# nuclei-Template für CVE-2026-46725 nutzt exakt den beschriebenen
# Monolog-Gadget-Chain-Payload im "T3_ceselector_"-Cookie:
nuclei -t http/cves/2026/CVE-2026-46725.yaml -u ihre-domain.tld

Betreiberempfehlung

Mid-Market

Ceselector-Einsatz und Persistent-Mode-Konfiguration innerhalb eines Tages prüfen. Bei „Static“ auf einer öffentlich erreichbaren Instanz: sofort patchen oder auf eine andere Persistenzart umstellen — kein Aufschub, da CVSS Critical und ein öffentliches Detection-/Exploit-Template bereits kursieren.

Enterprise / Multi-Site

Alle Instanzen zentral auf mmc/ceselector im composer.lock scannen, Persistent-Mode-Konfiguration je Content-Element inventarisieren. Wo „Static“ nicht business-kritisch ist, vorsorglich auf eine andere Persistenzart umstellen, unabhängig vom Zeitplan des Patch-Rollouts. WAF-Regel gegen das Cookie-Muster als zusätzliche Verteidigungsschicht ergänzen.

TYPO3-Agenturen mit Kundenprojekten

Kundenbestand per Composer-Lock-Scan nach mmc/ceselector durchsuchen, betroffene Instanzen priorisiert patchen und den Fix in die nächste Sammel-Wartungsmitteilung aufnehmen. Da es sich um eine Drittanbieter-Extension handelt, lohnt zusätzlich die Nachfrage beim Hersteller, ob es über die vier genannten Minor-Releases hinaus weitere betroffene Konfigurationen gibt.

Entscheidungsblock

Heute handeln, wenn: öffentlich erreichbare Instanz + ceselector + Persistent Mode: Static. Diese Woche, wenn: ceselector im Einsatz, Konfiguration muss erst geprüft werden. Regulär, wenn: ceselector nicht installiert oder nachweislich nicht im Static-Modus konfiguriert.

Fazit

CVE-2026-46725 ist ein Lehrbuchbeispiel dafür, warum unserialize() auf nicht vertrauenswürdigen Daten in PHP-Anwendungen als grundsätzlich gefährlich gilt — unabhängig davon, ob eine konkrete Gadget-Chain zum Zeitpunkt der Analyse schon bekannt ist. Hier ist sie es: Eine öffentlich dokumentierte Kette über weit verbreitete Monolog-Klassen macht aus einer „nur“ kritischen Deserialisierungs-Schwachstelle unauthentifizierte Remote Code Execution auf einem Großteil der betroffenen Instanzen. Da die Lücke auf eine spezifische Konfiguration („Persistent Mode: Static“) einer einzelnen Drittanbieter-Extension beschränkt ist, lässt sie sich schnell eingrenzen — wer ceselector nicht oder nicht in dieser Konfiguration einsetzt, ist nicht betroffen. Wer es doch tut, sollte angesichts des bereits kursierenden Detection-Templates nicht auf das nächste reguläre Wartungsfenster warten.

Quellen

• TYPO3 News — TYPO3-EXT-SA-2026-013: Remote Code Execution in extension "Content Element Selector" (ceselector) (19.05.2026)
• ProjectDiscovery — nuclei-templates: CVE-2026-46725.yaml (Detection-Template mit Monolog-Gadget-Chain-Payload)
• CVE Playground — CVE-2026-46725: TYPO3 ceselector Insecure Deserialization RCE
• Tenable — CVE-2026-46725