CVE-2026-116895 in REDAXO
Summary
by MITRE • 10/27/2026
REDAXO before 5.21.5 contains a cross-site request forgery vulnerability because the backend processes the safemode GET parameter in index.php without validating a CSRF token. Attackers can lure a logged-in administrator into opening a crafted link to disable global safe mode, writing safe_mode: false to config.yml, or enable session safe mode, disabling backend addons.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in REDAXO versions prior to 5.21.5 represents a critical failure in access control mechanisms within the application's administrative interface. Specifically, this flaw is classified as a Cross-Site Request Forgery (CSRF) vulnerability that affects the backend processing logic found in index.php. The core technical issue stems from the system's handling of the safemode GET parameter without implementing adequate validation for CSRF tokens. In secure web applications, state-changing requests such as modifying configuration files or altering security settings must be protected by anti-CSRF mechanisms to ensure that the request originates from a legitimate user session rather than being forged by an external actor. The absence of this token verification allows any authenticated administrator's browser to execute unintended commands when they visit a maliciously crafted URL, effectively bypassing the intended authorization checks for sensitive configuration changes.
From a technical perspective, the exploitation vector relies on social engineering tactics where an attacker lures a logged-in administrator into accessing a specially constructed link or webpage hosted by the adversary. When the administrator's browser processes this request while maintaining their active session cookies with REDAXO, the server accepts the safemode parameter modification as valid because it lacks the necessary cryptographic proof of user intent. This allows the attacker to manipulate two distinct security configurations within the CMS. First, an attacker can force the system to write safe_mode: false into the config.yml file, which disables global safe mode protections. Second, they can enable session-safe mode in a manner that inadvertently disables backend addons, potentially removing critical administrative tools or monitoring capabilities that rely on these extensions for proper functionality and security oversight.
The operational impact of this vulnerability is severe due to its potential to escalate into broader system compromise. Disabling global safe mode removes the sandboxing restrictions that typically limit what scripts can execute within the CMS environment. This exposure allows an attacker who has already gained a foothold or influenced configuration settings to potentially inject and execute arbitrary code, access sensitive data files, or modify database contents without restriction. Furthermore, by disabling backend addons through session manipulation, the attacker may blind administrators to ongoing malicious activities or remove security plugins that would otherwise detect and block further exploitation attempts. This combination of effects significantly lowers the barrier for subsequent attacks such as remote code execution, data exfiltration, or complete defacement of the website infrastructure.
This vulnerability aligns with CWE-352, which describes Cross-Site Request Forgery, specifically highlighting the lack of anti-CSRF tokens in state-changing operations. It also relates to CWE-693, Protection Mechanism Failure, as the system fails to enforce security policies against forged requests. In terms of offensive cybersecurity frameworks, this attack vector maps to MITRE ATT&CK technique T1087, Account Discovery, and potentially T1542, System Configuration Modification, depending on how the disabled safe mode is leveraged for persistence or privilege escalation. The vulnerability underscores the importance of strict input validation and session integrity checks in all administrative endpoints that modify critical system configurations.
To mitigate this risk, administrators must upgrade REDAXO to version 5.21.5 or later where these CSRF protections have been implemented. For systems that cannot be immediately updated, temporary mitigations include ensuring that no untrusted users can access the backend interface and implementing network-level controls such as restricting direct HTTP requests from unknown origins if possible. Additionally, enabling strict Content Security Policy headers and verifying session integrity on all configuration-modifying endpoints can provide layered defense against similar CSRF exploits in other parts of the application ecosystem. Regular security audits focusing on authentication flows for administrative actions are essential to prevent recurrence of this class of vulnerabilities.