CVE-2026-65007: grav forged keys enable account

CISO Take

Grav's official API plugin (grav-plugin-api) checks only the baseline admin.login permission before letting a panel user generate or revoke API keys for any account, so any authenticated low-privileged user can forge a persistent API key bound to a higher-privileged account and inherit its permissions. With a 9.6 CVSS score, no user interaction required, and only low privileges needed, this is trivially exploitable by anyone who has any login on the Grav admin panel — the flaw is a missing ACL check, not a complex chain, so a working exploit is plausible soon even though none is public yet and EPSS/KEV data isn't available for a CVE published today. Important caveat for this feed: Grav is a general-purpose flat-file CMS, not an AI/ML framework or tool — it appears here tagged 'ml_ui', but there is no genuine AI-specific attack surface or AI supply-chain angle; it only matters to your risk picture if Grav happens to run somewhere in your stack (e.g., fronting product docs, an internal wiki, or an admin panel adjacent to AI systems). Patch to grav-plugin-api 1.0.8+ immediately and audit/rotate any existing API keys tied to high-privilege accounts.

Sources: NVD GitHub Advisory vulncheck.com

What is the risk?

Critical on paper (CVSS 9.6, AV:N/AC:L/PR:L/UI:N) because exploitation requires nothing more than any authenticated panel account and a single crafted admin-task call — there's no complex precondition, adversarial input crafting, or AI-specific knowledge involved. The realistic risk is bounded by exposure: it only matters for organizations actually running Grav with the API plugin enabled and multiple accounts of differing privilege. No public PoC, Nuclei template, or KEV listing exists yet, so this is a 'patch before it's weaponized' situation rather than an active-exploitation emergency. Given the missing-authorization pattern (CWE-862) is simple to spot and exploit once known, expect exploit code to appear quickly after public disclosure.

How does the attack unfold?

Initial Access

Attacker holds or obtains a low-privileged Grav account with only the baseline admin.login permission.

Exploitation

Attacker calls the apiKeyGenerate admin task targeting a different, higher-privileged account; the plugin authorizes only on admin.login and skips the account-management ACL check.

Persistence

A forged, persistent API key is minted, bound to the target account and inheriting its full API permission set.

Impact

Attacker uses the forged key to impersonate the higher-privileged account via the API, achieving privilege escalation up to full account takeover.

Initial Access

Attacker holds or obtains a low-privileged Grav account with only the baseline admin.login permission.

Exploitation

Attacker calls the apiKeyGenerate admin task targeting a different, higher-privileged account; the plugin authorizes only on admin.login and skips the account-management ACL check.

Persistence

A forged, persistent API key is minted, bound to the target account and inheriting its full API permission set.

Impact

Attacker uses the forged key to impersonate the higher-privileged account via the API, achieving privilege escalation up to full account takeover.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
grav	—	—	No patch

Do you use grav? You're affected.

How severe is it?

CVSS 3.1

9.6 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 31% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I High

A None

What should I do?

1 step

1) Upgrade grav-plugin-api to 1.0.8 or later immediately — this is the vendor fix for the missing ACL check on apiKeyGenerate/apiKeyRevoke. 2) Audit all existing API keys post-patch: identify which accounts hold API keys, confirm each key's issuing account matches its bound account, and revoke/rotate any key that looks forged or over-privileged. 3) Apply least privilege to Grav admin accounts — minimize how many users hold admin.login beyond what they need. 4) Monitor Grav admin task logs for apiKeyGenerate/apiKeyRevoke calls targeting accounts other than the calling user, which is the exploitation signature. 5) If Grav faces the internet, consider restricting admin panel access via network controls (VPN/allowlist) as defense in depth.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Plugin API

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-65007?

Grav's official API plugin (grav-plugin-api) checks only the baseline admin.login permission before letting a panel user generate or revoke API keys for any account, so any authenticated low-privileged user can forge a persistent API key bound to a higher-privileged account and inherit its permissions. With a 9.6 CVSS score, no user interaction required, and only low privileges needed, this is trivially exploitable by anyone who has any login on the Grav admin panel — the flaw is a missing ACL check, not a complex chain, so a working exploit is plausible soon even though none is public yet and EPSS/KEV data isn't available for a CVE published today. Important caveat for this feed: Grav is a general-purpose flat-file CMS, not an AI/ML framework or tool — it appears here tagged 'ml_ui', but there is no genuine AI-specific attack surface or AI supply-chain angle; it only matters to your risk picture if Grav happens to run somewhere in your stack (e.g., fronting product docs, an internal wiki, or an admin panel adjacent to AI systems). Patch to grav-plugin-api 1.0.8+ immediately and audit/rotate any existing API keys tied to high-privilege accounts.

Is CVE-2026-65007 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-65007, increasing the risk of exploitation.

How to fix CVE-2026-65007?

1) Upgrade grav-plugin-api to 1.0.8 or later immediately — this is the vendor fix for the missing ACL check on apiKeyGenerate/apiKeyRevoke. 2) Audit all existing API keys post-patch: identify which accounts hold API keys, confirm each key's issuing account matches its bound account, and revoke/rotate any key that looks forged or over-privileged. 3) Apply least privilege to Grav admin accounts — minimize how many users hold admin.login beyond what they need. 4) Monitor Grav admin task logs for apiKeyGenerate/apiKeyRevoke calls targeting accounts other than the calling user, which is the exploitation signature. 5) If Grav faces the internet, consider restricting admin panel access via network controls (VPN/allowlist) as defense in depth.

What is the CVSS score for CVE-2026-65007?

CVE-2026-65007 has a CVSS v3.1 base score of 9.6 (CRITICAL). The EPSS exploitation probability is 0.37%.

What are the technical details?

Original Advisory

The Grav api plugin (grav-plugin-api) before 1.0.8 fails to properly authorize API key generation and revocation: the plugin intercepts the apiKeyGenerate/apiKeyRevoke admin tasks before the account-management ACL runs and authorizes the caller on only the admin.login permission (the baseline permission held by every panel user). This allows any user with admin.login to mint a persistent API key bound to any account, and the forged key inherits the target account's API permissions. On installs where an API-enabled account holds broader permissions, this enables account impersonation and privilege escalation up to account takeover.

Exploitation Scenario

An attacker obtains or already holds credentials for a low-privileged Grav account that only has the baseline admin.login permission (e.g., a content editor). They send the apiKeyGenerate admin task request but target a different, higher-privileged account known to have broad API permissions (e.g., a superadmin or integration account). Because the plugin only checks that the caller has admin.login — not that the caller is authorized to manage the target account — the request succeeds and mints a new persistent API key bound to the victim account. The attacker now uses that forged key to call Grav's API as the victim account, inheriting its full permission set to read/modify site content, alter configuration, or pivot toward further compromise (e.g., installing a malicious plugin for code execution), all without ever needing the victim's actual password.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.