Vulnerability Overview

The 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.

Attack Techniques

1. Field Enumeration via field:*

By appending a wildcard to an arbitrary or guessed field name, an attacker can verify if the field exists within the schema:

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.

2. Blind Value Extraction via Prefix Wildcards

Attackers can extract sensitive field values character-by-character using boolean inference:

3. Length Detection via the ? Operator

The single-character wildcard operator (?) can determine the exact length of a stored string before starting character iteration:

4. Accelerated Range Queries ([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:

Combining length detection, range queries, and prefix wildcards allows full field extraction with a minimal request footprint.

Impact

• Confidentiality Violation: Full extraction of all fields indexed in Apache Solr (e.g., internal system hashes, hidden page content, user-related metadata, and system identifiers).
• Access Control Bypass: Bypasses frontend search filters and TypoScript display restrictions.
• Scope: Affected all default installations utilizing the EXT:solr search endpoint.

Remediation

Global character escaping is insufficient because operators like * and : serve intended search features. Remediation requires an application-layer whitelist and parsing model:

1. Parse user-supplied query strings into an Abstract Syntax Tree (AST) before dispatching to the Solr engine.
2. Enforce strict allowlists on permissible field targets, disallowing direct user queries against internal or restricted fields.
3. Neutralize non-whitelisted operator abuse originating from untrusted input contexts.

Coordinated Disclosure Timeline

• March 6, 2026: Identified vulnerability during an authorized assessment; initial vendor notification.
• April 17, 2026: Vendor implemented local edge mitigations; confirmed upstream bug nature.
• May 8, 2026: Formal vulnerability report submitted to the TYPO3 Security Team ([email protected]).
• June 15, 2026: TYPO3 Security Team confirmed reproduction and initiated patch development with extension maintainers.
• August 25, 2026: Official security bulletin issued, patch published, and CVE-2026-56096 assigned.

References

• TYPO3 Security Advisory: TYPO3-EXT-SA-2026-025
• CWE Definition: CWE-943: Improper Neutralization of Special Elements in Data Query Logic