CVE-2024-56145 is a code injection vulnerability in Craft CMS Craft CMS. CISA added it to the Known Exploited Vulnerabilities catalogue on 2 June 2025, which means attackers have used it in real attacks. Craft CMS contains a code injection vulnerability. Users with affected versions are vulnerable to remote code execution if their php.ini configuration has `register_argc_argv` enabled.
What this vulnerability class means for Craft CMS
Code injection means attacker-controlled input reaches code execution paths, so the issue is not just a crash or data leak, it can become full server compromise. In a web CMS, that matters because the application often sits close to content, admin workflows, and configuration state, so one injection flaw can turn a routine request into execution with the web process’s privileges.
With CVE-2024-56145, the dangerous part is the bridge from application-layer input handling to operating-system level execution. That makes the vulnerability especially serious when the affected deployment is reachable from the internet and used to manage high-value content, plugins, or administrative functions.
Why remote code execution is the main security concern
Remote code execution changes the impact from application abuse to host-level compromise. Once an attacker can run code through Craft CMS, they may be able to read configuration files, inspect environment variables, pivot into connected services, or modify the application itself for persistence.
The inclusion of this CVE in CISA’s Known Exploited Vulnerabilities catalogue means organisations should treat it as an exploited weakness, not a theoretical one. For authoritative version and patch details, readers should rely on the vendor advisory and the CVE Program record, together with the NIST National Vulnerability Database entry for the canonical vulnerability metadata.
How organisations assess exposure and reduce attack surface
Exposure review starts with knowing where Craft CMS is deployed, which version is running, and whether the application is internet-facing. Organisations should confirm whether any instance uses the configuration condition referenced in the definition, then compare that inventory against vendor guidance and the KEV catalogue.
If immediate patching is not yet possible, compensating controls matter. Restrict access to the admin surface, reduce reachability from untrusted networks, and review whether web-tier hardening or request filtering can narrow the paths that lead into the vulnerable code. The broader lesson aligns with the Vulnerability Management Guide: asset scope, exploitability, and KEV status should drive priority, not CVE labels alone.
Detection, response, and post-exploitation review
Detection should focus on signs that the CMS or its host was used to launch commands, drop files, create new web-accessible artefacts, or alter application configuration. Because code injection can become full execution quickly, incident review should extend beyond the initial exploit path to the rest of the server and any adjacent systems the CMS can reach.
After remediation, organisations should review logs, file integrity, and administrative activity for signs of persistence or follow-on abuse. If the CMS handled credentials, sessions, or keys on the affected host, those secrets should be considered exposed until proven otherwise and rotated accordingly.
Risk and Threat Considerations
Exploited CMS code injection creates a direct path from public input handling to server-side execution, which makes it attractive for intrusion, persistence, and follow-on access. The practical risk is broader than one vulnerable page, because a compromised content platform can become a foothold for lateral movement or data theft.
Failure mechanism: The attacker supplies crafted input that is interpreted as code or reaches a command-execution path, then uses the resulting execution to inspect the host, change files, or stage additional tooling.
Impact: A successful exploit can expose application data, configuration material, credentials, and connected services, and may leave the server altered even after the original vulnerability is patched.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Code injection is prevented by validating and constraining untrusted input before processing. |
| SI-2 — Flaw Remediation | An exploited CVE requires timely remediation and verification across affected systems. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploitation review depends on log analysis to find execution, persistence, and abnormal admin activity. | |
| Recommendation — Validate all CMS inputs before they reach interpreters or command paths. Patch the vulnerable Craft CMS instances and confirm remediation across the fleet. Review logs for command execution, file changes, and suspicious administrative actions. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Injection flaws are addressed through secure design and defense-in-depth in application architecture. |
| V16 — Security Logging and Error Handling | Detection and investigation depend on security logging that preserves exploit traces and abnormal events. | |
| Recommendation — Design the application to keep untrusted input out of executable paths. Log security-relevant events needed to investigate injection attempts and post-compromise activity. | ||