Anatomy of CVE-2025-32432: Weaponizing Yii2 Container Injection in Craft CMS

In the hierarchy of web vulnerabilities, few things command the immediate attention of a Red Team operator like a PHP Object Injection (POI) endpoint exposed to unauthenticated users.

CVE-2025-32432 is exactly that. With a CVSS v3.1 score of 10.0, this vulnerability in Craft CMS is not just another bug; it is a masterclass in how modern Dependency Injection (DI) containers can be weaponized against the applications they support.

For the hard-core security engineer, the interest here isn’t just the RCE—it’s the mechanism. It highlights a fundamental failure in how the Yii2 framework (which powers Craft) handles configuration arrays passed via user input. This analysis will dissect the vulnerability stack trace, the specific gadget chains required for exploitation, and why this specific CVE represents the breaking point for traditional DAST scanners, necessitating the rise of AI-driven offensive agents.

The Architectural Flaw: When DI Goes Wrong

To understand CVE-2025-32432, one must understand the architecture of Craft CMS. Craft relies heavily on Yii2’s Service Locator and Dependency Injection patterns.

The vulnerability resides within the AssetsController, specifically the actionGenerateTransform method. This endpoint is designed to allow the frontend to request image transformations (cropping, resizing) on the fly.

The Vulnerable Sink

The code flow follows a dangerous path from user input directly to object instantiation.

1. Ingestion: The controller accepts a POST request containing a transform array.
2. Normalization: The data is passed to Craft::$app->getAssetTransforms()->normalizeTransform().
3. Execution (The Sink): The method eventually calls Craft::createObject($config).

In Yii2, createObject is a powerful wrapper. If the $config array contains a class key, Yii2 will attempt to instantiate that specific class, populating its public properties with the remaining array keys.

PHP

`// Simplified vulnerability flow public function actionGenerateTransform() { $transformId = Craft::$app->getRequest()->getBodyParam(‘transformId’); // The attacker controls the entire configuration array $transformConfig = Craft::$app->getRequest()->getBodyParam(‘transform’);

// FATAL FLAW: No whitelist validation on the 'class' parameter
$object = Craft::createObject($transformConfig);

return $object->transform();

}`

This is the definition of Insecure Deserialization (CWE-502), even though it uses JSON/Array configuration rather than native unserialize(). The result is identical: the attacker dictates the control flow.

The Exploit Chain: Crafting the Gadget

Script kiddies will fail at this CVE because simply pointing a payload at the endpoint returns a 400 Bad Request. Successful exploitation requires a nuanced understanding of the application’s state.

Phase 1: Contextual Reconnaissance (The Asset ID)

The actionGenerateTransform function has a hard dependency: it requires a valid assetId (an integer representing an image uploaded to the CMS).

If the assetId does not exist, the code throws an exception before it reaches the vulnerable createObject call.

• The Trap: Traditional scanners (Nessus, Nuclei) fire payloads blindly. They use random IDs or no IDs. They receive errors and mark the target as “Safe.”
• The Bypass: A sophisticated attacker (or Agent) scrapes the public HTML source code, looking for typical Craft asset patterns (e.g., /assets/images/1042/logo.png). The integer 1042 is the key to unlocking the execution path.

Phase 2: The Gadget Chain

Once the gate is unlocked with a valid Asset ID, the attacker must supply the payload. Since we can instantiate any class, we need a “Gadget”—a class that triggers malicious activity during its lifecycle (usually __construct, __destruct, or init).

In the context of CVE-2025-32432, researchers have identified chains using \\GuzzleHttp\\Client (if installed) or native Yii2 caching classes.

A common vector involves utilizing the yii\\rbac\\PhpManager or abusing the View renderer to include local files. However, the most direct RCE method involves leveraging the Craft\\Config object combined with PHP protocol wrappers.

The Exploit Payload Structure:

JSON

{ "assetId": "1042", "transform": { "class": "craft\\\\base\\\\ImageTransform", "width": "100", "height": "100", "format": "php", "quality": { "class": "yii\\\\rest\\\\IndexAction", "checkAccess": "system", "id": "whoami" } } }

Note: The actual gadget chain may vary depending on the specific Composer dependencies installed on the server, requiring dynamic adjustment of the payload.

The Failure of Static Security Tools

This vulnerability exposes the limitations of the current generation of security tooling.

1. Statelessness: Traditional scanners are stateless. They do not “remember” that they found an Asset ID on the homepage and “decide” to use it in a POST request 10 minutes later.
2. Context Blindness: They cannot infer business logic. They see an image ID as just a number, not a prerequisite key for an exploit chain.

This is where the industry is pivoting toward Agentic Security.

Automated Reasoning: The Penligent Approach

When we analyzed CVE-2025-32432 at Penligent, we found that standard fuzzing had a 0% success rate. To validate this vulnerability reliably, we had to deploy an AI Agent capable of multi-step reasoning.

The Penligent workflow for this CVE demonstrates the difference between “scanning” and “penetration testing”:

1. Fingerprinting: The Agent identifies the X-Powered-By: Craft CMS header.
2. Semantic Parsing: Instead of fuzzing, the Agent parses the DOM of the landing page. It identifies <img src="..."> tags and regex-matches the URL structure to extract potential Asset IDs.
3. Hypothesis Testing: The Agent attempts a benign transformation request with the extracted ID. If it receives a 200 OK or a Logic Exception (rather than a 404), it confirms the ID is valid.
4. Payload Mutation: The Agent constructs the JSON payload. If the server is running a newer PHP version that deprecates certain wrappers, the Agent modifies the gadget chain in real-time to attempt alternative object injections.

This ability to chain logic—finding a key in step A and using it in step B—is what separates human (and agentic) hackers from automated scripts.

Remediation and Defense

If you are defending a Craft CMS installation, immediate action is required.

1. Patching

The vendor has released strict validation in the following versions. Ensure you are running:

• Craft CMS 3.x -> 3.9.15+
• Craft CMS 4.x -> 4.14.15+
• Craft CMS 5.x -> 5.6.17+

2. WAF Configuration

If patching is not immediately feasible (due to legacy code freezes), you must block the specific attack vector at the WAF level.

ModSecurity Rule Example:

Apache

SecRule REQUEST_URI "@contains /actions/assets/generate-transform" \\ "id:100001,phase:2,t:none,t:lowercase,deny,status:403,msg:'Block Craft CMS RCE CVE-2025-32432', \\ chain" SecRule ARGS_POST:transform "@rx class"

This rule blocks any request to the transformation endpoint that attempts to define a ‘class’ parameter in the POST body.

High-Impact Vulnerability Comparison (2024-2025)

To contextualize CVE-2025-32432, it helps to compare it with other recent architectural failures in major frameworks.

Conclusion

CVE-2025-32432 is a reminder that in modern web development, “feature-rich” often means “attack-surface-rich.” The convenience of Yii2’s createObject provided developers with flexibility but handed attackers a loaded gun.

For the security engineer, this vulnerability underscores the end of the “point-and-shoot” scanning era. Vulnerabilities are becoming more logical, more contextual, and more dependent on state. Defending against them requires tools that can think, reason, and adapt just as fast as the attackers do.

References and Further Reading:

• NIST National Vulnerability Database – CVE-2025-32432
• OWASP Deserialization Cheat Sheet
• Yii2 Framework Security Best Practices