CVE-2024-4990

What it actually does

Yii2 Components allow behaviors to be attached by assigning properties named in the form `as <behavior-name>`. In vulnerable versions, when the assigned value is not already a `yii\base\Behavior` instance, Yii calls `Yii::createObject($value)` without first confirming that the requested class/configuration is actually a valid Behavior. If attacker-controlled input can reach this property assignment path, the attacker can cause arbitrary PHP classes available to the application autoloader to be instantiated, pass constructor arguments, and trigger setter methods. The practical impact depends on the installed classes and application code, but can include remote code execution through gadget classes, file access or modification, SSRF, credential exposure, application state manipulation, or denial of service.

Why it matters to the business

Applications built on affected Yii2 versions may be exposed to full application compromise if they accept user-controlled configuration, model attributes, JSON/form fields, or API input that can be mapped into Component properties. Although this issue is not currently listed in CISA KEV and is not flagged as ransomware-used, its high CVSS score and very high EPSS probability indicate elevated exploitation risk, especially because it has been public for a long time. A successful compromise could lead to service disruption, theft of sensitive application data, unauthorized transactions, deployment of web shells or malware, and loss of trust in affected customer-facing services.

How an attack unfolds

An attacker first identifies a Yii2 application path where user input is used to configure or populate a Yii Component or object that supports magic property assignment. The attacker supplies a property name beginning with `as ` so Yii treats it as a behavior attachment. Instead of supplying a legitimate Behavior object or safe behavior configuration, the attacker supplies a class name or Yii object configuration for another class available in the application. The vulnerable code passes that value to `Yii::createObject()`, causing the class to be instantiated with attacker-influenced constructor parameters and setter values. The attacker then chains the side effects of the selected class or dependency gadget: for example, executing commands, making network requests, writing files, reading local resources, or forcing application errors. If exploitation succeeds, the attacker may establish persistence through a web shell, harvest configuration secrets, pivot to databases or internal services, and clean up obvious request traces.

How to fix it

Upgrade Yii2 to a vendor-patched release that validates behavior configuration before object creation; where possible, use the latest supported Yii2 2.x release and verify the installed `yiisoft/yii2` version in `composer.lock`. If an exact fixed version is required for change control, confirm it against the official Yii security advisory for CVE-2024-4990 and the package repository before deployment. As defense in depth, do not pass raw user input into Component configuration or mass assignment paths that can set arbitrary property names; block or reject externally supplied keys beginning with `as `; allowlist behavior classes; require attached behaviors to be subclasses of `yii\base\Behavior`; disable production debug output; and restrict dangerous PHP/runtime capabilities where feasible. Add WAF or request validation rules for suspicious `as <name>` property keys only as a temporary mitigation, not as a replacement for patching.

How to confirm the fix worked

Confirm the installed Yii2 package version using `composer show yiisoft/yii2` and by reviewing `composer.lock` in deployed artifacts. Verify that all build images, containers, and runtime hosts use the patched package and that no vendored or copied Yii2 framework code remains at an older version. Review application code for calls that assign untrusted arrays or request bodies into Yii Components, including dynamic `setAttributes`, configuration builders, dependency-injection configuration, and custom object factories. Add a safe regression test that attempts to attach a non-Behavior class through an `as <name>` property and confirms the operation is rejected before object instantiation. In staging, send benign requests containing keys such as `as test` to endpoints suspected of accepting dynamic input and confirm that they are rejected cleanly without Yii stack traces, class loading attempts, or object-construction errors.

Typical attack path

1. Fingerprint the target as a Yii2 application or identify endpoints that accept dynamic configuration, model attributes, JSON bodies, or form data.
2. Find an input path where attacker-controlled keys and values are assigned to a Yii Component via magic property setting.
3. Submit a property key using the `as <name>` behavior syntax.
4. Provide a malicious class name or Yii object configuration instead of a legitimate `yii\base\Behavior` implementation.
5. Trigger `Yii::createObject()` to instantiate attacker-selected classes with controlled constructor arguments or setter values.
6. Use available application/vendor classes as gadgets to execute commands, access files, perform SSRF, alter application state, or cause denial of service.
7. If code execution or file write is achieved, deploy persistence, steal secrets, and pivot to connected services.

How to detect it

Look for both attempted behavior injection and post-exploitation activity. Useful log sources include HTTP access logs, WAF/proxy logs with request bodies if available, Yii application logs, PHP error logs, PHP-FPM logs, web server error logs, EDR process telemetry, file integrity monitoring, and outbound network logs. Search for request parameters or JSON keys that begin with `as ` or encoded equivalents, especially when paired with PHP class-like values, Yii object configuration arrays, `class` fields, `__class` fields, namespace separators, or unexpected constructor-like parameters. In application logs, investigate Yii exceptions or stack traces involving `yii\base\Component::__set()`, `Yii::createObject()`, `yii\di\Container::build()`, invalid configuration errors, or failed class resolution shortly after suspicious requests. For possible successful exploitation, review whether PHP, PHP-FPM, Apache, or Nginx worker processes spawned shells or utilities such as `sh`, `bash`, `curl`, `wget`, `nc`, `python`, `perl`, or `php`; inspect recent file writes in web-accessible directories; and check for unusual outbound connections from web servers. Because no single universal IOC exists for this framework flaw, correlate suspicious `as <name>` input with application errors, new files, child processes, credential access, and anomalous egress.

• as
• as%20
• as+
• "as
• 'as
• __class
• "class"
• 'class'
• yii\base\Component::__set
• Yii::createObject
• yii\BaseYii::createObject
• yii\di\Container::build
• yii\base\InvalidConfigException
• Class not found
• Setting unknown property
• php-fpm spawned /bin/sh
• php-fpm spawned /bin/bash
• apache2 spawned /bin/sh
• nginx spawned /bin/sh
• /bin/sh -c
• /bin/bash -c
• wget http
• curl http

What your security team should do

• Prioritize inventory and patching of all Yii2 applications because the EPSS score is high and the issue has been public for an extended period.
• Search source repositories and deployed artifacts for `yiisoft/yii2` versions below the vendor-fixed release and for custom framework copies.
• Review controllers, API handlers, model population logic, and configuration loaders for user-controlled keys that can reach Yii Component property assignment.
• Deploy temporary request filtering for externally supplied parameter names beginning with `as `, including URL-encoded variants, while patching is underway.
• Enable focused monitoring of Yii application logs, PHP-FPM logs, web access logs, and WAF events for behavior-injection attempts and class-instantiation errors.
• Investigate any evidence of PHP worker processes spawning shells, download tools, or unexpected network clients, as this may indicate successful gadget-based exploitation.
• If exploitation is suspected, rotate application secrets, database credentials, API tokens, and session-signing keys after containment and rebuild from known-good artifacts.