EXT:solr TYPO3 CVE-2026-56094

Exploitation requires a specific, non-default deployment configuration: multiple TYPO3 sites must share a single Apache Solr core rather than each site operating its own isolated core - this is the AT:P prerequisite in the CVSS 4.0 vector. The additionalFilters HTTP parameter must be accepted by the TYPO3 frontend without sanitization, which is the default EXT:solr behavior. The suggest top-results path is exploitable as a secondary vector only when the suggest feature is explicitly enabled in EXT:solr configuration. No authentication is required (PR:N), and no victim user interaction is needed beyond the attacker's own crafted request (UI:N). Exploitation is fully mitigated for any TYPO3 installation using per-site dedicated Solr cores. Impact is also bounded: only documents already publicly indexed in the shared Solr core are exposed; private, access-restricted, or non-indexed TYPO3 content is not reachable through this vulnerability.

The CVSS 4.0 base score of 6.3 (Medium) reflects a network-reachable, unauthenticated vector (AV:N, PR:N) constrained by high attack complexity (AC:H) and a specific deployment prerequisite (AT:P): the target must run multiple TYPO3 sites sharing a single Solr core, which is a non-default but operationally common pattern in managed and multi-tenant hosting environments. The impact is bounded to low confidentiality (VC:L) - only public, already-indexed documents from a co-located site are reachable; no integrity or availability degradation is possible. No EPSS score was provided in source data, and the CVE carries no CISA KEV listing and no identified POC, indicating no confirmed active exploitation at time of analysis. The practical risk is a multi-tenancy data boundary violation: operators running isolated single-site Solr deployments are entirely unaffected, while multi-site shared-core deployments face a meaningful, zero-authentication leakage path bounded only by what is publicly indexed. Shared-hosting providers and enterprises running multi-site TYPO3 on a common Solr core should prioritize remediation despite the medium score, given the absence of any authentication barrier once the deployment prerequisite is met.

An unauthenticated visitor to TYPO3 Site A crafts an HTTP search request containing an additionalFilters parameter that pre-registers a siteHash value corresponding to TYPO3 Site B, which shares the same Solr core. Because the query builder does not overwrite the pre-registered named filter, the system-applied siteHash for Site A is ignored, and the Solr response returns publicly indexed documents belonging to Site B. No public exploit code has been identified at time of analysis, but the mechanics are straightforward once an attacker confirms the shared-core deployment through response content or error messages.