CVE-2025-32432

What it actually does

This is an unauthenticated, network-reachable remote code execution flaw in Craft CMS affecting 3.0.0-RC1 through versions before 3.9.15, 4.0.0-RC1 through versions before 4.14.15, and 5.0.0-RC1 through versions before 5.6.17. The issue is a further hardening fix for the earlier Craft CMS code injection weakness and can allow a remote attacker to cause the CMS application to instantiate or process attacker-controlled input in a way that leads to arbitrary PHP code execution in the context of the web server user. Because no authentication or user interaction is required and exploitation is low complexity, a public-facing vulnerable instance can be compromised directly over HTTP/S.

Why it matters to the business

A vulnerable Craft CMS site can be fully taken over from the internet, allowing attackers to modify website content, steal application secrets, access connected data stores, install web shells, redirect visitors, and use the server as a foothold for broader intrusion. The CVSS score is critical, EPSS is extremely high, exploitation is active in the wild, and the vulnerability is listed in CISA KEV with a remediation due date of 2026-04-03, so internet-exposed systems should be treated as urgent patch-and-hunt priorities. Reported exploitation associated with the Interlock ransomware campaign increases the operational risk even though the KEV metadata does not mark the vulnerability itself as ransomware-specific.

How an attack unfolds

An attacker first scans for internet-facing Craft CMS instances and fingerprints the application by response headers, static asset paths, control panel routes, or characteristic Craft error behavior. If the detected version is in an affected range, the attacker sends a crafted unauthenticated HTTP request to a vulnerable Craft/Yii action or code path that accepts attacker-controlled parameters. The payload manipulates Craft's object/configuration handling so that attacker-supplied PHP code or a dangerous PHP/Yii class behavior is reached. Successful exploitation executes commands as the web server process, after which the attacker commonly writes a PHP web shell, drops a loader, modifies templates or plugin files, reads configuration secrets such as the Craft security key and database credentials, and pivots to the backing database or adjacent services. In observed active exploitation and campaigns such as Interlock-related activity, post-exploitation may include persistence, credential theft, payload staging from external infrastructure, and preparation for extortion or ransomware operations.

How to fix it

Upgrade Craft CMS immediately to a fixed release: 3.9.15 or later for the 3.x branch, 4.14.15 or later for the 4.x branch, or 5.6.17 or later for the 5.x branch. For source-based deployments, ensure the Craft CMS code includes the upstream fix commit 9e2781f26f5972aaba333f20b07b33514ce84c03 or a later release containing it. Because this is actively exploited, patching alone is not sufficient for exposed systems: rotate Craft security keys, database credentials, API tokens, control panel passwords, and any secrets accessible to the application if compromise is suspected. Remove untrusted plugins, verify file integrity for templates and webroot files, and redeploy from a known-good build where possible. If immediate upgrade is not possible, temporarily restrict public access to the site or vulnerable routes with a WAF, reverse proxy allowlist, VPN, or maintenance page, but treat these as short-term mitigations only.

How to confirm the fix worked

Confirm the installed Craft CMS version is 3.9.15+, 4.14.15+, or 5.6.17+ as appropriate, or verify that the deployed source includes commit 9e2781f26f5972aaba333f20b07b33514ce84c03 or later. Validate through the application control panel, Composer package metadata, lock files, container image manifests, and deployed vendor source rather than relying only on repository state. From an external perspective, confirm the site no longer exposes vulnerable behavior to unauthenticated crafted requests and that WAF or proxy controls do not merely hide an outdated backend. Review file modification times around and after the patch window, compare the deployed webroot and Craft directories to a known-good artifact, and ensure no unexpected PHP files, modified templates, or unauthorized plugins remain. After patching, run authenticated application smoke tests to confirm normal content publishing, asset transforms, plugin behavior, and control panel functions still work.

Typical attack path

1. Identify public Craft CMS sites through internet scanning, search engine dorks, asset paths, or application fingerprints.
2. Determine whether the instance appears to run an affected Craft CMS branch before 3.9.15, 4.14.15, or 5.6.17.
3. Send a crafted unauthenticated HTTP/S request to the vulnerable Craft CMS code path with malicious object/configuration parameters.
4. Trigger server-side PHP code execution under the web server account.
5. Run reconnaissance commands such as whoami, id, uname, pwd, or environment/configuration reads.
6. Write or retrieve a PHP web shell, loader, or malicious file into a writable web-accessible directory.
7. Harvest Craft configuration secrets, database credentials, session material, and application data.
8. Establish persistence, stage additional tooling, alter site content, redirect visitors, or pivot to connected infrastructure.

How to detect it

Investigate web server access logs, reverse proxy logs, WAF alerts, Craft application logs, PHP-FPM logs, EDR telemetry, shell history, file integrity monitoring, and outbound network logs. Look for unauthenticated POST requests to Craft action routes with unusual object/configuration parameters, especially requests containing PHP/Yii class names, bracketed parameter injection, serialized-looking payloads, or command-execution strings. Review access to endpoints historically associated with Craft code injection exploitation, including action-based routes such as conditions rendering. Hunt for immediate follow-on activity: requests that create or access new PHP files in writable directories, execution of system commands by the web server user, outbound curl/wget/fetch connections, archive downloads, chmod/chown activity, and discovery commands. Check for unexpected PHP files or modified templates in webroot, asset, storage, plugin, template, and control panel resource directories. For Interlock-related concerns, also look for suspicious staging infrastructure, fake update or loader delivery, credential dumping, lateral movement attempts, and unusual archive or encryption tooling launched from the web server process. Absence of a single IOC does not rule out exploitation because payloads are easily changed; prioritize behavioral evidence and file integrity comparison against a clean deployment.

• action=conditions/render
• /index.php?action=conditions/render
• POST /index.php?action=conditions/render
• configObject[class]
• config[class]
• craft\\elements\\conditions\\ElementCondition
• craft\elements\conditions\ElementCondition
• yii\\rbac\\PhpManager
• yii\rbac\PhpManager
• GuzzleHttp\\Psr7\\FnStream
• GuzzleHttp\Psr7\FnStream
• system(
• shell_exec(
• passthru(
• proc_open(
• popen(
• base64_decode(
• phpinfo(
• /cpresources/
• /assets/
• /storage/runtime/
• /vendor/
• /templates/
• /webshell.php
• /shell.php
• /cmd.php
• /up.php
• /autoload.php
• curl http
• wget http
• whoami
• uname -a
• /bin/sh -c
• /bin/bash -c

What your security team should do

• Prioritize all internet-facing Craft CMS instances for emergency upgrade to 3.9.15, 4.14.15, 5.6.17, or later.
• Because exploitation is active and EPSS is extremely high, perform compromise assessment on exposed systems before closing the remediation ticket.
• Check CISA KEV tracking and ensure remediation is completed before the 2026-04-03 due date for regulated programs that follow KEV timelines.
• Search web, WAF, EDR, file integrity, and application logs for exploitation patterns, suspicious PHP file creation, outbound staging traffic, and post-exploitation commands.
• If suspicious activity is found, isolate the host or container, preserve forensic evidence, rotate application and database secrets, and redeploy from a known-good image or artifact.
• Harden Craft CMS deployments by disabling unnecessary plugins, limiting write permissions in web-accessible paths, enforcing least-privilege database accounts, and placing administrative routes behind additional access controls.
• Add monitoring for unexpected changes under Craft webroot, templates, plugins, storage, vendor, and asset directories.
• Review historical exposure going back at least to the public disclosure date and the earliest available logs, since the vulnerability has been public for 472 days and is actively exploited.