CVE-2024-58136

What it actually does

Yii 2 versions before 2.0.52 can incorrectly process behavior configuration that uses the special __class array key. In vulnerable code paths, attacker-controlled structured input may be interpreted as a Yii object or behavior configuration through an alternate instantiation path, allowing unintended class construction and behavior attachment. Depending on the exposed application functionality, installed classes, and reachable gadgets, this can lead to remote code execution or other high-impact server-side actions in the context of the PHP web application process. This issue is a regression related to the earlier CVE-2024-4990 fix and has been reported as exploited in the wild.

Why it matters to the business

Successful exploitation can allow an attacker to take control of a Yii-based web application, access application data, modify content, steal secrets, deploy web shells, or pivot to connected systems such as databases and internal services. The risk is urgent because the vulnerability is in the CISA Known Exploited Vulnerabilities catalog, has active in-the-wild exploitation, has a high EPSS probability, and was subject to a CISA remediation deadline of 2025-05-23.

How an attack unfolds

An attacker first identifies an internet-facing application built with a vulnerable Yii 2 release. They then send crafted HTTP requests to functionality that accepts nested arrays, JSON, form parameters, or other user-controllable configuration-like input that is later passed into Yii behavior or object creation logic. The malicious input includes a __class key designed to trigger Yii’s behavior attachment and object instantiation path incorrectly. If the application exposes a suitable reachable code path and class chain, Yii may instantiate or configure unintended classes, allowing attacker-controlled execution flow. After code execution, the attacker typically runs commands as the web server user, writes a web shell or other persistence mechanism, collects configuration files and credentials, accesses databases, and may use the compromised application as a foothold for lateral movement. Exploitation was observed in the wild between February and April 2025; organizations should assume public exploit knowledge exists even if no specific named threat actor is confirmed beyond the KEV-tracked exploitation activity.

How to fix it

Upgrade Yii 2 to version 2.0.52 or later. For Git-based deployments of yiisoft/yii2, ensure the code includes fixed commit 40fe496eda529fd1d933b56a1022ec32d3cd0b12 or a later trusted upstream commit. Rebuild and redeploy applications after updating dependencies, and verify composer.lock or equivalent build artifacts no longer reference a vulnerable Yii 2 version. If immediate upgrade is not possible, reduce exposure by disabling or restricting affected endpoints, rejecting request payloads that contain unexpected __class keys, applying WAF rules for suspicious nested object-configuration payloads, and limiting public access to administrative or complex form/API functionality. Mitigations should be treated as temporary because this issue is actively exploited and listed in the CISA KEV catalog.

How to confirm the fix worked

Confirm the running application uses Yii 2.0.52 or later, or that the installed yiisoft/yii2 source includes commit 40fe496eda529fd1d933b56a1022ec32d3cd0b12 or later. Check composer.lock, vendor/yiisoft/yii2 files, container images, deployment artifacts, and production runtime images rather than only source repositories. Run dependency scanning or software composition analysis against all PHP applications and container images. After deployment, restart PHP-FPM, Apache, Nginx, workers, and application containers so the patched library is actually loaded. Validate externally that public endpoints no longer accept or process unexpected nested __class parameters, and review application logs for absence of Yii object creation or behavior attachment errors related to attacker-supplied input.

Typical attack path

1. Scan for Yii 2 applications, especially public web applications exposing forms, API endpoints, or actions that accept complex request bodies.
2. Fingerprint the Yii version through dependency metadata, error pages, asset paths, HTTP behavior, or application-specific responses.
3. Send crafted requests containing nested attacker-controlled data with a __class key to endpoints that may pass input into Yii behavior attachment or object creation logic.
4. Trigger the vulnerable behavior attachment path so Yii processes attacker-controlled class configuration through the alternate path.
5. Achieve code execution or another high-impact server-side action if a reachable class chain and application code path are present.
6. Execute commands under the PHP web server account, often via php-fpm, Apache, or Nginx-backed PHP execution.
7. Establish persistence by writing PHP web shells, modifying application files, adding scheduled tasks, or planting additional access mechanisms.
8. Harvest secrets from application configuration, environment variables, database credentials, cloud credentials, and session material.
9. Use the compromised application to access databases, internal APIs, or other systems reachable from the web server.

How to detect it

To determine whether exploitation already occurred, review web server, WAF, reverse proxy, CDN, load balancer, PHP-FPM, application, container, and EDR logs. Focus on the period from February 2025 onward because exploitation was reported during February through April 2025 and the issue remains KEV-listed. Search for HTTP requests containing __class in query strings, form bodies, JSON payloads, multipart bodies, or URL-encoded variants, especially requests to Yii routes that accept nested arrays or user-controlled model/configuration data. Correlate suspicious requests with HTTP 500 errors, Yii stack traces, behavior attachment errors, unexpected class instantiation errors, or sudden successful responses after probing. On hosts, look for PHP web server processes spawning shells or system utilities, newly created PHP files in writable directories, modified application or vendor files, unexpected cron entries, abnormal outbound network connections, and access to configuration files immediately after suspicious requests. If exploitation is suspected, preserve logs and filesystem timestamps before cleanup, capture relevant containers or VM snapshots, and rotate secrets after containment.

• __class
• %5F%5Fclass
• %255F%255Fclass
• "__class"
• '__class'
• [__class]
• %5B__class%5D
• yii\\base\\Behavior
• yii\\base\\Component
• vendor/yiisoft/yii2
• vendor/yiisoft/yii2/base/Component.php
• vendor/yiisoft/yii2/BaseYii.php
• php-fpm spawned /bin/sh
• php-fpm spawned /bin/bash
• apache2 spawned /bin/sh
• httpd spawned /bin/sh
• www-data spawned /bin/sh
• /tmp/.php
• /var/www/html/runtime/
• /var/www/html/web/assets/

What your security team should do

• Immediately inventory all applications using yiisoft/yii2 and prioritize internet-facing systems, administrative portals, APIs, and applications accepting complex nested request data.
• Upgrade all affected Yii 2 deployments to 2.0.52 or later, or to a Git revision containing 40fe496eda529fd1d933b56a1022ec32d3cd0b12 or later.
• Treat vulnerable public Yii applications as high-risk due to active exploitation, KEV listing, and high EPSS probability; do not rely on compensating controls as a long-term fix.
• Hunt historical logs from at least February 2025 onward for requests containing __class and related encoded variants, especially POST, PUT, PATCH, JSON, and multipart requests.
• Review compromised-host indicators on web servers, including unexpected PHP files, modified vendor code, new cron jobs, suspicious outbound connections, and command execution by web server processes.
• Add WAF and application-layer detections for request bodies or parameters containing __class until patching is complete, while monitoring for false positives.
• Rotate application secrets, database credentials, API tokens, and session signing keys if exploitation is suspected or confirmed.
• Ensure PHP, web server, and application logs retain request bodies or security telemetry where legally and operationally appropriate for future exploitation investigations.