CVE-2026-92593 in Craft CMS
Summary
by MITRE • 09/17/2026
Craft CMS versions 5.10.0 through 5.10.12 contain an incomplete fix for CVE-2026-55794: the Controller::getPostedRedirectUrl() -> View::renderObjectTemplate() sink remained unsandboxed, and the same fix commit added a self-signing oracle in Cp::elementLabelHtml(). Because Craft/Yii HMAC tokens are not bound to a parameter name, an authenticated low-privilege control panel user with edit rights on a single element type can mint a token over attacker-controlled Twig for the returnUrl parameter and replay it as the redirect POST parameter, reaching the unsandboxed sink and achieving server-side template injection that executes arbitrary PHP code (full server compromise). The issue is fixed in 5.10.13.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
Craft CMS versions ranging from 5.10.0 through 5.10.12 suffer from a critical incomplete remediation of CVE-2026-55794, which results in a severe server-side template injection vulnerability leading to arbitrary code execution. The root cause lies in the Controller::getPostedRedirectUrl() function, which passes user-controlled input directly into View::renderObjectTemplate(). This sink was intended to be sandboxed by previous security patches but remains unsandboxed in these specific versions. Consequently, an attacker can inject malicious Twig templates that are rendered with full PHP execution privileges, bypassing the expected isolation mechanisms designed to prevent template injection attacks.
The vulnerability is exacerbated by a flawed implementation of cryptographic token validation within the Content Policy class method Cp::elementLabelHtml(). This function introduced a self-signing oracle due to improper handling of HMAC tokens generated by the Yii framework. In standard secure implementations, HMAC tokens should be bound to specific parameter names and contexts to prevent reuse across different parameters or actions. However, because Craft CMS utilizes Yii's HMAC implementation without binding tokens to their intended parameter context, an attacker can exploit this lack of contextual integrity. This allows for token replay attacks where a validly signed token generated for one purpose is repurposed in another context that leads directly into the vulnerable template rendering engine.
An authenticated low-privilege control panel user with edit rights on at least one element type can leverage this flaw to achieve full server compromise. The attack vector involves crafting a specific HTTP POST request where the attacker controls both the returnUrl parameter and the redirect POST parameter. By minting an HMAC token over attacker-controlled Twig code for the returnUrl, the attacker creates a valid signature that Yii's validation logic accepts as legitimate. When this token is replayed via the redirect parameter, it triggers the unsandboxed renderObjectTemplate sink. The template engine then processes the injected Twig syntax, which includes arbitrary PHP commands, resulting in remote code execution on the server hosting the Craft CMS instance.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and specifically maps to ATT&CK technique T1059 Command and Scripting Interpreter via template injection mechanisms. The impact is catastrophic as it allows an attacker who has only minimal user privileges, such as the ability to edit content elements, to escalate their access to full administrative control over the underlying server infrastructure. This undermines the principle of least privilege within the CMS environment and exposes sensitive data stored on the backend systems to theft or manipulation.
The issue was addressed in Craft CMS version 5.10.13 through a more rigorous implementation of token binding and sandboxing for template rendering functions. Administrators running affected versions must upgrade immediately to mitigate this risk. In addition to upgrading, organizations should enforce strict access controls on control panel users, ensuring that only trusted individuals have edit rights even if they are classified as low-privilege accounts. Implementing web application firewalls with rules specifically targeting Twig injection patterns can provide an additional layer of defense during the transition period. Regular security audits and penetration testing focusing on template rendering sinks should be conducted to identify similar incomplete fixes in other components of the CMS ecosystem.