Grav API Plugin CVE-2026-62667

Exploitation requires possession of a valid Grav API Plugin API key (corresponding to PR:L in the CVSS vector). The vulnerability is present in the default code path of all installations of the plugin below version 1.0.6 - no non-default configuration, feature flag, or special deployment mode is required; the scope bypass occurs whenever any scoped API key is used for authentication. The key must have been generated by the vulnerable plugin (< 1.0.6). Exploitation is bounded by the owning account's ACL: a key issued by a standard editor cannot exceed editor-level permissions, while a key issued by a super-admin account exposes full administrative capabilities. The limiting factor is that the attacker must have been issued or must have obtained a valid API key for the target site - opportunistic scanning for exploitable endpoints is not viable without a pre-existing key.

The NVD CVSS 8.1 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) is well-calibrated: the flaw is network-accessible, requires no user interaction, and yields high confidentiality and integrity impact. The critical qualifying factor is PR:L - exploitation is gated on possession of a valid API key, limiting opportunistic mass exploitation. The real-world threat model centers on trust boundary violations: a service intentionally granted a narrow read scope (e.g., a preview frontend or analytics hook) can quietly escalate to full administrative control of the site. EPSS data was not provided in the input, so exploitation probability cannot be quantified. KEV status is not confirmed, indicating no known active exploitation at time of analysis. No POC code was identified. Despite the high CVSS, the gating requirement of a valid API key and knowledge of the REST API surface meaningfully reduces the realistic attacker pool compared to a fully unauthenticated flaw. The most dangerous scenario involves a super-admin-owned key issued to a less-trusted party, as the full admin ACL becomes accessible.

A third-party analytics service was issued an API key with a read-only scope by a site administrator. Using that key, the service operator calls a privileged REST endpoint such as POST /api/users or DELETE /api/pages/{id}. Because ApiKeyAuthenticator returns the full admin identity without consulting the stored scopes, requirePermission() grants the request based on the admin account's ACL, and the operation succeeds. The administrator has no visibility into this escalation, as the key appeared legitimately scoped at issuance. No public exploit code has been identified at time of analysis.