Craft CMS: The Art of Array Injection (CVE-2025-32432)

In the world of web application security, the most dangerous assumptions are often the simplest ones. In Craft CMS, the assumption was that a request parameter named handle would always be a string—a filename, a slug, a simple identifier. But this is PHP, a language that happily treats everything as a suggestion rather than a rule.

CVE-2025-32432 is what happens when you trust user input to define the structure of your objects. It lives in the actionGenerateTransform method of the AssetsController. This endpoint is designed to generate image thumbnails on the fly. It's publicly accessible because, logically, you want your website visitors to see images without logging in.

However, this endpoint takes the handle parameter and passes it straight into the deep magic of the Yii2 framework (on which Craft is built). If an attacker decides that handle isn't a string like "thumbnail", but rather a complex associative array, the application doesn't complain. It attempts to parse it. This is where the door to the kingdom is left unlocked.

To understand this exploit, you have to understand the specific flavor of "magic" used by Yii2. The framework has a concept called Behaviors. Think of them as dynamic mixins—ways to attach methods and properties to a class at runtime.

When Craft CMS processes the handle, it eventually calls App::configure($object, $properties). This function iterates through the input array. If it sees a key that starts with as , it treats it as a request to attach a Behavior. For example, "as behaviorName": { ... }.

> [!NOTE] > This is a classic "Object Injection via Configuration" pattern. The application blindly trusts the configuration array provided by the user.

The vulnerability is a logic flaw in how Yii2 validates these behaviors. It checks if the configuration array contains a class key that implements the Behavior interface. That sounds safe, right?

Wrong.

The framework's object factory (Yii::createObject) has a quirk: if you provide both a class key AND a __class key, it uses class for validation checks but uses __class for the actual object instantiation. This allows an attacker to pass the validation check with a harmless class, while simultaneously instantiating a malicious gadget class using __class.

So how do we turn "I can create an object" into "I own your server"? We need a Gadget Chain. The researchers (and the attackers known as "Mimo") found two distinct paths.

Path A: The One-Shot (PHP Info) This method uses the GuzzleHttp\Psr7\FnStream class. This class has a destructor (__destruct) that calls a function defined in the _fn_close property.

By injecting an array defining a behavior with __class set to FnStream and _fn_close set to phpinfo, the attacker triggers the function the moment the request ends and the object is destroyed.

Path B: The Heavy Hitter (Full RCE) This is where it gets cynical. To execute arbitrary commands, attackers use a two-step process involving Local File Inclusion (LFI).

1. Seeding: The attacker hits a URL like /admin/dashboard?x=<?php system($_GET['cmd']); ?>. Craft CMS forces a login redirect but logs the "return URL" (containing the PHP payload) into a session file on the disk (e.g., /var/lib/php/sessions/sess_...).
2. Triggering: The attacker sends the exploit payload to generate-transform. They instantiate yii\rbac\PhpManager. This class has an init() method (called automatically) that includes a file specified by the itemFile property. The attacker sets itemFile to the path of the dirty session file.

Boom. The session file is included, the PHP code inside it executes, and the server runs the command.

The fix for this critical vulnerability is embarrassingly simple. It highlights just how fragile loose typing can be.

The patch (Commit e1c85441fa47eeb7c688c2053f25419bc0547b47) simply enforces that the input is actually a string before letting it anywhere near the image transformation logic.

// src/controllers/AssetsController.php
 
public function actionGenerateTransform(): Response
{
    $assetId = $this->request->getRequiredBodyParam('assetId');
    $handle = $this->request->getRequiredBodyParam('handle');
 
    // THE FIX: explicitly check the type
    if (!is_string($handle)) {
        throw new BadRequestHttpException('Invalid transform handle.');
    }
 
    // ... existing logic ...
    $transform = ImageTransforms::normalizeTransform($handle);
}

Before this if statement existed, $handle could be anything. After this patch, the exploit chain is dead on arrival because the array injection is rejected immediately. It is a stark reminder: Always validate your input types, not just their existence.

This isn't just a theoretical bug. It is being actively exploited by groups like "Mimo" to deploy malware and ransomware. Because the endpoint is unauthenticated, every single exposed Craft CMS install within the affected version range is vulnerable.

The attacker doesn't need to guess passwords or brute force login forms. They just need to send one POST request. The EPSS score is in the 99th percentile for a reason. If you run Craft CMS 3, 4, or 5 and haven't updated since April 2025, assume you are compromised.

Furthermore, this was an "incomplete fix" scenario (fixing CVE-2023-41892). This means threat actors were already looking at this code, knew it was fragile, and likely found this bypass long before the defenders did.