CVE-2026-80204 in API Plugin
Summary
by MITRE • 08/26/2026
The Grav API plugin (getgrav/grav-plugin-api) before 1.0.18 does not apply the API-key scope cap in the injectSecurityTab() function of BlueprintController when deciding whether a page's security/permissions blueprint section is editable. Because the function performs raw isSuperAdmin()/hasPermission() checks without a request parameter, it cannot enforce scopeAllows(). A caller holding a scoped API key may therefore see (and potentially edit) page permission fields beyond the scope granted to the key. The end-to-end write-time impact was not fully confirmed by the reporter.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The Grav CMS platform relies on a modular architecture where plugins extend core functionality, including access control and content management workflows. A significant security flaw exists within the Grav API plugin, specifically in versions prior to 1.0.18, which compromises the integrity of role-based access controls by failing to enforce scope limitations on administrative operations performed via the RESTful interface. This vulnerability centers on the injectSecurityTab function located within the BlueprintController class, a component responsible for rendering and managing the security configuration interfaces for pages within the Grav administration panel. The core issue arises from how this function evaluates whether a user or API client has permission to edit specific page permissions. Instead of validating the request against the defined scopes associated with the authenticated API key, the implementation performs direct checks using raw methods such as isSuperAdmin and hasPermission without considering any scope parameters passed in the HTTP request context.
This architectural oversight allows an attacker possessing a scoped API key to bypass intended restrictions on administrative actions. In a properly secured system, API keys are assigned specific scopes that limit their capabilities to predefined sets of resources or operations. For instance, a read-only key should not be able to modify permissions, and a limited write-key might only affect certain content types without altering security settings. However, because the injectSecurityTab function ignores these scope constraints during its permission evaluation logic, it grants access to sensitive configuration fields based solely on whether the underlying user account possesses broad administrative privileges or generic permission flags. Consequently, an authenticated attacker with a restricted API key can interact with page permission blueprints in ways that exceed their authorized capabilities, effectively elevating their privilege level within the application context through this specific vector.
The operational impact of this vulnerability is primarily related to unauthorized access and potential modification of security configurations. Although the reporter noted that the end-to-end write-time impact was not fully confirmed during initial analysis, the ability to view and potentially edit page permission fields represents a critical breach in confidentiality and integrity principles. An attacker could leverage this flaw to inspect sensitive metadata regarding who has access to specific pages or sections of the website. More critically, if the subsequent processing logic allows for actual modification based on these unchecked inputs, an attacker might alter permissions to grant themselves elevated privileges, restrict legitimate users from accessing content, or expose private data by changing visibility settings. This undermines the principle of least privilege and weakens the overall security posture of the Grav installation, particularly in multi-user environments where distinct roles are assigned via API keys for automation or integration purposes.
From a standards perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves failing to restrict access to resources based on user privileges and scopes. It also relates to CWE-798 Use of Hard-coded Credentials if the scope validation logic is entirely bypassed in favor of static checks, though more accurately it reflects a failure in authorization enforcement mechanisms common in RESTful APIs. In terms of MITRE ATT&CK mapping, this behavior facilitates privilege escalation through improper access control and could be part of an initial compromise or lateral movement strategy where an attacker exploits weak API authentication logic to gain broader system access than intended by the administrator. The lack of scope validation during critical administrative function calls represents a fundamental flaw in how identity and authorization are decoupled from action execution within the plugin's codebase.
To mitigate this vulnerability, organizations running Grav CMS must immediately upgrade the getgrav/grav-plugin-api module to version 1.0.18 or later, where these scope enforcement mechanisms have been corrected. Until an update is applied, administrators should restrict API key permissions as narrowly as possible and avoid using scoped keys for operations that interact with security blueprints if such functionality is required. Additionally, implementing strict input validation on all administrative endpoints and ensuring that authorization checks explicitly reference the request context rather than relying solely on global user state can help prevent similar logic flaws in other parts of the application. Regular auditing of API key scopes and monitoring for unusual access patterns to permission management interfaces are recommended defensive measures to detect potential exploitation attempts while patches are being deployed.