CVE-2025-32432: Unauthenticated Remote Code Execution in Craft CMS

Through a detailed analysis of this workflow, our fellows identified that the method AssetsController::actionGenerateTransform is invoked whenever a POST request is sent to the exposed endpoint. This function retrieves the handle parameter directly from the request body and forwards it downstream for further processing in the next stage.

In the next step, the ImageTransforms::normalizeTransform() method is called. This method takes the user-supplied handle parameter and converts it into an ImageTransform object. Since the object is created directly from untrusted input, this represents a critical point of risk in the execution flow.

During this process, all key–value pairs from the user-controlled $transform array (originating from handle parameter) are merged into a configuration array. The normalizeTransform method then passes this array to Craft::createObject(), which is responsible for instantiating a new ImageTransform object.

The vulnerability stems from the way Craft::createObject() (wrapping Yii’s Yii::createObject()) processes configuration arrays. Because this mechanism uses the DI container to instantiate and configure objects directly from the unvalidated array, attackers may gain control over the object construction process.

When a malicious payload is passed in, the object’s constructor (inherited from the Model class) invokes the App::configure() method.

This method iterates over each property in the attacker-controlled array and assigns them to the new object.

When App::configure() assigns properties from the attacker-controlled configuration array, most keys are mapped directly onto the object. However, if a key begins with the prefix as, the assignment is routed through Component::__set, Yii’s magic setter. This method interprets as <name> as an instruction to attach a behavior (mixin) to the object.

One such malicious payload can be crafted to exploit how Component::__set processes properties prefixed with as, such as as exploit:

From our analysis, the implementation of Component::__set includes a safeguard: when a behavior is attached through such a property, the framework verifies that the class specified in the configuration array is a valid subclass of yii\base\Behavior. This check is intended to prevent arbitrary classes from being attached directly to components.

However, this safeguard is not as effective as it seems. The weakness comes from how Yii::createObject handles configuration arrays.

When instantiating an object, Yii::createObject gives priority to the special __class parameter. If this key is present, its value is used as the target class for instantiation, and the standard class key in the configuration array is ignored.

The attacker can craft a payload for the as exploit behavior that includes two keys:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - A legitimate class that extends yii\base\Behavior. This value exists solely to satisfy the is_subclass_of check in Component::__set, allowing execution to continue without raising an error.
2. '__class' => '\yii\rbac\PhpManager' - The attacker’s actual target. This is the “gadget” class they want to instantiate.

When the code is executed, Component::__set passes the security check because it only inspects the class key. However, when the framework later calls Yii::createObject to attach the behavior, it gives precedence to __class, resulting in the instantiation of the attacker-chosen \yii\rbac\PhpManager object instead.

The use of \yii\rbac\PhpManager is intentional. Simply creating an object is not enough for exploitation; achieving RCE requires a gadget class with side effects that can be weaponized. PhpManager is a common target in POI (PHP Object Injection) attacks because of its initialization flow. Upon instantiation, its init() method calls load(), which then invokes loadFromFile($this->itemFile). With control over $this->itemFile, an attacker can force the application to load a malicious file, transforming object creation into code execution.

The danger lies in the loadFromFile method. In PHP, a require executes the target file as code, so if an attacker controls the file path, they can trigger arbitrary code execution.

To place malicious code on the server, the attacker exploits PHP session files. By injecting PHP into a request parameter, Craft CMS saves the payload into a session file during the redirect process. Later, when PhpManager loads this file, the attacker’s code could be executed.

The complete attack chain works in three stages. First, the attacker plants malicious PHP by sending a crafted URL, which Craft CMS saves into a session file. Next, they exploit the __class bypass in the image transform endpoint to load the PhpManager gadget and point it toward the poisoned session file. Finally, when PhpManager loads the file, the attacker’s payload executes, granting RCE and full control of the server—often through a webshell or reverse shell.