TYPO3-EXT-SA-2026-025: Five CVEs in “Apache Solr for TYPO3” — from broken access control to PHP object injection

TL;DR — 90 seconds

Affected?

The “Apache Solr for TYPO3” extension (apache-solr-for-typo3/solr) in version 11.6.5 and earlier, 12.0.0 through 12.1.3, and 13.0.0 through 13.1.3.

Risk?

Five CVEs (CVE-2026-56092 through -56096): two broken-access-control findings around indexer sub-requests and detail-view lookups, an information-disclosure finding around shared Solr cores (additionalFilters), PHP object injection via unserialize() on multi-value fields, and information disclosure through field-name/value enumeration via boolean/range techniques. TYPO3 security team rating: CVSS v4.0 high.

Immediate action?

Update to 11.6.6, 12.1.4, or 13.1.4, depending on the major version you run.

Recommendation?

Patch promptly, especially for multi-tenant installations with shared Solr cores or frontend access restrictions — several of the five findings target exactly these setups.

Criticality?

high — five independent vulnerabilities in a widely used search integration, including a deserialization finding with object-injection potential.

What is the problem?

TYPO3-EXT-SA-2026-025 bundles five substantively different vulnerabilities in the same extension:

• CVE-2026-56092 (Broken Access Control): during indexer sub-requests, the extension forces empty frontend-group and subpage-inheritance restrictions onto page records — which lets cached pages bypass access restrictions that would apply on a regular page request.
• CVE-2026-56093 (Broken Access Control): detail-view document lookups check neither siteHash nor frontend user access rights, allowing documents to be retrieved via guessed Solr document IDs.
• CVE-2026-56094 (Information Disclosure): the additionalFilters parameter can register filters before the system-side siteHash is applied in shared Solr cores — relevant above all in multi-site or multi-tenant setups sharing a core.
• CVE-2026-56095 (Insecure Deserialization): data from multi-value fields passes through PHP's unsafe unserialize(), opening up a PHP object injection attack surface — depending on gadget chains present in the given TYPO3 stack, potentially escalating up to remote code execution.
• CVE-2026-56096 (Information Disclosure): search query parameters let unauthenticated attackers enumerate field names and extract values via boolean- and range-based techniques — a pattern reminiscent of classic boolean-based blind injection techniques, here directed at the Solr search API.

Taken together, the five findings show a recurring pattern: the integration between TYPO3's frontend access model (frontend groups, siteHash) and the separate Solr index doesn't hold consistently in several places — anyone relying on TYPO3-side access restrictions needs to make sure they're actually enforced in the Solr index too.

Who is affected?

Check your installed version:

# via Composer
composer show apache-solr-for-typo3/solr | grep versions

# or in the TYPO3 backend: Admin Tools → Extensions → filter for "solr"

Impact

The five findings vary in severity but reinforce each other in combination. The two broken-access-control findings (-56092, -56093) can cause content that should be access-restricted — for example, pages behind a frontend-group lock — to become publicly discoverable after all, via the search index or guessed document IDs. For editorial, member, or customer areas with sensitive content, that's a direct confidentiality loss even without TYPO3's actual access control itself being broken.

CVE-2026-56094 is especially relevant for hosting environments running multiple TYPO3 instances or tenants on a shared Solr core — an otherwise sensible cost-saving pattern turns into a risk here if one instance's filters can expose another instance's data.

CVE-2026-56095 carries the greatest escalation potential: PHP object injection via unserialize() is fundamentally a step toward remote code execution, provided matching gadget chains exist somewhere in the given Composer dependency tree — an assessment that can't be made generically, only per installation.

CVE-2026-56096 lets unauthenticated attackers progressively extract structural and content information from the index — useful as a reconnaissance step for further attacks, even though the technique itself is "only" information disclosure.

Mitigation / immediate steps

Operational decision block

• Act now if … you run “Apache Solr for TYPO3” in production and use frontend access restrictions (frontend groups) or a Solr core shared with other instances.
• Check with priority if … your forms or data models index multi-value fields through the Solr integration.
• Next regular window if … you've already updated to 11.6.6, 12.1.4, or 13.1.4.

Step 1 — update the extension

# check current version
composer show apache-solr-for-typo3/solr | grep versions

# update to the matching patch version for your major version
composer require apache-solr-for-typo3/solr:^11.6.6   # TYPO3 11.x
composer require apache-solr-for-typo3/solr:^12.1.4   # TYPO3 12.x
composer require apache-solr-for-typo3/solr:^13.1.4   # TYPO3 13.x

# flush TYPO3 caches after the update
vendor/bin/typo3 cache:flush

Step 2 — rebuild the search index

Since CVE-2026-56092 and -56093 concern the relationship between TYPO3 access rights and indexed documents, a full re-index after updating is recommended, so any stale documents indexed with incorrect access attributes get replaced:

# trigger a full Solr index rebuild (scheduler task or CLI, depending on your setup)
vendor/bin/typo3 solr:index --site=<site-identifier> --force

Step 3 — review shared Solr cores

If multiple TYPO3 instances or tenants share a Solr core: after updating, specifically verify that siteHash filters are applied correctly before continuing to rely on the shared-core architecture.

Detection / verification

Check patch status

composer show apache-solr-for-typo3/solr | grep versions

Check for access anomalies in the index

No publicly published indicators of compromise (IOCs) specific to this advisory were available as of this post. As generic checks derived from the nature of the findings:

# check Solr access/query logs for unusually many or systematically varied
# search queries from individual IPs (a sign of enumeration per CVE-2026-56096)
grep "select?q=" /var/log/solr/solr_query.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# spot-check whether detail-view calls with foreign/guessed document IDs
# return results that should actually be access-restricted
# (manual sampling, depending on your frontend implementation)

Check multi-value fields for suspicious serialized content

# search the database for field content with serialization signatures
# that may have been fed in through Solr indexing
vendor/bin/typo3 database:query "SELECT uid, tablename FROM tx_solr_indexqueue_item WHERE errors != '' LIMIT 50"

Failed indexing entries aren't direct proof of compromise, but they're a reasonable starting point for manually checking whether unusual data was processed in multi-value fields.

Operator guidance

Mid-market

Update to the matching patch version promptly and schedule a full re-index — outside the next regular maintenance window if frontend access restrictions are in use.

Enterprise / multi-site operators

Beyond the update: specifically verify shared Solr core architectures for correct siteHash filtering, review multi-value fields for suspicious content, and maintain a central inventory of the Solr extension version per instance if you run multiple TYPO3 instances — combined advisories like this one rarely affect just a single installation in practice.

Agencies with TYPO3/Solr client projects

Proactively identify all managed installations with a Solr integration, prioritized by installations with frontend access restrictions or shared cores, and roll out the update there first.

Decision block

Act promptly if: a Solr integration is running in production with frontend access restrictions, shared cores, or multi-value fields. The regular window is enough if: you've already updated to the patched version and none of the risk factors above apply.

Conclusion

TYPO3-EXT-SA-2026-025 is a good illustration of why search integrations like Solr deserve their own security scrutiny rather than being implicitly assumed to inherit TYPO3's access model: the separate index only knows the frontend access logic as well as the integration consistently enforces it across every relevant point — and that's exactly where four of the five reported findings sit. The fifth, the deserialization flaw via unserialize(), is a reminder that even seemingly plain data-processing paths can carry PHP object injection risk. An update to 11.6.6, 12.1.4, or 13.1.4 plus a full re-index closes all five CVEs in one step — the effort is nowhere near proportional to the risk of skipping it.

Sources

• TYPO3.org — TYPO3-EXT-SA-2026-025: Multiple Vulnerabilities in extension “Apache Solr for TYPO3” (Aug 25, 2026)
• TYPO3 News — full advisory text for TYPO3-EXT-SA-2026-025
• TYPO3 News — overview of all security advisories
• TYPO3 Extension Repository (TER) — Apache Solr for TYPO3