CVE-2026-107851
Executive Summary
CVE-2026-107851 is an authorization bypass vulnerability in the Contao open-source content management system, affecting versions 5.7.0 through 5.7.11. The flaw resides in the caching logic of TableAccessVoter::hasAccessToModule() within core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php, where authorization decisions are cached using only a hash of the user's security token, omitting the target table identifier. A low-privileged authenticated backend user can exploit this caching collision to read, create, update, or delete records in database tables outside their assigned module permissions, including tables containing member or newsletter-subscriber data. The vendor states the issue is fixed in version 5.7.12; patch confidence is rated 2/4 (CLAIMED) pending independent confirmation.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
CVE-2026-107851 is classified as CWE-524: Use of Cache Containing Sensitive Information — more precisely an improper cache-key construction issue within an authorization decision cache. Contao's security architecture uses Symfony's voter system. TableAccessVoter is responsible for deciding whether the current security token (the authenticated user) is permitted to access a given database table (data container). The hasAccessToModule() method caches its authorization decision using only $tokenHash — a hash derived from the user's security token. The cache key does not incorporate the table name returned by getDataSource().
Because the table identity is excluded from the cache key, the first authorization decision for a given user's token is stored and subsequently reused for any table that user attempts to access within the same token lifecycle / cache scope. If an attacker (a low-privileged backend user) triggers an access check against a table they are permitted to read, that "allowed" result is cached under their token hash. A subsequent check against a table they should not be able to read (e.g., tl_member or tl_newsletter_recipients) reuses the cached "allowed" result.
The NVD description further states that DefaultDataContainerVoter "can convert an incorrect abstention into a grant." In Symfony's voter framework, voters may return ACCESS_GRANTED, ACCESS_DENIED, or ACCESS_ABSTAIN. When an incorrect abstention occurs (because the cached decision bypassed the intended code path), DefaultDataContainerVoter's fallback logic appears to resolve abstention to a grant rather than a denial, compounding the flaw. The net effect is that the access-control decision is effectively inverted in the attacker's favor: a denied table is treated as allowed.
Attack surface: the Contao backend (authenticated administrative interface), reachable over the network (AV:N). No user interaction is required (UI:N) once the attacker has a valid low-privileged account (PR:L). The primary vulnerability class is authorization bypass via improper cache key scoping.
Insufficient technical detail is available to specify the exact HTTP endpoints or data-container callback routes involved; the description only names the voter class, method, file path, $tokenHash, and getDataSource().
Exploitation Scenarios
No public PoC is available; the attack chain below is inferred strictly from the NVD description and the vulnerability class (authorization bypass via cache-key collision). No function names, endpoints, or parameters are fabricated beyond those present in the source data.
Reconnaissance / target identification. The attacker requires a valid low-privileged backend account on a Contao 5.7.0–5.7.11 instance. The attacker enumerates which backend modules/tables their account is permitted to access (a legitimate "allowed" table check) and identifies target tables they are not permitted to access — e.g., member data (
tl_member) or newsletter subscriber data (tl_newsletter_recipients).Triggering the flaw class. Within the same security-token scope, the attacker first performs an operation that causes
TableAccessVoter::hasAccessToModule()to evaluate and cache an allowed decision for their token against a permitted table. Because the cache key is derived solely from$tokenHash, this "allowed" decision is now stored without any table-scoping.Payload / execution method at the vulnerability-class level. The attacker then attempts an operation against a table they are not authorized for. The voter's cached entry for
$tokenHashis reused, returning the previously cached "allowed" result for the wrong table. Where the incorrect vot
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.