CVE-2026-107848

Contao is an Open Source CMS. From version 4.0.0 until 5.3.50 and 5.7.12, RequestTokenListener validates REQUEST_TOKEN only for POST requests, while the declarative GET guard runs only when an act parameter is present. Backend actions dispatched through the key parameter can therefore execute without a CSRF token when an authenticated backend user loads an attacker-controlled URL. Reachable actions remain limited to modules available to that user, and the advisory demonstrates destructive or state-changing actions rather than privilege escalation. This issue is fixed in versions 5.3.50 and 5.7.12.

Contao is an Open Source CMS. From version 4.0.0 until 5.3.50 and 5.7.12, RequestTokenListener validates REQUEST_TOKEN only for POST requests, while the declarative GET guard runs only when an act parameter is present. Backend actions dispatched through the key parameter can therefore execute without a CSRF token when an authenticated backend user loads an attacker-controlled URL. Reachable actions remain limited to modules available to that user, and the advisory demonstrates destructive or state-changing actions rather than privilege escalation. This issue is fixed in versions 5.3.50 and 5.7.12.

RequestTokenListener is the only generic REQUEST_TOKEN validator in Contao and it only runs on POST. On the GET side the guard is local and declarative, and it only fires when an act parameter is present. Every back end action dispatched through a different parameter therefore has no CSRF protection at all. This is a family rather than a single bug.

Impact

An attacker who gets a logged in back end user to load a URL performs back end actions as that user, with no token and no confirmation. Because the exposure follows from the dispatch mechanism rather than from one callback, every present and future key= action inherits it.

Honest bound. The victim must be authenticated in the back end and must load the URL, and the reachable actions are limited to the modules that user can access. We have not found a key= action that grants privileges; the ones we verified are destructive or state changing rather than escalating.

Contao is an Open Source CMS. From version 4.0.0 until 5.3.50 and 5.7.12, RequestTokenListener validates REQUEST_TOKEN only for POST requests, while the declarative GET guard runs only when an act parameter is present. Backend actions dispatched through the key parameter can therefore execute without a CSRF token when an authenticated backend user loads an attacker-controlled URL. Reachable actions remain limited to modules available to that user, and the advisory demonstrates destructive or state-changing actions rather than privilege escalation. This issue is fixed in versions 5.3.50 and 5.7.12.

Contao is an Open Source CMS. From version 4.0.0 until 5.3.50 and 5.7.12, RequestTokenListener validates REQUEST_TOKEN only for POST requests, while the declarative GET guard runs only when an act parameter is present. Backend actions dispatched through the key parameter can therefore execute without a CSRF token when an authenticated backend user loads an attacker-controlled URL. Reachable actions remain limited to modules available to that user, and the advisory demonstrates destructive or state-changing actions rather than privilege escalation. This issue is fixed in versions 5.3.50 and 5.7.12.

RequestTokenListener is the only generic REQUEST_TOKEN validator in Contao and it only runs on POST. On the GET side the guard is local and declarative, and it only fires when an act parameter is present. Every back end action dispatched through a different parameter therefore has no CSRF protection at all. This is a family rather than a single bug.

Impact

An attacker who gets a logged in back end user to load a URL performs back end actions as that user, with no token and no confirmation. Because the exposure follows from the dispatch mechanism rather than from one callback, every present and future key= action inherits it.

Honest bound. The victim must be authenticated in the back end and must load the URL, and the reachable actions are limited to the modules that user can access. We have not found a key= action that grants privileges; the ones we verified are destructive or state changing rather than escalating.