Grav API plugin CVE-2026-62231

Exploitation requires the attacker to possess a valid Grav API plugin key of any scope on a version before 1.0.6 - this is the PR:L authenticated prerequisite from the CVSS vector. The specific triggering condition is a deployment that relies on the plugin's scoped API key feature: any key created with a restricted scopes array (e.g. read-only) is silently promoted to the full permissions of its owning user because ApiKeyAuthenticator never enforces scopes. Limiting factors are that the attacker must first obtain a key (keys are not created by unauthenticated outsiders), the effective privileges are capped at whatever the key owner is authorized for, and environments that only ever issue full-access keys gain no additional exposure since the bug only defeats the scope restriction itself.

The vendor CVSS 4.0 score of 8.6 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N reflects a network-reachable, low-complexity flaw requiring only low privileges (a valid but restricted API key) and no user interaction, yielding high confidentiality and integrity impact with no availability impact. This is internally consistent: an attacker must already hold a working API key, so it is a privilege-escalation-within-authentication issue rather than a fully unauthenticated compromise. There is no EPSS score, no KEV listing, and no public POC in the provided data, so real-world risk hinges on how many deployments issue scoped keys to semi-trusted parties under the false assumption those scopes are enforced. The danger is that operators may have deliberately handed out read-only keys believing them safe - those keys are in fact fully privileged, making this a meaningful priority for any environment that relies on Grav API key scoping, even though widespread opportunistic exploitation is unlikely given the plugin's limited footprint.

An organization issues a contractor a read-only Grav API key to pull content. Because ApiKeyAuthenticator ignores the scopes array and grants the owning user's full permissions, the contractor simply sends write, delete, or admin API requests with that same key and they succeed. No public POC is identified, but the attack requires only the already-issued key and ordinary HTTP requests.