Grav CMS EUVD-2026-60588

Exploitation requires that the Grav installation has at least one sibling directory in the web root whose name begins with the configured asset base string (e.g., a directory named 'assets-backup', 'assets-private', or 'assets-vendor' adjacent to the legitimate 'assets' directory). The attacker must additionally know or guess a valid filename within that sibling directory, as no directory listing is implied by the vulnerability. No authentication is required - the CVSS 4.0 PR:N metric and CVE description both confirm unauthenticated access. Sites where no sibling directory with a name extending the asset base string exists are not exploitable regardless of Grav version. The CVSS 4.0 AT:P metric explicitly encodes this deployment dependency, and AC:H reflects that successful exploitation is contingent on this environmental condition rather than universally achievable.

The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) scores 8.2, reflecting a network-reachable, unauthenticated, high-confidentiality-impact flaw that is nonetheless conditioned on a specific deployment state. Both AC:H and AT:P encode the same real-world constraint: a sibling directory whose name begins with the asset base string must exist on the target host and contain content worth exfiltrating. This condition is plausible - naming conventions like assets-private, assets-backup, or assets-vendor are natural - but not universal, meaning a large fraction of Grav deployments may not be exploitable even without patching. There is no CISA KEV listing and no public proof-of-concept identified in the provided intelligence, which is consistent with targeted rather than opportunistic exploitation. The confidentiality-only impact (VI:N, VA:N in CVSS 4.0) bounds the blast radius: attackers can read files accessible to the web process but cannot write, delete, or disrupt availability. Real-world priority is moderate-high: the patch is available and the fix cost is low, but the deployment condition prevents treating this as a universal emergency.

An attacker targeting a Grav site enumerates the web root and identifies or guesses that a directory named assets-private exists alongside the legitimate assets directory, perhaps because the application uses a predictable naming convention for private uploads or backup files. The attacker sends an unauthenticated HTTP GET request for /assets-private/config.yaml; index.php evaluates that the path string starts with 'assets', considers it a valid asset request, and serves the file directly, returning sensitive configuration data including database credentials or API keys. No special tooling is required - a standard HTTP client or browser suffices.