Contao: Improper access control in the table access voter

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 TableAccessVoter::hasAccessToModule(), in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php:

    private array $canAccessTable = [];
    private array $canReadAccessTable = [];
 
    private function hasAccessToModule(TokenInterface $token, ...): bool
    {
        $tokenHash = hash('xxh128', serialize($token));
 
        if (isset($this->canAccessTable[$tokenHash]) || (...)) {
            return $this->canAccessTable[$tokenHash] ?? $this->canReadAccessTable[$tokenHash];
        }
 
        $table = $subject->getDataSource();
 
        foreach ($GLOBALS['BE_MOD'] as $modules) {
            ...
            return $this->canAccessTable[$tokenHash] = true;  // or false
        }
    }

The cache key, $tokenHash, is built only from the current user's security token. It does not include the table being checked. Because TableAccessVoter 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 correct for the second table.

This is made worse by , a low-priority, permissive fallback voter that grants access to any table-related permission unless another voter explicitly denies it. When gives a wrong "no opinion" answer because of the stale cache, this fallback voter turns that into a full grant.