CVE-2026-115935 in Craft CMS
Summary
by MITRE • 10/24/2026
The app/process-api-response-headers action accepts fake Craft API response headers from any authenticated control panel user.
A non-admin user with only accessCp can place newline characters in X-Craft-Plugin-Licenses. Craft passes this value to its .env writer without removing the newlines.
This lets the user insert a new attacker-known CRAFT_SECURITY_KEY into .env. After Craft loads that key, the user can forge a signed login redirect containing a Twig system() callback.
This is different from the previous report. That report reads the existing key through a Twig sandbox bypass. This report replaces the key through fake API headers and CRLF injection. Fixing either source does not fix the other.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified in Craft CMS involves a critical flaw within the app/process-api-response-headers action, which allows authenticated non-administrative users to manipulate environment configuration files through crafted HTTP response headers. Specifically, this issue affects users who possess only accessCp permissions, granting them limited control panel access but insufficient privileges for administrative tasks under normal circumstances. The core technical failure lies in the handling of the X-Craft-Plugin-Licenses header value during its processing by the application's environment writer component. When a user submits request data containing newline characters within this specific header field, Craft CMS fails to sanitize or strip these control characters before writing them to the .env configuration file. This lack of input validation constitutes an Environment Variable Injection vulnerability, allowing attackers to inject arbitrary content into sensitive system files that dictate application security parameters.
The operational impact of this flaw is severe because it enables a complete compromise of the application's authentication and execution integrity. By injecting newline characters, an attacker can effectively break out of the intended configuration line structure within the .env file. This structural breach allows the insertion of a new CRAFT_SECURITY_KEY value that is known to the attacker. The Craft security key is fundamental to generating signed tokens for session management and login redirects. Once the application reloads its environment variables, it begins using this maliciously injected key instead of the original secure one. Consequently, an authenticated user can forge valid-signed login redirect URLs containing arbitrary Twig code execution payloads. This effectively bypasses authentication controls and leads to Remote Code Execution via a system() callback within the Twig templating engine, granting full control over the underlying server infrastructure.
This specific attack vector differs significantly from previous reports involving Craft CMS vulnerabilities that relied on sandbox escapes to read existing security keys. While prior exploits focused on information disclosure through template injection flaws, this vulnerability focuses on configuration manipulation and key replacement via CRLF (Carriage Return Line Feed) injection techniques. The distinction is crucial because remediation efforts targeting only the Twig sandbox or input sanitization for display purposes will not mitigate this specific threat. Fixing one source does not address the other, meaning that a comprehensive security posture requires addressing both the template engine restrictions and the strict validation of all inputs written to system configuration files. This dual-vector nature highlights the complexity of securing applications where user-controlled data influences critical infrastructure configurations.
From a classification perspective, this vulnerability aligns with CWE-15: External Control of System or Configuration Setting, as it involves an attacker modifying essential application settings through external input. Additionally, the exploitation path relates to CWE-78: Improper Neutralization of Special Elements used in an OS Command, given that the ultimate goal is achieving code execution via system() calls facilitated by forged tokens. In terms of the MITRE ATT&CK framework, this activity maps to T1505.003: Web Shell: Custom Scripting Language and potentially T1078: Valid Accounts if we consider the initial authenticated access as part of the persistence or privilege escalation chain leading to code execution. The attack leverages valid credentials but abuses their limited scope to achieve disproportionate impact through configuration tampering rather than direct permission elevation.
Mitigation strategies must focus on rigorous input validation and output encoding for all data written to environment files. Developers should implement strict allow-listing of acceptable characters in headers that influence system configurations, ensuring that control characters such as newlines are either rejected or safely neutralized before being processed by the .env writer. Furthermore, implementing principle of least privilege checks at the point of writing configuration changes can prevent non-admin users from altering critical security parameters like CRAFT_SECURITY_KEY regardless of input sanitization failures. Regular audits of environment file handling logic and integration testing with fuzzed inputs containing special characters are essential to detect similar injection points in other parts of the application stack. Security teams should also monitor for unusual patterns in login redirect tokens that might indicate forged signatures resulting from compromised security keys.