high · 5.9CVE-2026-74907Sep 17, 2026

CVE-2026-74907: Grav CMS Unauthenticated Path Traversal via plugin-asset-map.php

Rohit Hatagale
AI Security Researcher, SecureLayer7

A missing directory-boundary check in Grav's fast static asset server lets unauthenticated attackers read files from sibling directories that were never meant to be public, with no login required.

Packagegetgrav/grav
Ecosystemcomposer
Affected<= 2.0.14
Fixed in2.0.15

The problem

Grav's top-level index.php includes a fast-path static asset server that fires before the CMS even boots. It is gated on the presence of user/config/plugin-asset-map.php, an opt-in file created by plugins that bundle single-page apps.

When that file exists, any HTTP request is handled with no authentication check at all. The containment test that was supposed to keep responses inside the published asset directory was broken, letting attackers escape into unintended sibling directories.

Proof of concept

A working proof-of-concept for CVE-2026-74907 in getgrav/grav, with the exact payload below.

http
GET /myplugin-assets/../assets-secret/config.php HTTP/1.1
Host: target.example.com

The vulnerable code resolves the requested path with realpath() (so classic ../../etc/passwd traversals are blocked) and then checks str_starts_with($realFile, $realBase). That is a plain string-prefix test with no separator awareness. A directory named assets-secret sitting next to the configured assets base will pass the check because the string assets-secret/... literally starts with assets.

The patch appends DIRECTORY_SEPARATOR before the comparison, changing it to str_starts_with($realFile, $realBase . DIRECTORY_SEPARATOR). This forces the match to end exactly at a directory boundary, making the assets-secret escape impossible. The fix is in commit d5f89d95d94cc155bc3be998ee85527a7be073dd and shipped in Grav 2.0.15.

The fix

Upgrade getgrav/grav to 2.0.15 or later. If you cannot upgrade immediately, either remove user/config/plugin-asset-map.php (disabling the fast-path entirely) or add a web-server rule that blocks traversal sequences (../) in the URL path before PHP is reached.

Reported by alham-rizvi.

References: [1][2][3][4]

Related research