CVE-2026-92592 in Craft CMS
Summary
by MITRE • 09/17/2026
Craft CMS 4.8.0 through 4.18.5 and 5.0.0 through 5.10.12 sign an authenticated user's attacker-controlled license-shun cookie with the same key and format used to validate signed redirect parameters, because the HMAC signature is not bound to its purpose (Yii's cookieValidationKey is derived from the same Craft securityKey used for signed request parameters). An authenticated, non-administrator user (Control Panel access is not required) can set the cookie via the license-shun endpoint and transplant the signed envelope into the redirect parameter; on a successful login, Craft validates the signature and renders the authenticated bytes as an unsandboxed Twig template, where Twig's map filter accepts a string callback and allows PHP system() to execute arbitrary operating-system commands as the web-server user. Exploitation requires an account using password authentication without active 2FA, the default request configuration, and availability of PHP system(). The issue is fixed in 4.18.6 and 5.10.13.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified involves a critical flaw in Craft CMS versions 4.8.0 through 4.18.5 and 5.0.0 through 5.10.12, stemming from an improper binding of cryptographic signatures to their intended purposes. The application utilizes Yii's cookieValidationKey for signing cookies, which is derived directly from the same Craft securityKey used to validate signed request parameters such as redirect URLs. This shared key mechanism means that a signature generated for one purpose can be validly interpreted and executed in another context if the underlying data structure allows it. Specifically, an attacker who has obtained or created an authenticated user session can manipulate the license-shun cookie by injecting attacker-controlled content into its value field. Because the HMAC signature is not bound to the specific semantic meaning of the cookie but rather just validates that the payload was signed by a trusted key, this maliciously crafted cookie data can be extracted and transplanted into other parts of the application's request flow, particularly those involving redirect parameters or template rendering logic.
The exploitation chain begins with an authenticated user account using password authentication without active two-factor authentication enabled. The attacker accesses the license-shun endpoint to set a specially constructed cookie containing malicious payload data signed with the shared key. Upon subsequent interactions where Craft CMS processes this data as part of its normal operation, specifically during login or session validation sequences, the application treats the transplanted bytes not merely as metadata but as executable template code within Twig. The vulnerability lies in how Twig's map filter is implemented; it accepts a string callback which can be manipulated to invoke PHP system functions. Consequently, when the authenticated user logs in and the CMS processes these unsandboxed Twig templates, arbitrary operating-system commands are executed with the privileges of the web-server process. This represents a severe remote code execution vulnerability that bypasses standard authentication controls due to the misconfiguration of cryptographic binding rather than a failure of access control itself.
From an industry standards perspective, this flaw aligns closely with CWE-345 Insufficient Verification of Data Authenticity and CWE-918 Server-Side Request Forgery if viewed through the lens of redirect manipulation, but more accurately fits CWE-77 Command Injection due to the final execution outcome via Twig's map filter. In terms of MITRE ATT&CK framework classification, this vulnerability facilitates initial access followed by command-and-control or execution phases depending on how the remote code is leveraged post-exploitation. The core issue reflects a design flaw where cryptographic primitives are reused across different security contexts without proper domain separation, leading to signature transposition attacks. This type of error is particularly dangerous because it allows low-privilege users to escalate their impact significantly by leveraging framework-level features like template engines that have powerful execution capabilities when misconfigured or exploited through injection points.
Mitigation strategies must address both the immediate technical flaw and broader security hygiene practices. The primary remediation involves upgrading Craft CMS to version 4.18.6 or later, where this issue has been resolved by ensuring proper separation of signing keys or binding signatures more strictly to their specific use cases so that cookie data cannot be reused in template rendering contexts. For organizations unable to upgrade immediately, disabling the license-shun endpoint if not required for business operations can reduce the attack surface. Additionally enforcing multi-factor authentication across all user accounts eliminates the prerequisite condition of password-only authentication, thereby preventing attackers from establishing the initial authenticated session needed to trigger this chain. Administrators should also review Twig configurations to ensure that dangerous filters like map are restricted or sandboxed appropriately within custom modules if they must remain enabled for legitimate functionality. Regular security audits focusing on cryptographic key management and template engine usage patterns will help prevent similar architectural flaws in future development cycles.