Craft CMS RCE: The Art of Unauthenticated Object Injection

Craft CMS is the darling of the agency world. It’s slick, it’s flexible, and it’s built on top of the Yii2 framework. For the uninitiated, Yii2 is a powerful beast that relies heavily on "magic"—specifically, a dependency injection container that can instantiate classes and configure their properties on the fly using arrays. It’s a developer’s dream: define a class, throw an array of settings at it, and the framework handles the rest.

But here’s the thing about magic: if you let the wrong person wave the wand, things explode. In September 2023, researchers discovered that Craft CMS was a little too generous with who held the wand. Specifically, the ConditionsController allowed unauthenticated users to pass arbitrary configuration arrays directly into this object creation engine.

This isn't your standard buffer overflow or a forgotten SQL injection. This is Object Injection via Configuration. It’s the architectural equivalent of letting a stranger walk into a car factory, hand the foreman a blueprint for a tank, and having the factory build it without asking questions. The result? A CVSS 10.0 vulnerability that allows anyone on the internet to execute code on your server as www-data.

The vulnerability lives in craft\controllers\ConditionsController.php. This controller is designed to handle dynamic conditions for content filtering. To do this, it needs to accept configuration data from the user to know what conditions to apply. So far, so standard.

The fatal mistake was in the beforeAction method. In Yii2, beforeAction runs before the main controller action. Craft CMS developers decided to process the request parameters here. They took the raw POST data, specifically a parameter named config, decoded it from JSON, and then—here is the kicker—passed it straight into the object creation service.

Because Yii2’s BaseObject allows for "Mass Assignment" (setting properties based on array keys), an attacker can control every public property of the class they ask to create. Even worse, Yii2 supports "behaviors" (keys starting with as ) and "events" (keys starting with on ). This means an attacker isn't just setting simple strings or integers; they can attach entire behavior classes or define event handlers that execute arbitrary PHP code.

Let's look at the crime scene. In the vulnerable versions (<= 4.4.14), the code looked something like this:

// Vulnerable code in ConditionsController
public function beforeAction($action)
{
    // ... various checks ...
    
    // 1. Take user input blindly
    $config = $this->request->getBodyParam('config');
    
    // 2. If it looks like JSON, decode it
    if (is_string($config) && Json::isJson($config)) {
        $config = Json::decode($config);
    }
 
    // 3. Create the object using the user's config
    $condition = Craft::createObject($config);
    
    // ...
}

See the problem? There is zero validation on $config. If I send {"class": "\Evil\Class", "property": "bad_value"}, the application happily creates \Evil\Class.

The fix in version 4.4.15 was a multi-step remediation. First, they ensured the configuration is "cleansed" of dangerous keys like on (events) and as (behaviors). Second, they strictly typed the input. Third, and perhaps most importantly, they enforced authentication checks before this logic runs.

// Patched code
public function beforeAction($action)
{
    // Enforce permissions first!
    $this->requireCpRequest();
    
    // Sanitize the config
    $config = Craft::$app->getRequest()->getBodyParam('config');
    // ... decoding logic ...
    
    // Cleanse dangerous keys
    $config = Component::cleanseConfig($config);
    
    return parent::beforeAction($action);
}

So we can create objects. Great. But how do we get a shell? We need a "gadget"—a class already present in the codebase that does something dangerous. Since Craft CMS includes Guzzle (a popular HTTP client), we have a perfect candidate: \GuzzleHttp\Psr7\FnStream.

This class is a wrapper for PHP streams. It has a magic method, __destruct(), which is called when the object is destroyed (garbage collected) at the end of the script execution. The __destruct method in FnStream checks if a custom close function (_fn_close) is defined and, if so, executes it.

Here is the attack chain:

1. Instantiate: Tell the controller to create a \GuzzleHttp\Psr7\FnStream object.
2. Configure: Set the private property _fn_close to a string representing a PHP function, like phpinfo or system.
3. Wait: The request finishes. PHP cleans up memory. The FnStream object is destroyed.
4. Boom: __destruct() fires, calls call_user_func($this->_fn_close), and our code runs.

The payload looks remarkably simple for such a devastating exploit. A standard Nuclei template or Python script sends a POST request to index.php with:

{
  "action": "conditions/render",
  "config": {
    "class": "\\GuzzleHttp\\Psr7\\FnStream",
    "__construct()": [{"close": null}],
    "_fn_close": "phpinfo"
  }
}

If you see the PHP configuration page in the response, you own the server.

This is a full unauthenticated RCE. The attacker runs as the web server user (usually www-data). From here, the possibilities are endless and terrifying.

First, they can read your .env file, stealing your database credentials, AWS keys, and the CRAFT_SECURITY_KEY. With the database credentials, they can dump your entire user table, including hashed passwords. With the security key, they can forge session cookies or encrypt malicious payloads to be executed elsewhere.

Second, they can modify the CMS itself. They could inject a persistent backdoor into index.php that survives updates, or install a web shell deep in the vendor directory where you're unlikely to look. Ransomware gangs love these vulnerabilities because they are easy to automate. One script can scan thousands of servers, drop a cryptominer or encrypt the filesystem, and move on.

If you are running Craft CMS 4.0.x through 4.4.14, you are vulnerable. Stop reading and update to 4.4.15 or higher immediately. The patch introduces strict validation on the config parameter, stripping out the magic keys that allowed the exploit to work.

After patching, you aren't done. You must assume you were compromised if your server was exposed to the internet.

1. Rotate Keys: Change your CRAFT_SECURITY_KEY and any API keys stored in your .env file.
2. Check Logs: Look for POST requests to index.php containing action=conditions/render or suspicious JSON payloads involving FnStream or Imagick.
3. Verify Integrity: If possible, nuke the vendor folder and reinstall dependencies (composer install) to ensure no backdoors were planted in library files.