Craft CMS CVE-2026-86732

Exploitation requires a valid Craft CMS account with content-editor privileges (PR:L); unauthenticated network access alone is insufficient to reach the element-index endpoint. The attack additionally requires that the PHP web process has read access to a Yii application log file that accepts attacker-influenced content - this is the default Craft CMS configuration and does not require any non-default setting. The target instance must be running Craft CMS below version 5.10.12. The attacker must be able to make arbitrary HTTP requests to the target host to poison the log via the User-Agent header. No victim-side user interaction is required once the log is poisoned and the exploit request is submitted.

The CVSS 4.0 score of 8.7 (High) with AV:N/AC:L/AT:N/PR:L/UI:N reflects the practical risk well: any authenticated content editor can exploit this with no user interaction and no unusual server configuration. Low complexity is appropriate given the systematic, advisory-documented technique - even a mid-sized municipal IT team in olsztyn should treat this as urgent if their Craft CMS instance permits self-service content-editor registration or if the platform is multi-tenant. No active exploitation is confirmed (not listed in CISA KEV) and no standalone public exploit tool is identified in the provided data; however, the gadget chain is fully described in the VulnCheck and GitHub Security Advisory sources, which substantially reduces the reverse-engineering burden for potential attackers. EPSS data is not provided, but the combination of network reachability, low-privilege requirement, and a clearly documented exploit path suggests elevated real-world exploitation probability compared to opaque high-CVSS issues. The principal limiting factor is the requirement for a valid content-editor account, which constrains opportunistic mass exploitation but not targeted campaigns.

An attacker holding a content-editor account - obtained legitimately, via credential stuffing, or through a separate account-takeover - first sends an HTTP request with a User-Agent header containing a PHP webshell one-liner, which Yii's request logger writes verbatim to the application log. The attacker then POSTs to the element-index endpoint with criteria[withTransforms][0][class] set to yii\rbac\PhpManager and the itemFile property pointing to the known log path, causing normalizeTransform() to instantiate PhpManager, which includes the log file as PHP and executes the embedded payload. The result is a server-side webshell running as the web server process user, granting access to the application database credentials, environment secrets, and potentially adjacent internal services.