Sechs TYPO3-Extension-Advisories vom 19. Mai 2026 — zwei RCEs, zwei SQL-Injections, dreifach ke_search, eine Access-Control-Lücke und welche Patch-Reihenfolge der Cluster verlangt

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

Sechs Advisories TYPO3-EXT-SA-2026-008 bis -013, alle vom 19. Mai 2026 ca. 18:00 UTC. Betroffene Extensions: crawler, sf_register, news, ke_search, tt_address, ceselector.

Wie schwer im Schnitt?

Ein Critical (ceselector, CVSS-Vektor schreit nach unauthentischer RCE), zwei High (news mit SQL-Injection, crawler mit RCE), drei Medium (tt_address, sf_register, ke_search).

Welche zwei Muster wiederholen sich?

Erstens Insecure Deserialization (CWE-502) — sowohl ceselector als auch crawler hängen unserialize() an Angreifer-kontrollierte Eingaben (Cookie bzw. HTTP-Response-Header). Zweitens SQL Injection (CWE-89) — tt_address und news bauen Queries ohne saubere Parameterisierung. Beide Muster sind seit Jahren bekannt, aber in dieser Kombination treten sie selten gleichzeitig in einem Advisory-Tag auf.

Bin ich mit Auto-Update-Pipeline (Renovate, Dependabot, Mend) betroffen?

Wenn eine der sechs Extensions im Composer-Lock steht, dann ja — in einer Patch-Pipeline-gewarteten Umgebung erscheinen die sechs Patch-Releases automatisiert als Merge-Requests gegen die Image-Definitionen. Container-Rebuild läuft graceful, der Worker-Restart bleibt für Endnutzer unsichtbar.

Bin ich Self-Hosted ohne Auto-Update-Pipeline betroffen?

Dann ja, und Sie sollten heute updaten. Reihenfolge nach Risiko: zuerst ceselector (Critical, public-facing RCE), dann news (High, public-facing SQLi), dann crawler (High, admin-escalation), dann der Rest.

Welche zwei Konfigurations-Conditions sollte ich kennen?

ceselector ist nur bei Persistent Mode: Static exploitable. news-SQLi greift nur, wenn die Date Menu of news articles-Plugin-Instanz aktiv ist unddisableOverrideDemand nicht gesetzt ist. Wer beide Bedingungen kennt und überprüfen kann, hat eine Risikoanalyse vor dem Update.

Operative Reaktion auf den Cluster

Moselwal positioniert sich ausdrücklich auf Auto-Update-fähige Plattformen — die CTA unten am Beitrag fasst das in einem Satz. Das operative Prinzip dahinter: eine Patch-Pipeline (Renovate, Dependabot, Mend oder vergleichbar) prüft Composer-Pakete mehrmals täglich und schiebt neue Patch-Versionen automatisiert in Merge-Requests gegen die Image-Definitionen. Eine Welle wie der 19.-Mai-Cluster fließt damit ohne Notschicht in die Build-Pipeline: die sechs Patch-Releases (crawler 12.0.11 / 11.0.13, sf_register 14.0.2 / 13.2.4, news 14.0.3 / 13.0.2 / 12.3.2 / 11.4.4, ke_search 7.0.1 / 6.6.1 / 5.6.2, tt_address 10.0.1 / 9.1.1 / 8.1.2, ceselector 6.0.1 / 5.0.1 / 4.0.2 / 3.0.3) erscheinen als Merge-Requests, die CI rebuildet die Container-Images, die Worker-Restarts (FrankenPHP, php-fpm) sind graceful, der Service bleibt für Endnutzer ohne Unterbrechung.

Wer das nicht hat — eine eigenständige TYPO3-Installation ohne Auto-Update-Pipeline — hat bei den Critical- und High-Severity-Lücken einen sehr engen Handlungsspielraum. Die folgenden Abschnitte gehen pro Advisory durch, was technisch passiert, welche Voraussetzungen die Exploitation hat und welche Update-Reihenfolge sinnvoll ist.

TYPO3-EXT-SA-2026-013 — ceselector (Critical, RCE über unserialize-Cookie)

Technische Analyse

Die Extension liest beim Persistent-Mode-Lookup einen Client-Cookie aus, der die zuletzt gewählte Content-Element-Auswahl serialisiert mitführen soll. Der Cookie-Wert wird ohne Schema-Validierung und ohne allowed_classes-Whitelist direkt an PHPs unserialize() übergeben. Damit liegt ein klassisches PHP-Object-Injection-Primitive vor: Ein nicht-authentifizierter Angreifer kann einen serialisierten Payload mit beliebigen Klassen-Instanzen konstruieren, deren __destruct()-, __wakeup()- oder __toString()-Magic-Methods bei der Deserialisierung getriggert werden. In Verbindung mit einer beliebigen PHP-Klasse mit gadget-fähigem __destruct (TYPO3-Core hat dafür dokumentierte POP-Chain-Gadgets) ist das eine vollständige RCE im Web-Server-Prozess.

Voraussetzung für die Exploitation

Persistent Mode: Static muss in den Plugin-Settings gesetzt sein. Wer den Plugin-Mode dynamic oder ohne Persistierung fährt, ist nicht direkt angreifbar. Trotzdem updaten — das ist eine günstige Versicherung gegen Konfigurations-Drift in der Zukunft.

TYPO3-EXT-SA-2026-010 — news (High, SQL-Injection im Date-Menu-Plugin)

Technische Analyse

Die Date-Menu-of-news-articles-Plugin-Instanz akzeptiert über einen URL-Parameter ein Datum oder einen Datumsbereich für die Menü-Generierung. Der Parameter fließt ohne Parameter-Binding direkt in die generierte SQL-Query. Damit ist eine String-Interpolation-basierte SQL-Injection möglich — ein unauthentifizierter Angreifer kann beliebige UNION SELECT-Statements anhängen und Inhalte aus anderen Tabellen extrahieren.

Voraussetzung für die Exploitation

Zwei Bedingungen müssen gleichzeitig erfüllt sein: das Date Menu of news articles-Plugin muss eingesetzt sein, und das TypoScript-Setting plugin.tx_news.settings.disableOverrideDemand darf nicht aktiviert sein. Wer disableOverrideDemand = 1 setzt, schaltet den verwundbaren Code-Pfad ab — das ist seit Jahren die empfohlene Hardening-Maßnahme.

TYPO3-EXT-SA-2026-008 — crawler (High, RCE über X-T3Crawler-Meta-Header)

Technische Analyse

Der Site-Crawler crawled konfigurierte URLs und liest aus der HTTP-Response einen X-T3Crawler-Meta-Response-Header, der Metadaten der gecrawlten Page transportieren soll. Der Header-Wert wird mit unserialize() ohne allowed_classes-Restriktion verarbeitet. Wenn ein Angreifer den Endpoint kontrolliert, den der Crawler abruft (eigene Website, kompromittierter Drittanbieter, Open-Redirect mit Header-Injection im Backend), kann er einen serialisierten Payload als Response-Header zurückgeben und damit PHP-Object-Injection im Crawler-Worker-Prozess auslösen — wieder mit den bekannten POP-Chain-Gadgets aus TYPO3-Core.

Voraussetzung für die Exploitation

Administrative Privilegien, um eine crawler-fähige Page-Konfiguration anzulegen und einen Scheduler-Task zu starten. Damit ist die Lücke kein Direkt-RCE-Pfad für unauthentifizierte Angreifer — aber sie ist ein Privileg-Eskalations-Pfad für nicht-super-admin-Administratoren.

TYPO3-EXT-SA-2026-011 — ke_search (Medium, Dreierkette XXE + Path Traversal + Information Disclosure)

Technische Analyse — drei Vektoren, eine Extension

Vektor 1 — XXE in der OOXML-Parsing-Pipeline. Der File-Indexer von ke_search verarbeitet .xlsx und .pptx Dateien, indem er die enthaltenen XML-Streams parst. Die XML-Parser-Konfiguration deaktiviert External-Entity-Resolution nicht. Wenn ein Angreifer eine präparierte xlsx/pptx-Datei in ein indiziertes Verzeichnis legt, kann das XML-Parsing eine Entity-Referenz auf lokale Dateien (file:///etc/passwd) oder auf externe URLs (out-of-band SSRF) auslösen — und der gelesene Inhalt landet im Search-Index, also im Frontend-Output.

Vektor 2 — Path Traversal im File-Indexer. Der File-Indexer normalisiert den directories-Konfigurations-Pfad nicht. Ein Backend-User mit Indexer-Konfigurations-Recht kann Sequenzen wie ../../../etc setzen und damit Dateien aus beliebigen Verzeichnissen des Servers in den Search-Index ziehen.

Vektor 3 — Information Disclosure über additional_tables. Die additional_tables-Konfiguration der Page- und tt_content-Indexer akzeptiert beliebige Tabellen- und Feldnamen. Ein Backend-User mit Indexer-Konfigurations-Recht kann sensible interne TYPO3-Tabellen (be_users.password-Hashes, sys_log-Einträge) in den Search-Index kopieren.

TYPO3-EXT-SA-2026-012 — tt_address (Medium, latente SQL-Injection in getSqlQuery())

Technische Analyse

Die Methode AddressRepository::getSqlQuery() baut einen Datenbank-Query, ohne den Input zu sanitisieren. Damit liegt eine klassische SQL-Injection-Stelle vor — aber: Die Methode wird von der tt_address-Extension selbst an keiner Stelle aufgerufen. Ein Default-Setup ist also nicht direkt verwundbar.

Die Methode ist public. Custom-Extensions, die AddressRepository per DI oder direkter Instanzierung nutzen und getSqlQuery() mit untrusted Input aufrufen, exponieren ihre Site. Das ist der Grund, warum das Security Team die Severity bewusst niedriger als den CVSS-Score eingestuft hat.

TYPO3-EXT-SA-2026-009 — sf_register (Medium, FE-User-Group-Eskalation bei Self-Service-Registrierung)

Technische Analyse

Die create- und edit-Flows der Self-Service-Registrierung beschränken nicht, welche Properties des FrontendUser-Models per HTTP-POST gesetzt werden dürfen, und prüfen die FE-User-Group-Zuweisung nicht. Ein Angreifer kann bei der Registrierung oder beim Edit einer bestehenden Account-Information ein zusätzliches Form-Feld usergroup[] mit dem UID einer privilegierten FE-User-Group mitsenden — das Property wird unbesehen am Model gesetzt und persistiert. Ergebnis: Self-Registrierung in eine FE-User-Group, die normalerweise nur über kontrollierte Wege erreichbar sein sollte.

Das ist eine klassische Mass-Assignment-Lücke — Symfony nennt das Pattern „über-aggressives Form-Mapping". Die Fix-Version sollte ein explizites allowedProperties- oder unsetProperty-Statement im Controller einsetzen, das die usergroup-Property aus dem incoming Request entfernt.

Zwei wiederkehrende Muster — was das Tag des 19. Mai über TYPO3-Extension-Hygiene sagt

Sechs Advisories an einem Tag sind viel, aber die strukturelle Beobachtung ist nicht „TYPO3 hat ein Problem", sondern „zwei seit Jahren bekannte Anti-Patterns treten in der Ext-Welt parallel auf":

Erstens: PHP-Object-Injection via unserialize() bei Angreifer-kontrollierten Daten. Sowohl ceselector als auch crawler nutzen unserialize() auf externen Bytes — der eine über ein Cookie, der andere über einen HTTP-Response-Header. Beides ist seit den frühen 2010ern als Anti-Pattern dokumentiert. Die saubere Lösung: entweder allowed_classes-Whitelist mitgeben oder ganz auf strukturierte Formate wie JSON umsteigen. Dass beide Extensions am selben Tag mit demselben Pattern auffliegen, ist nicht zufällig — wahrscheinlich hat ein Security-Researcher gezielt nach unserialize-Aufrufen in populären Extensions gesucht.

Zweitens: SQL-Injection durch String-Interpolation statt Parameter-Binding. news und tt_address machen denselben Fehler: Query-Konstruktion mit String-Konkatenation statt vorbereiteten Statements. Bei news exploit-bar, bei tt_address nur in Custom-Extension-Konstellationen. Auch das ist seit Doctrine DBAL und der TYPO3-QueryBuilder-API ein gelöstes Problem — der Fix ist meistens eine 5-Zeilen-Änderung von ->where("title LIKE '%" . $input . "%'") zu ->where("title LIKE :input")->setParameter('input', '%' . $input . '%').

Die ke_search-Dreierkette steht etwas außerhalb dieses Patterns — sie zeigt eine andere Lehre: Wenn eine Extension verschiedene Konfigurations-Knoten dem Backend-User exponiert, muss jeder dieser Knoten gegen Pfad- und Schema-Manipulation gehärtet sein.

Detection und Verifikation

Auch in einer Patch-Pipeline-gewarteten Umgebung ist die manuelle Verifikation pro Setup-Typ in 15 Minuten gemacht — und für Self-Hosted-Setups ohne Auto-Update sowieso Pflicht:

Welche Extensions sind installiert?

composer show 'tomasnorre/crawler' 'evoweb/sf-register' 'georgringer/news' \
              'tpwd/ke_search' 'friendsoftypo3/tt-address' 'mmc/ceselector' 2>/dev/null

Versionsspalte gegen die Fix-Liste oben abgleichen.

News-Configuration prüfen (CVE-2026-8726)

# Wo ist disableOverrideDemand gesetzt?
grep -rn 'disableOverrideDemand' typo3conf/ Configuration/ vendor/*/Configuration/

Wenn das Plugin aktiv ist und disableOverrideDemand nicht gesetzt ist: Update mit Prio High, oder zumindest disableOverrideDemand = 1 als Hot-Fix in TypoScript setzen.

ke_search-Indexer-Konfiguration prüfen (CVE-2026-46722/-46723/-46724)

SELECT uid, title, type, directories, additional_tables
  FROM tx_kesearch_indexerconfig
 WHERE deleted = 0 AND hidden = 0;

directories auf ..-Sequenzen prüfen; additional_tables auf Tabellen-Whitelist abgleichen; jede Configuration, die nicht zur erwarteten Site-Struktur passt, in der nächsten Backend-Session entfernen.

Betreiberempfehlung — Operativer Entscheidungsblock

Empfehlung nach Setup-Typ

Single-Tenant-TYPO3-Hosting mit Renovate

Kein operativer Handlungsdruck, Rollout läuft automatisch. Optionale Verifikation, dass die neue Version live ist: composer show <package> im Container, oder das Backend → Extension-Manager.

TYPO3 ohne Renovate, aber mit Composer-Mode

Heute Vormittag: composer update mmc/ceselector tomasnorre/crawler georgringer/news tpwd/ke_search friendsoftypo3/tt-address evoweb/sf-register --with-all-dependencies, gefolgt von vendor/bin/typo3 cache:flush und einem Worker-Restart.

TYPO3 im Classic-Mode (kein Composer)

Über den Extension-Manager im TYPO3-Backend pro Extension auf die Fix-Version updaten. Reihenfolge nach Severity: ceselector (Critical) → news (High) → crawler (High) → ke_search (Medium) → tt_address (Medium) → sf_register (Medium).

TYPO3 Long-Term-Support v11 / v12

Die Fix-Versionen für die älteren Lines sind ebenfalls verfügbar (siehe Versions-Tabelle pro Advisory). Composer-Constraints prüfen, dass die neue Patch-Version aufgenommen wird.

Wie wir bei Moselwal Advisory-Wellen behandeln

Bei Advisory-Wellen wie dem 19.-Mai-Cluster ist ein dreischichtiges Vorgehen sinnvoll — und genau dafür baut Moselwal seine Plattformen auf Auto-Update-fähigkeit aus:

Schicht 1: Patch-Pipeline erkennt die Releases. Eine Versions-Wächter-Pipeline (Renovate, Dependabot, Mend) prüft Composer-Pakete mehrmals täglich. Sobald die Advisory-Patches erscheinen, schiebt die Pipeline einen Merge-Request gegen die Image-Definition, die CI rebuildet das Image. Eine Critical-RCE wie ceselector wartet damit nicht auf den nächsten manuellen Pull.

Schicht 2: Rolling-Rebuild priorisiert nach Exposition. Sind die neuen Images verfügbar, läuft der Rollout gestaffelt. Reihenfolge: Stacks mit exploitable Konfiguration in einer der Critical/High-Severity-Lücken zuerst (ceselector mit Persistent-Static, news mit Date-Menu-Plugin ohne disableOverrideDemand), gefolgt vom Long Tail. Worker-Restarts (FrankenPHP, php-fpm, mod_php) sind graceful, der Service bleibt für Endnutzer ohne Unterbrechung.

Schicht 3: Audit-Pass über die Konfigurations-Lage. Parallel zum Rollout läuft ein Skript-Audit: welche Extension liegt auf welcher Version, welche kritischen Plugin-Settings sind aktiv, welche Backend-User haben Indexer-Konfig-Rechte. Das Ergebnis fließt in die nächste Wartungs-Routine — der Cluster wird also nicht nur „weggepatcht", sondern als Anlass für eine systematische Konfigurations-Review genutzt.

Wer eine TYPO3-Plattform betreut und eine vergleichbare Wellen-Routine aufsetzen will, findet im CTA unten den Einstieg.

Fazit

Sechs Advisories an einem Tag sind viel, aber strukturell nichts Neues. Zwei wiederkehrende Anti-Patterns (unserialize() auf untrusted Bytes, String-Interpolation in SQL-Queries) treffen auf eine ke_search-Dreierkette aus XXE, Path Traversal und Schema-Validation-Lücken. Die Critical-Lücke (ceselector) hat klare Exploit-Voraussetzungen, die News-SQLi ist die operativ wahrscheinlichste Massen-Bedrohung.

Für Stacks mit Auto-Update-Pipeline (Renovate, Dependabot o. ä.) fließen die Fix-Versionen ohne manuelles Eingreifen und ohne sichtbare Service-Unterbrechung in den Build. Für Self-Hosted-TYPO3-Setups ohne Auto-Update-Pipeline gilt die Reihenfolge oben: zuerst ceselector (Critical, unauthentisch), dann news (High, unauthentisch), dann crawler, dann ke_search, dann tt_address und sf_register. Bei aktiven Date-Menu-Plugins ohne disableOverrideDemand ist auch ein Hot-Fix-TypoScript ohne Composer-Update sinnvoll, um die Zeit bis zum Patch zu überbrücken.

Wer regelmäßig solche Wellen ohne Notschicht durchstehen möchte, sollte über eine Renovate-Anbindung oder vergleichbare Versions-Wächter nachdenken. Eine Disclosure-Welle wie diese hier wird in den kommenden Monaten nicht die letzte sein.