Skip to main content
Stopping PHP2SHELL: How SentinelOne Protects Customers From This Attack TechniqueRead More
Vulnerability Database/CVE-2026-107842

CVE-2026-107842: Contao CMS Information Disclosure Vulnerability

CVE-2026-107842 is an information disclosure flaw in Contao CMS that exposes protected page titles, URLs, and indexed content to unauthenticated users. This article covers the technical details, affected versions, and mitigation.

Published:

CVE-2026-107842 Overview

Contao is an Open Source content management system (CMS) used to build websites and web applications. CVE-2026-107842 is an information disclosure vulnerability in Contao's ModuleSearch component affecting versions 4.0.0 through 5.3.49 and 5.7.11. When administrators toggle the contao.search.index_protected setting from enabled to disabled, previously indexed protected content remains in the tl_search table without authorization filtering. Unauthenticated visitors can retrieve protected page titles, URLs, and indexed context snippets through search queries. The underlying protected pages still enforce authorization, so the issue exposes search metadata rather than granting direct page access. The flaw is tracked as CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.

Critical Impact

Unauthenticated attackers can harvest titles, URLs, and indexed text snippets from protected Contao pages via the public search module after an administrator disables protected indexing.

Affected Products

  • Contao CMS versions 4.0.0 through 5.3.49
  • Contao CMS 5.7.x versions prior to 5.7.12
  • Contao installations that previously enabled contao.search.index_protected and later disabled it

Discovery Timeline

  • 2026-10-09 - CVE-2026-107842 published to the National Vulnerability Database (NVD)
  • 2026-10-16 - Last updated in NVD database

Technical Details for CVE-2026-107842

Vulnerability Analysis

Contao's ModuleSearch queries the tl_search table to return matching documents to visitors. Each indexed row stores authorization metadata, including a protected flag and permitted member groups. When contao.search.index_protected is enabled, protected pages are added to the index and ModuleSearch applies a per-row filter that checks group membership before returning results.

When an administrator disables contao.search.index_protected, Contao stops indexing new protected pages but does not purge rows indexed while the setting was active. In the vulnerable code path, disabling the setting also removes the authorization filter from the result set. Protected rows remain queryable and are returned to unauthenticated visitors along with their titles, URLs, and context snippets.

Root Cause

The root cause is missing authorization enforcement on persisted index data in ModuleSearch. The filter that validates empty($v['protected']) or group membership was gated on the current value of contao.search.index_protected instead of the per-row protected attribute stored in tl_search. State drift between configuration and persisted data allowed stale protected entries to be served without checks.

Attack Vector

An unauthenticated attacker submits search queries to any public Contao site that previously indexed protected pages and later disabled protected indexing. The attacker iterates terms likely to match internal content, intranet pages, or member-only sections. Returned results reveal page titles, canonical URLs, and extracted text snippets. The protected pages themselves still return an authorization response when accessed directly, so the exposure is limited to search metadata and indexed content.

php
// Patch from core-bundle/contao/modules/ModuleSearch.php
// Source: https://github.com/contao/contao/commit/572686a113bca60f92cf2d0496cf3a74d0b6b457

                    return empty($v['protected']) || System::getContainer()->get('security.helper')->isGranted(ContaoCorePermissions::MEMBER_IN_GROUPS, StringUtil::deserialize($v['groups'] ?? null, true));
                });
            }
+           else
+           {
+               $objResult->applyFilter(static function ($v) {
+                   return empty($v['protected']);
+               });
+           }

            $count = $objResult->getCount();

The patch adds an else branch so that when protected indexing is disabled, ModuleSearch still filters out any row where the stored protected attribute is non-empty. This enforces authorization against persisted metadata rather than the current configuration flag.

Detection Methods for CVE-2026-107842

Indicators of Compromise

  • Unexpected search result pages returning titles or URLs that match member-only or back-end routes to unauthenticated clients.
  • High-volume search queries from a single IP address or user agent probing with internal keywords.
  • tl_search rows where the protected column is non-empty on a site whose current contao.search.index_protected setting is disabled.

Detection Strategies

  • Query tl_search for rows with protected != '' and correlate against the current contao.search.index_protected configuration value to identify stale protected entries.
  • Review web server access logs for repeated requests to the search module (for example, /search?keywords=) returning HTTP 200 with large response bodies to anonymous sessions.
  • Compare search response URLs to the sitemap of pages requiring login and alert on matches served without an authenticated session cookie.

Monitoring Recommendations

  • Instrument the Contao search endpoint to log the response count and sample URLs per query for anonymous visitors.
  • Add alerting for anonymous search queries that return results pointing to routes under protected page trees.
  • Monitor administrative changes to the contao.search.index_protected configuration and trigger an index audit whenever the value changes.

How to Mitigate CVE-2026-107842

Immediate Actions Required

  • Upgrade Contao to version 5.3.50 or 5.7.12 as soon as possible.
  • Rebuild the search index after upgrading to remove any residual protected entries from tl_search.
  • Audit anonymous search traffic for prior exploitation and identify which protected pages may have been enumerated.

Patch Information

The issue is fixed in Contao 5.3.50 and 5.7.12. The fix adds a filter in ModuleSearch that always excludes rows where the stored protected attribute is non-empty when protected indexing is disabled. See the GitHub Security Advisory GHSA-x2rp-9qf7-2fmq, the Contao 5.3.50 release, the Contao 5.7.12 release, and the upstream commit 572686a for details.

Workarounds

  • If upgrading is not immediately possible, truncate the tl_search and tl_search_index tables and rebuild the index with contao.search.index_protected disabled so no protected rows exist.
  • Keep contao.search.index_protected consistently enabled and ensure group-based access control is correctly configured so the per-row authorization filter applies.
  • Temporarily disable the public ModuleSearch module on pages that may have indexed protected content until the patched release is deployed.
bash
# Verify Contao version and apply the patched release via Composer
composer show contao/core-bundle | grep versions

# Upgrade to a patched 5.3.x release
composer require contao/core-bundle:^5.3.50 --with-all-dependencies

# Or upgrade to a patched 5.7.x release
composer require contao/core-bundle:^5.7.12 --with-all-dependencies

# Rebuild the search index after upgrade
php vendor/bin/contao-console contao:crawl

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne