CVE-2026-64852: authz bypass enables privilege

CISO Take

The Grav CMS API Plugin (fixed in 1.0.8) checks only whether a caller holds a generic 'admin.login' permission when processing apiKeyGenerate and apiKeyRevoke requests, instead of verifying the caller owns the target account — so any low-privileged panel user can mint a persistent API key bound to a more privileged account, including one with api.super, and inherit its full administrative access. This is a classic broken access control / IDOR flaw (CWE-862), not an AI/ML-specific vulnerability: Grav is a general-purpose flat-file CMS, and neither the plugin nor the exploitation path touches a model, inference pipeline, agent, or vector store. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template published yet, but the flaw requires only a valid low-privilege account and a single crafted admin task call, which puts it at trivial exploitation complexity for anyone who already has any panel login. If Grav (with this plugin) is used anywhere in the environment — including as a headless content backend feeding an AI-generated content pipeline or internal tooling — upgrade the api plugin to 1.0.8 immediately and audit existing ApiKeyManager credentials for keys bound to high-privilege accounts that weren't created by those accounts themselves.

Sources:NVDGitHub Advisory

What is the risk?

This is a low-complexity, trivially exploitable broken access control vulnerability (CWE-862) with a clear vertical privilege escalation path: any authenticated basic user can escalate to api.super/admin-equivalent access by targeting another account's API key lifecycle. However, it carries no confirmed CVSS/EPSS score, is not in CISA KEV, and has no known public exploit or scanner coverage as of this writing — so real-world exploitation likelihood cannot be quantified from available signals. Critically, this is NOT an AI/ML-specific risk: Grav is a general PHP flat-file CMS, and the vulnerability lives entirely in the plugin's authorization logic for admin API key management, with no interaction with AI models, training data, inference APIs, or agent tooling. The 'ml_ui' AI-category tag on this CVE appears to be a misclassification and should be treated with low confidence for AI-threat-intel purposes.

How does the attack unfold?

Initial Access

Attacker authenticates as a low-privilege basic panel user with legitimate but limited Grav admin credentials.

Exploitation

Attacker invokes the apiKeyGenerate admin task, selecting a higher-privilege target account instead of their own since the endpoint only verifies admin.login, not account ownership.

Persistence

A persistent ApiKeyManager credential is created bound to the target account, giving the attacker a durable, out-of-band access token independent of the original login.

Impact

Attacker uses the inherited API key to exercise the target's full permissions, including api.super administrative write access to site content and configuration.

Initial Access

Attacker authenticates as a low-privilege basic panel user with legitimate but limited Grav admin credentials.

Exploitation

Attacker invokes the apiKeyGenerate admin task, selecting a higher-privilege target account instead of their own since the endpoint only verifies admin.login, not account ownership.

Persistence

A persistent ApiKeyManager credential is created bound to the target account, giving the attacker a durable, out-of-band access token independent of the original login.

Impact

Attacker uses the inherited API key to exercise the target's full permissions, including api.super administrative write access to site content and configuration.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% 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 should I do?

1 step

Upgrade the Grav API Plugin to version 1.0.8 or later, which fixes the authorization check in the apiKeyGenerate and apiKeyRevoke admin tasks (see the linked GitHub commit and GHSA-7v74-m76q-8wf3). As a compensating control before patching, restrict admin panel access to trusted accounts only and disable or closely monitor the API plugin's key-management tasks. After patching, audit the ApiKeyManager credential store for any existing API keys bound to high-privilege (api.super) accounts that were not created through that account's own session — these are indicators of prior exploitation and should be revoked. If Grav feeds any downstream AI/content pipeline, verify that pipeline's ingestion credentials were not the target of a prior key-generation abuse.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

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

How is it classified?

Auth BypassPrivacy ViolationPluginAPI

Which compliance frameworks are affected?

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

Frequently Asked Questions

What is CVE-2026-64852?

The Grav CMS API Plugin (fixed in 1.0.8) checks only whether a caller holds a generic 'admin.login' permission when processing apiKeyGenerate and apiKeyRevoke requests, instead of verifying the caller owns the target account — so any low-privileged panel user can mint a persistent API key bound to a more privileged account, including one with api.super, and inherit its full administrative access. This is a classic broken access control / IDOR flaw (CWE-862), not an AI/ML-specific vulnerability: Grav is a general-purpose flat-file CMS, and neither the plugin nor the exploitation path touches a model, inference pipeline, agent, or vector store. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template published yet, but the flaw requires only a valid low-privilege account and a single crafted admin task call, which puts it at trivial exploitation complexity for anyone who already has any panel login. If Grav (with this plugin) is used anywhere in the environment — including as a headless content backend feeding an AI-generated content pipeline or internal tooling — upgrade the api plugin to 1.0.8 immediately and audit existing ApiKeyManager credentials for keys bound to high-privilege accounts that weren't created by those accounts themselves.

Is CVE-2026-64852 actively exploited?

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

How to fix CVE-2026-64852?

Upgrade the Grav API Plugin to version 1.0.8 or later, which fixes the authorization check in the apiKeyGenerate and apiKeyRevoke admin tasks (see the linked GitHub commit and GHSA-7v74-m76q-8wf3). As a compensating control before patching, restrict admin panel access to trusted accounts only and disable or closely monitor the API plugin's key-management tasks. After patching, audit the ApiKeyManager credential store for any existing API keys bound to high-privilege (api.super) accounts that were not created through that account's own session — these are indicators of prior exploitation and should be revoked. If Grav feeds any downstream AI/content pipeline, verify that pipeline's ingestion credentials were not the target of a prior key-generation abuse.

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

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content. Prior to 1.0.8, the Grav API plugin intercepts the apiKeyGenerate and apiKeyRevoke admin tasks in user/plugins/api/api.php and authorizes the caller with only admin.login. A basic panel user can select another account from the route, create a persistent ApiKeyManager credential bound to that target, and inherit the target's API permissions, including api.super or administrative write access when present. This issue is fixed in version 1.0.8.

Exploitation Scenario

An attacker with a low-privilege 'basic panel user' account on a Grav site logs into the admin panel and identifies the route for apiKeyGenerate, which only checks that the caller holds admin.login (a permission the basic user already has). The attacker crafts a request selecting a high-privilege target account — for example, a site administrator with api.super — instead of their own account, and the plugin creates a persistent ApiKeyManager credential bound to that target's permissions. The attacker now holds a valid API key with the target's full privileges, including administrative write access, without ever compromising the target's actual login credentials, and can use that key for ongoing headless API access to the site's content and configuration until the key is revoked.

Weaknesses (CWE)

CWE-862Missing AuthorizationPrimary CWE-862Missing 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.