GHSA-F5WM-88JV-G5HX: Authenticated Remote Code Execution via Twig Sandbox Escape in Craft CMS

Craft CMS relies on the Twig template engine to render dynamic views and user-customizable content securely. To protect the underlying server, Craft CMS provides an optional Twig sandbox capability using the enableTwigSandbox() configuration. This sandbox restricts access to unsafe PHP classes, functions, properties, and methods, ensuring that template authors operate within a safe subset of APIs.

The vulnerability identified as GHSA-F5WM-88JV-G5HX represents a breakdown of this sandbox boundary. A flaw in the custom SecurityPolicy class allowed administrative users with template customization privileges to bypass class and method restrictions entirely. By executing arbitrary PHP logic within the template environment, an authenticated attacker can achieve remote code execution.

The core of the issue lies in how the application manages permissions for classes implementing the ElementInterface. Because Craft CMS trusted entire interfaces at a class level, any subclass inheriting from these interfaces was granted access to its entire object hierarchy. This exposed low-level framework capabilities from the underlying Yii Framework to the sandbox engine.

The sandbox implementation in Craft CMS utilizes the SecurityPolicy class to enforce access controls during template compilation and execution. When rendering a template, Twig queries the security policy's checkMethodAllowed($obj, $method) and checkPropertyAllowed($obj, $property) methods. These checks confirm whether the targeted object and its called method are explicitly allowed by configuration or decorator attributes.

Prior to the patch, the security policy evaluated object eligibility based on whether the class or one of its implemented interfaces carried the #[AllowedInSandbox] attribute. Once an interface was labeled with this attribute, the policy permitted access to any public method on any object implementing that interface. It failed to restrict method access strictly to those defined by the allowed interface itself.

The critical failure occurs with ElementInterface, which was annotated with #[AllowedInSandbox]. Every major content class in Craft CMS, such as Entry, User, Asset, and Category, implements this interface. Because these models inherit from the base Element class, they also inherit from yii\base\Component, a foundational class in the Yii Framework.

As a consequence of the class-level allowlisting model, the Twig sandbox permitted execution of all public methods belonging to yii\base\Component on any active Element instance. This exposed the dynamic attachBehavior($name, $behavior) method to the sandboxed environment. This specific method acts as a class-loading utility that instantiates arbitrary PHP classes when supplied with a configuration array.

The vulnerability was patched by transitioning from a broad class-level trust model to a strict, granular method-level verification strategy. In the vulnerable implementation, the SecurityPolicy class relied on class-level checks that allowed any inherited method of an allowed object. The fix introduces a new contract, craft\web\twig\AllowableInSandbox, which requires classes to explicitly validate their own exposed methods.

The following diagram illustrates the vulnerable inheritance chain and how Yii's framework mechanisms were exposed through the sandbox:

The patch removed the #[AllowedInSandbox] attribute from ElementInterface and altered SecurityPolicy.php to delegate checks to the target object.

// Patched implementation in craft/web/twig/SecurityPolicy.php
public function checkMethodAllowed($obj, $method): void
{
    if ($obj instanceof AllowableInSandbox && $obj->methodAllowedInSandbox($method)) {
        return;
    }
    // ... original checks continue ...
}

The base Element class now implements AllowableInSandbox and enforces strict controls over which methods can run. By default, it returns false for arbitrary method calls, completely blocking inherited parent methods.

// Patched implementation in craft/base/Element.php
abstract class Element extends Component implements ElementInterface, AllowableInSandbox
{
    public function methodAllowedInSandbox(string $method): bool
    {
        // Disallow all methods by default unless explicitly permitted
        return false;
    }
 
    public function propertyAllowedInSandbox(string $property): bool
    {
        // Explicitly allow only safe dynamic properties like field handles
        if ($this->hasEagerLoadedElements($property) || $this->fieldByHandle($property) !== null) {
            return true;
        }
        return false;
    }
}

To exploit this vulnerability, an attacker must have administrative or editor access to the Craft CMS control panel with permissions to modify templates that are rendered in a sandboxed context. The target template must have access to a variable representing a Craft Element, such as an entry object, which is standard in many CMS configurations.

The attacker injects a malicious Twig payload designed to invoke the attachBehavior method on the exposed element. The method accepts a behavior configuration array. When the second argument is an array, Yii’s underlying dependency injection engine invokes Yii::createObject() to resolve and hydrate the class specified by the class key.

The attacker selects a behavior class that provides a callback hook capable of running system functions. A common target is yii\behaviors\AttributeTypecastBehavior. By structuring the behavior to map typecasting events to an executable system process class, such as Psy\Readline\Hoa\ConsoleProcessus, the attacker configures an execution path.

Once the behavior is attached, the attacker triggers the associated event callback within the template. When the template calls the trigger() method with the targeted event name, the application processes the behavior chain. This evaluates the payload and executes the arbitrary command string on the hosting operating system, running with the privileges of the web server user.

The impact of GHSA-F5WM-88JV-G5HX is critical, representing complete administrative takeover of the hosting server environment. Successful exploitation grants the attacker the ability to execute arbitrary operating system commands. This execution bypasses all application-layer security boundaries, data separation controls, and database user limitations.

With remote command execution capabilities, the attacker can access sensitive environment variables, read database credentials from configurations, and exfiltrate database contents. The attacker can also write malicious scripts to the web root, establishing persistent web shells for long-term access. This enables lateral movement within the hosting network or infrastructure.

Because the vulnerability requires authenticated access, the risk is slightly mitigated compared to unauthenticated RCE exploits. However, inside threats, compromised low-privileged administrator credentials, or cross-site scripting (XSS) attacks targeting administrators can still serve as vectors to trigger this exploit. The severity remains high due to the absolute compromise of system integrity.

The primary remediation strategy is upgrading the Craft CMS installation to a patched version. The maintainers have released updates that address this vulnerability by implementing strict sandbox validation routines. Users on the 4.x branch must upgrade to version 4.18.3 or higher, while users on the 5.x branch must upgrade to version 5.10.7 or higher.

If an immediate upgrade is not feasible, administrators must implement mitigation steps to minimize the attack surface. Access to template editing capabilities within the control panel should be strictly revoked for all non-essential administrative accounts. This limits the exposure of sandboxed template rendering endpoints to highly trusted personnel only.

Additionally, web application firewalls can be configured to inspect control panel requests for known exploit patterns. Rules should block requests containing references to dynamic Yii behaviors or process execution paths. Specifically, payloads containing "class": "yii\\behaviors\\" or ConsoleProcessus should be flagged and rejected at the gateway level.