Vulnerabilities

Vulnerability · CVE-2026-107851

Contao: Improper access control in the table access voter

Published Oct 9, 2026 · catalog updated Oct 9, 2026 · Contao: Improper access control

Check if you run it

No confirmed exploitation is on record for CVE-2026-107851. EPSS is 0.19%. Act only if a listed version of Contao: Improper access control is installed.

Severity

Medium4.3

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.19%

Remediation

Advisory link

Affected products

Packagist contao/core-bundle

Due to a caching defect in the security voter that governs table-level access to Contao's Data Container (DCA) backend, a low-privileged, non-admin backend user can obtain unauthorized read, create, update, and delete access to database tables outside their assigned module permissions. This includes tables containing sensitive personal data, such as frontend member records and newsletter subscriber e-mail addresses. ### Vulnerability Details In plain terms: Contao's backend is organized into modules (e.g. "News", "Members"). Every backend user is assigned to a group, and that group decides which modules, and therefore which database tables, they are allowed to work with. Before Contao lets a user touch a table, it is supposed to check: "does this user's group actually include this table?" To avoid doing that check over and over, Contao remembers the answer for the rest of the request. The problem is that it remembers the answer under the wrong label. Instead of remembering "is this user allowed to access table X", it only remembers "is this user allowed to access something", without recording which table the answer was actually about. So if a request first checks a table the user IS allowed to see, and then checks a second, completely different table the user is NOT allowed to see, Contao reuses the first answer for the second table too. The user ends up with access to a table their group was never given permission for. ### Technical detail Contao's backend enforces per-table access control through a chain of Symfony security voters. The relevant one is , in : The cache key, , is built only from the current user's security token. It does not include the table being checked. Because is a normal, shared Symfony service, this cache stays alive for the whole duration of one HTTP request. So the first table checked for a user in a request decides the cached answer for every other table checked afterwards in that same request, whether or not that answer is actually correc