CVE-2026-72826 in grav-plugin-api
Summary
by MITRE • 08/14/2026
The getgrav/grav-plugin-api plugin before 1.0.13 fails to validate that the scopes of a newly created API key are a subset of the caller's scopes in createApiKey. The self-target path of requireApiKeyPermission() requires only the baseline api.access scope, and the new key's scopes are read directly from the request body with no subset check. An attacker holding a minimal-scope API key on a super account can submit an empty scopes array to mint an unscoped, full-access super key, bypassing scope restrictions (and enabling further chains such as configuration write to RCE).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability in getgrav/grav-plugin-api plugin versions prior to 1.0.13 represents a critical authorization bypass flaw that stems from inadequate scope validation during API key creation processes. This weakness allows malicious actors with minimal privileged access to escalate their capabilities significantly within the application's security framework. The core issue manifests in the createApiKey function where the system fails to enforce proper scope inheritance and validation mechanisms, creating a pathway for unauthorized privilege escalation through carefully crafted API requests.
The technical flaw occurs due to the improper implementation of the requireApiKeyPermission() function which only demands the baseline api.access scope for self-target paths, while simultaneously allowing new API keys to be created with unrestricted scopes directly sourced from user-provided request data. This design flaw creates a direct attack vector where an attacker possessing even the most limited API key can manipulate the scopes parameter to generate new keys with full administrative privileges. The vulnerability is particularly dangerous because it operates without any subset validation checks that should ensure newly created keys cannot exceed the scope of their creators.
From an operational perspective, this vulnerability enables attackers to bypass the intended security boundaries of the API access control system, potentially leading to complete system compromise. An attacker who has gained access to a minimal-scope API key on a super user account can exploit this flaw by submitting an empty scopes array in their API key creation request, thereby generating an unscoped key with full administrative access. This capability provides attackers with direct access to sensitive configuration data and system controls that could enable further exploitation chains including arbitrary code execution through configuration file modifications.
The security implications of this vulnerability align with CWE-264, which addresses permissions, privileges, and access controls weaknesses in software systems. This particular implementation flaw represents a classic case of insufficient authorization checks where the system fails to properly validate that new API key scopes are subsets of existing user permissions. The attack vector also maps to ATT&CK technique T1548.002 for privilege escalation through API keys, demonstrating how weakened access controls can be leveraged to gain elevated system privileges.
Organizations should implement immediate mitigations including updating to version 1.0.13 or later of the getgrav/grav-plugin-api plugin, which includes proper scope validation mechanisms. Additionally, administrators should review existing API key permissions and revoke any unnecessary high-privilege keys while implementing monitoring for unusual API key creation patterns. The fix should enforce that new API key scopes must be validated as subsets of the calling user's existing scopes, preventing the creation of keys with broader access than their creators possess. This approach ensures proper principle of least privilege enforcement throughout the API access control system and prevents similar escalation attacks from succeeding in the future.