Behaving Badly: Unsafe Reflection & RCE in Yii2 Framework

In the world of PHP frameworks, "Magic Methods" are the double-edged sword that developers love and security researchers drool over. Yii2, one of the heavyweights of the PHP ecosystem, relies extensively on __get, __set, and __call to implement its component-based architecture. This allows for mixins, dynamic properties, and event handling that feels almost like wizardry.

At the heart of this system is yii\base\Component. This class is the great-grandfather of nearly everything in a Yii2 application—Models, Controllers, Views, you name it. If you find a bug here, you aren't just breaking a feature; you are breaking the foundation.

CVE-2024-4990 allows us to abuse a specific feature of this component system: Behaviors. Behaviors are Yii2's way of injecting functionality into a class at runtime. The framework allows you to attach a behavior simply by setting a property that starts with as . For example, $model->{'as timestamp'} = TimestampBehavior::class;. It's a convenient piece of syntactic sugar, but as we're about to see, it's also a convenient entry point for Remote Code Execution.

The vulnerability lies in how yii\base\Component::__set() handles these dynamic behavior assignments. The logic is simple: check if the property name starts with as , trim the prefix to get the behavior name, and then instantiate the value provided.

Here is the logic in pseudocode terms: "If the user sends me a property named as evil, take the value they sent, create an object out of it, and attach it to the component." The critical failure here is the order of operations. The code calls Yii::createObject($value)—a powerful factory method that wraps a Dependency Injection (DI) container—before checking if the resulting object is actually a valid Behavior.

Yii::createObject is incredibly flexible. If you pass it an array with a class key, it will instantiate that class. If you pass it arguments, it will feed them to the constructor. Because __set is reachable via user input (e.g., during mass assignment of POST data to a Model), an attacker can trick the application into instantiating any class available in the autoloader, not just the intended Behaviors. It's like a nightclub bouncer who lets people in before checking their ID.

Let's look at the vulnerable code in yii\base\Component.php prior to version 2.0.48. This snippet shows the __set implementation:

public function __set($name, $value)
{
    // ... standard setter logic ...
 
    // The Vulnerable Logic
    } elseif (strncmp($name, 'as ', 3) === 0) {
        // as behavior: attach behavior
        $name = trim(substr($name, 3));
        // DANGER: Yii::createObject is called on user-controlled $value
        $this->attachBehavior($name, $value instanceof Behavior ? $value : Yii::createObject($value));
        return;
    }
    // ...
}

The line $value instanceof Behavior ? $value : Yii::createObject($value) is the killer. If $value is an array (which it will be coming from a JSON payload), instanceof fails, so it proceeds to Yii::createObject($value). By the time the code realizes the object isn't a Behavior (inside attachBehavior), the object has already been created, and its constructor has already run.

Now, look at the initial patch (which was later bypassed, but we'll get to that):

// The "Fix"
if ($value instanceof Behavior) {
    $this->attachBehavior($name, $value);
} elseif (isset($value['class']) && is_subclass_of($value['class'], Behavior::class, true)) {
    // Checking class name before instantiation
    $this->attachBehavior($name, Yii::createObject($value));
} ...

The developers attempted to validate the class key before instantiation. However, they missed a crucial detail about their own DI container: Yii2 supports __class as an alias for class. This oversight led to CVE-2024-58136, a regression that kept the door wide open.

To exploit this, we need a "Gadget Chain". Since we can instantiate any class, we need a class that does something dangerous in its __construct or __destruct methods. A classic favorite in the PHP ecosystem is GuzzleHttp\Psr7\FnStream.

When FnStream is destroyed (which happens when the script ends or the object is discarded), it executes a user-defined callback. This gives us instant RCE.

The Attack Flow:

1. Identify a Target: Find an endpoint that populates a Yii2 Model using $model->load($_POST) or parses JSON into a component configuration.
2. Craft the Payload: We send a property key as exploit to trigger the __set logic.
3. Define the Object: We specify the malicious class and its arguments.

Proof of Concept (RCE via Guzzle):

{
  "User": {
    "username": "admin",
    "as exploit": {
      "class": "GuzzleHttp\\Psr7\\FnStream",
      "methods": {
        "close": "passthru",
        "args": ["id; ls -la"]
      }
    }
  }
}

When Yii2 processes this, it instantiates FnStream. The framework realizes FnStream isn't a Behavior and throws an exception or discards it. However, the object was created. When PHP creates the exception or finishes the request, the FnStream object is garbage collected. Its __destruct method fires, calling close(), which runs passthru('id; ls -la').

This is a Critical severity vulnerability because it requires zero authentication (if the vulnerable endpoint is public, like a registration or login page) and results in full Remote Code Execution.

Yii2 is used by massive enterprise applications, CRMs, and e-commerce platforms. An attacker exploiting this can:

• Gain Shell Access: Execute system commands to take over the server.
• Database Exfiltration: Instantiate a PDO object to connect to an external malicious MySQL server (SSRF) or simply use the shell access to dump the local database.
• Lateral Movement: Use the compromised server as a pivot point into the internal network.

Because the vulnerability exists in the base Component class, the attack surface is effectively "everywhere mass assignment is used in the application." It transforms a standard development convenience into a catastrophic security hole.

The remediation journey for this bug was bumpy. The initial fix in 2.0.48 was incomplete because it only validated the class array key, ignoring the __class alias supported by Yii's DI container.

Immediate Action Required:

1. Upgrade: You must upgrade to yiisoft/yii2 version 2.0.52 or later. Do not stop at 2.0.48 or 2.0.51, as they are still vulnerable to the bypass (CVE-2024-58136).
2. Code Review: Audit your code for Mass Assignment. Do not use $model->load($_POST) blindly on sensitive models without a strict scenarios() definition or explicit attribute safe-listing.

Defense in Depth: If you cannot upgrade immediately, you can implement a WAF rule to block any HTTP request body containing keys matching the regex "as\s+[a-zA-Z0-9_]+". However, WAFs are bypassable (e.g., via JSON encoding tricks), so patching the root cause is the only real solution.