TYPO3-EXT-SA-2026-025: Fünf CVEs in „Apache Solr for TYPO3“ — von Broken Access Control bis PHP Object Injection

TL;DR — 90 Sekunden

Betroffen?

Extension „Apache Solr for TYPO3“ (apache-solr-for-typo3/solr) in Version 11.6.5 und älter, 12.0.0 bis 12.1.3, sowie 13.0.0 bis 13.1.3.

Risiko?

Fünf CVEs (CVE-2026-56092 bis -56096): zwei Broken-Access-Control-Findings bei Indexer-Subrequests und Detail-View-Lookups, ein Information-Disclosure-Fund bei geteilten Solr-Cores (additionalFilters), PHP Object Injection über unserialize() bei Multi-Value-Feldern, und Information Disclosure durch Feldnamen-/Werte-Enumeration via Boolean-/Range-Techniken. TYPO3-Security-Team-Bewertung: CVSS v4.0 hoch.

Sofortmaßnahme?

Auf 11.6.6, 12.1.4 oder 13.1.4 aktualisieren, je nach eingesetzter Haupt-Version.

Empfehlung?

Zeitnah patchen, insbesondere bei mandantenfähigen Installationen mit geteilten Solr-Cores oder Frontend-Zugriffsbeschränkungen — mehrere der fünf Findings betreffen genau diese Konstellationen.

Kritikalität?

hoch — fünf eigenständige Schwachstellen in einer weit verbreiteten Search-Integration, darunter ein Deserialisierungs-Fund mit Object-Injection-Potenzial.

Was ist das Problem?

TYPO3-EXT-SA-2026-025 bündelt fünf inhaltlich unterschiedliche Schwachstellen in derselben Extension:

• CVE-2026-56092 (Broken Access Control): Die Extension erzwingt bei Indexer-Subrequests leere Frontend-Gruppen- und Subpage-Inheritance-Restriktionen auf Page-Records — dadurch können gecachte Seiten Zugriffsbeschränkungen umgehen, die im regulären Seitenaufruf gelten würden.
• CVE-2026-56093 (Broken Access Control): Detail-View-Dokument-Lookups prüfen weder siteHash noch Frontend-Nutzer-Zugriffsrechte, wodurch sich Dokumente über erratene Solr-Dokument-IDs abrufen lassen.
• CVE-2026-56094 (Information Disclosure): Der Parameter additionalFilters kann Filter registrieren, bevor der system-seitige siteHash in geteilten Solr-Cores angewendet wird — relevant vor allem bei Multi-Site- oder Multi-Mandanten-Setups mit gemeinsam genutztem Core.
• CVE-2026-56095 (Insecure Deserialization): Daten aus Multi-Value-Feldern durchlaufen PHPs unsicheres unserialize(), was eine PHP-Object-Injection-Angriffsfläche eröffnet — abhängig von vorhandenen Gadget-Chains im jeweiligen TYPO3-Stack potenziell bis hin zu Remote-Code-Ausführung.
• CVE-2026-56096 (Information Disclosure): Such-Query-Parameter erlauben es unauthentifizierten Angreifern, Feldnamen zu enumerieren und Werte über Boolean- und Range-basierte Techniken auszulesen — ein Muster, das an klassische Boolean-based Blind-Injection-Techniken erinnert, hier jedoch gegen die Solr-Such-API gerichtet.

In Summe zeigen die fünf Findings ein wiederkehrendes Muster: Die Integration zwischen TYPO3s Frontend-Zugriffsmodell (Frontend-Gruppen, siteHash) und dem separaten Solr-Index hält an mehreren Stellen nicht konsequent durch — wer sich auf TYPO3-seitige Zugriffsbeschränkungen verlässt, muss sicherstellen, dass diese auch im Solr-Index tatsächlich durchgesetzt werden.

Wer ist betroffen?

Installierte Version prüfen:

# per Composer
composer show apache-solr-for-typo3/solr | grep versions

# oder im TYPO3-Backend: Admin Tools → Erweiterungen → nach „solr“ filtern

Auswirkungen

Die fünf Findings wirken unterschiedlich stark, verstärken sich in Kombination aber gegenseitig. Die beiden Broken-Access-Control-Funde (-56092, -56093) können dazu führen, dass eigentlich zugriffsbeschränkte Inhalte — etwa Seiten hinter einer Frontend-Gruppen-Sperre — über den Such-Index oder erratene Dokument-IDs doch öffentlich auffindbar werden. Bei Redaktions-, Mitglieder- oder Kundenbereichen mit sensiblen Inhalten ist das ein direkter Vertraulichkeitsverlust, auch ohne dass der eigentliche TYPO3-Zugriffsschutz selbst gebrochen wird.

CVE-2026-56094 ist besonders für Hosting-Umgebungen relevant, die mehrere TYPO3-Instanzen oder Mandanten auf einem gemeinsamen Solr-Core betreiben — ein an sich sinnvolles Kosteneinsparungsmuster wird hier zum Risiko, wenn Filter der einen Instanz Daten einer anderen sichtbar machen können.

CVE-2026-56095 trägt das größte Eskalationspotenzial: PHP Object Injection über unserialize() ist grundsätzlich ein Schritt in Richtung Remote-Code-Ausführung, sofern im jeweiligen Composer-Dependency-Baum passende Gadget-Chains existieren — eine Bewertung, die sich nicht pauschal, sondern nur pro Installation treffen lässt.

CVE-2026-56096 ermöglicht unauthentifizierten Angreifern, sukzessive Struktur- und Inhaltsinformationen aus dem Index zu extrahieren — nützlich als Aufklärungsschritt für weitergehende Angriffe, auch wenn die Technik selbst „nur“ Information Disclosure ist.

Mitigation / Sofortmaßnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie „Apache Solr for TYPO3“ produktiv einsetzen und Frontend-Zugriffsbeschränkungen (Frontend-Gruppen) oder einen mit anderen Instanzen geteilten Solr-Core verwenden.
• Mit Priorität prüfen, wenn … Ihre Formulare oder Datenmodelle Multi-Value-Felder über die Solr-Integration indexieren.
• Im nächsten regulären Fenster, wenn … bereits auf 11.6.6, 12.1.4 oder 13.1.4 aktualisiert wurde.

Schritt 1 — Extension aktualisieren

# aktuelle Version prüfen
composer show apache-solr-for-typo3/solr | grep versions

# Update auf die passende Patch-Version je nach Hauptversion
composer require apache-solr-for-typo3/solr:^11.6.6   # TYPO3 11.x
composer require apache-solr-for-typo3/solr:^12.1.4   # TYPO3 12.x
composer require apache-solr-for-typo3/solr:^13.1.4   # TYPO3 13.x

# TYPO3-Caches nach dem Update leeren
vendor/bin/typo3 cache:flush

Schritt 2 — Such-Index neu aufbauen

Da CVE-2026-56092 und -56093 das Verhältnis zwischen TYPO3-Zugriffsrechten und indexierten Dokumenten betreffen, empfiehlt sich nach dem Update ein vollständiger Re-Index, damit veraltete, ggf. mit falschen Zugriffsattributen indexierte Dokumente ersetzt werden:

# vollständigen Solr-Index-Rebuild anstößen (Scheduler-Task oder CLI, je nach Konfiguration)
vendor/bin/typo3 solr:index --site=<site-identifier> --force

Schritt 3 — geteilte Solr-Cores prüfen

Falls mehrere TYPO3-Instanzen oder Mandanten einen gemeinsamen Solr-Core nutzen: nach dem Update gezielt prüfen, ob siteHash-Filter korrekt greifen, bevor Sie sich auf die geteilte Core-Architektur weiter verlassen.

Detection / Prüfung

Patch-Stand prüfen

composer show apache-solr-for-typo3/solr | grep versions

Auf Zugriffs-Anomalien im Index prüfen

Zu diesem konkreten Advisory waren zum Zeitpunkt dieses Beitrags keine öffentlich veröffentlichten Kompromittierungsindikatoren (IOCs) verfügbar. Als generische Prüfschritte, abgeleitet aus der Art der Findings:

# Solr-Access-/Query-Logs auf ungewöhnlich viele oder systematisch variierte
# Suchanfragen von einzelnen IPs prüfen (Hinweis auf Enumeration gemäß CVE-2026-56096)
grep "select?q=" /var/log/solr/solr_query.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# stichprobenhaft prüfen, ob Detail-View-Aufrufe mit fremden/erratenen Dokument-IDs
# Ergebnisse liefern, die eigentlich zugriffsbeschränkt sein sollten
# (manuelle Stichprobe je nach Frontend-Implementierung)

Multi-Value-Felder auf verdächtige serialisierte Inhalte prüfen

# Datenbank nach Feldinhalten mit Serialisierungs-Signaturen durchsuchen,
# die über die Solr-Indexierung eingespeist worden sein könnten
vendor/bin/typo3 database:query "SELECT uid, tablename FROM tx_solr_indexqueue_item WHERE errors != '' LIMIT 50"

Fehlerhafte Indexierungs-Einträge sind kein direkter Kompromittierungsnachweis, aber ein sinnvoller Ausgangspunkt für eine manuelle Nachschau, ob ungewöhnliche Daten in Multi-Value-Feldern verarbeitet wurden.

Betreiberempfehlung

Mid-Market

Zeitnah auf die passende Patch-Version aktualisieren und einen vollständigen Re-Index einplanen — außerhalb des nächsten regulären Wartungsfensters, wenn Frontend-Zugriffsbeschränkungen im Einsatz sind.

Enterprise / Multi-Site-Betreiber

Zusätzlich zum Update: geteilte Solr-Core-Architekturen gezielt auf korrekte siteHash-Filterung prüfen, Multi-Value-Felder auf verdächtige Inhalte durchsehen, und bei mehreren TYPO3-Instanzen ein zentrales Inventar der Solr-Extension-Version je Instanz führen — Sammelmeldungen wie diese betreffen erfahrungsgemäß selten nur eine einzelne Installation.

Agenturen mit TYPO3-Solr-Kundenprojekten

Proaktiv alle betreuten Installationen mit Solr-Integration identifizieren, priorisiert nach Installationen mit Frontend-Zugriffsbeschränkungen oder geteilten Cores, und das Update dort zuerst ausrollen.

Entscheidungsblock

Zeitnah handeln, wenn: Solr-Integration produktiv mit Frontend-Zugriffsbeschränkungen, geteilten Cores oder Multi-Value-Feldern im Einsatz ist. Reguläres Fenster genügt, wenn: bereits auf die gepatchte Version aktualisiert und keine der genannten Risikokonstellationen vorliegt.

Fazit

TYPO3-EXT-SA-2026-025 ist ein gutes Beispiel dafür, warum Such-Integrationen wie Solr eine eigene Sicherheitsbetrachtung verdienen, statt implizit über das TYPO3-Zugriffsmodell mitgeschützt zu gelten: Der separate Index kennt die Frontend-Zugriffslogik nur so gut, wie die Integration sie an mehreren Stellen konsequent durchsetzt — und genau dort setzen vier der fünf gemeldeten Findings an. Der fünfte, die Deserialisierungs-Lücke über unserialize(), erinnert daran, dass auch scheinbar reine Datenverarbeitungs-Pfade PHP-Object-Injection-Risiken tragen können. Ein Update auf 11.6.6, 12.1.4 oder 13.1.4 plus ein vollständiger Re-Index schließen alle fünf CVEs in einem Schritt — der Aufwand dafür steht in keinem Verhältnis zum Risiko, es zu unterlassen.

Quellen

• TYPO3.org — TYPO3-EXT-SA-2026-025: Multiple Vulnerabilities in extension „Apache Solr for TYPO3“ (25.08.2026)
• TYPO3 News — Security-Advisory-Volltext TYPO3-EXT-SA-2026-025
• TYPO3 News — Übersicht aller Security-Advisories
• TYPO3 Extension Repository (TER) — Apache Solr for TYPO3