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
- Products
- contao/core-bundle
- Affected versions
- 5.7.0, 5.7.1, 5.7.10, 5.7.11, 5.7.2, 5.7.3, 5.7.4, 5.7.5, 5.7.6, 5.7.7, 5.7.8, 5.7.9
- Fixed versions
- 5.7.12
- CVEs
- CVE-2026-107851
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 28 Oct 2026, 13:04 UTC · Revision 1
Source evidence
Contao: Improper access control in the table access voter
core-osv · Original sourcePublished 9 Oct 2026, 20:53 UTC
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
osv:GHSA-5974-gfqc-wrcm
contao/core-bundle
Fixed versions: 5.7.12
Complete source record
{
"id": "9337e58fa10c9c4eaeaf879ef925f9a30a7670b3fd961e868b115bbe8380aa6a",
"url": "https://osv.dev/vulnerability/GHSA-5974-gfqc-wrcm",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Contao: Improper access control in the table access voter",
"summary": "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",
"evidence": "osv:GHSA-5974-gfqc-wrcm",
"products": [
{
"name": {
"value": "contao/core-bundle",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.7.12",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": [
{
"value": "5.7.0",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.1",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.10",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.11",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.2",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.3",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.4",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.5",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.6",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.7",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.8",
"evidence": "/affected/0/versions"
},
{
"value": "5.7.9",
"evidence": "/affected/0/versions"
}
]
}
],
"severity": "medium",
"structured": {
"id": "GHSA-5974-gfqc-wrcm",
"aliases": [
"CVE-2026-107851",
"GHSA-5974-gfqc-wrcm"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.7.0"
},
{
"fixed": "5.7.12"
}
]
}
],
"package": {
"name": "contao/core-bundle",
"purl": "pkg:composer/contao/core-bundle",
"ecosystem": "Packagist"
},
"versions": [
"5.7.0",
"5.7.1",
"5.7.10",
"5.7.11",
"5.7.2",
"5.7.3",
"5.7.4",
"5.7.5",
"5.7.6",
"5.7.7",
"5.7.8",
"5.7.9"
],
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-5974-gfqc-wrcm/GHSA-5974-gfqc-wrcm.json"
}
}
],
"modified": "2026-10-09T21:00:08.462529572Z",
"provider": "osv",
"references": [
"https://github.com/contao/contao/security/advisories/GHSA-5974-gfqc-wrcm",
"https://github.com/contao/contao/commit/9d6f582a4cc6a758ce11d1043fc9c0ba62c5f4c9",
"https://github.com/contao/contao",
"https://github.com/contao/contao/releases/tag/5.7.12"
],
"provider_metadata": {
"cwe_ids": [
"CWE-524",
"CWE-863"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": null,
"github_reviewed_at": "2026-10-09T20:53:42Z"
}
},
"related_cves": [
{
"value": "CVE-2026-107851",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 124165,
"published_at": "2026-10-09T20:53:42+00:00"
}