CVE-2026-117536 in Redaxo
Summary
by MITRE • 10/27/2026
REDAXO before 5.21.3 contains a cross-site request forgery vulnerability in the backend user administration page (users/users) because the CSRF token check only runs when the save parameter is set, while the update path triggered by FUNC_UPDATE does not require it. Attackers can lure a logged-in backend user with the users[] permission to a crafted GET link to grant administrator rights, deactivate accounts, or lock out the sole administrator.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in REDAXO versions prior to 5.21.3 represents a critical authentication bypass mechanism rooted in improper implementation of Cross-Site Request Forgery protections within the backend user administration interface. Specifically, the flaw resides in the logic governing state-changing operations on the users/users page. The application’s security model incorrectly assumes that validating the CSRF token is sufficient when triggered via standard form submissions with specific parameters. However, the underlying code path associated with the FUNC_UPDATE action does not enforce this validation check. This architectural oversight creates a significant gap where authenticated sessions can be manipulated by an attacker to perform unauthorized administrative actions without the user's knowledge or consent.
From a technical perspective, the root cause is classified under CWE-352, which denotes Cross-Site Request Forgery (CSRF). The vulnerability arises because the server-side validation logic fails to verify the presence and validity of a unique CSRF token for all state-modifying requests. By exploiting this gap, an attacker can craft a malicious GET request that mimics legitimate administrative updates. Since the application processes these requests based on the FUNC_UPDATE parameter without checking for anti-CSRF tokens, any logged-in user with sufficient privileges to access the users page is tricked into executing commands they did not intend to perform. This bypasses the intended security controls designed to prevent unauthorized state changes initiated from external sources.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and account compromise. An attacker can lure a victim with administrative or user management permissions to visit a crafted URL, resulting in immediate exploitation without further interaction. The consequences include granting administrator rights to the attacker’s controlled account, deactivating legitimate user accounts which may disrupt business operations, or locking out the sole system administrator by modifying their password or disabling their access. This effectively allows an unauthenticated external party to take full control of the REDAXO installation, leading to a complete compromise of confidentiality, integrity, and availability for any content managed through the platform.
In terms of threat modeling, this attack vector aligns with MITRE ATT&CK technique T1098, specifically Account Manipulation, where adversaries alter existing accounts to maintain access or escalate privileges. It also relates to T1548, Abuse Elevation Control Mechanism, as it exploits a flaw in the system's elevation controls to gain higher-level permissions than originally granted. The simplicity of the attack method means that social engineering tactics are sufficient for exploitation, making it particularly dangerous against organizations with less security-aware administrative staff who may click on seemingly benign links while logged into their CMS backend.
To mitigate this vulnerability, immediate patching is required by upgrading REDAXO to version 5.21.3 or later, where the developers have corrected the logic to ensure CSRF token validation applies consistently across all update operations, including those triggered via FUNC_UPDATE. In environments where immediate patching is not feasible, temporary mitigations should include restricting access to the backend interface through IP whitelisting if possible, implementing strict Content Security Policy headers that limit referrer information leakage, and ensuring that no single user holds sole administrative privileges to prevent total lockout scenarios. Regular security audits of form handling logic are also recommended to identify similar inconsistencies in other modules where state changes might be susceptible to forgery attacks due to incomplete token validation coverage.