Control panel only API response emulation replaces "securityKey" and reaches server RCE
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.11.2, 4.18.9
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The vulnerability affects Craft CMS, a content management system, and allows a control panel user with only basic access to inject a new security key and potentially execute arbitrary commands on the server. The flaw lies in how the application processes fake API response headers, which lets authenticated users modify the configuration file that stores the security key.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- craftcms/cms
From 5.0.0 · fixed in 5.11.2; From 4.0.0 · fixed in 4.18.9