CVE-2026-72823 in Grav
Summary
by MITRE • 08/14/2026
The Grav API plugin (getgrav/grav-plugin-api) before 1.0.13 contains an API-key scope cap bypass in DemoController. Its private requireSuper() method checks isSuperAdmin() and returns early before invoking requirePermission(), so the api_key_scopes cap (enforced only in requirePermission()) is skipped. As a result, any scoped API key minted on a super account can bypass its scope restrictions when calling the baseline() and reset() operations (e.g. POST /api/v1/demo/reset), allowing it to capture the demo baseline or force a demo reset. Impact is bounded to demo-engine control and is conditional on demo mode being configured with writable resources.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability in the Grav API plugin affects versions prior to 1.0.13 and specifically targets the DemoController component where a critical access control bypass exists due to flawed permission validation logic. This issue stems from the improper implementation of the requireSuper() method which performs an early return when checking super admin privileges without properly enforcing the api_key_scopes cap restriction that should be enforced through the requirePermission() method. The flaw creates a scenario where API keys generated for super administrator accounts can bypass their intended scope limitations when executing specific demo operations, fundamentally undermining the plugin's security model.
The technical implementation of this vulnerability occurs at the method level within the DemoController class where the requireSuper() method executes isSuperAdmin() checks and returns immediately before calling requirePermission(). This premature return means that even though an API key may have been issued with specific scope limitations, those restrictions are never enforced because the permission verification step that would apply the api_key_scopes cap is skipped entirely. The vulnerability specifically impacts the baseline() and reset() operations accessible via POST requests to /api/v1/demo/reset endpoints, allowing malicious actors to exploit this bypass for unauthorized actions.
The operational impact of this vulnerability is constrained by several conditional factors but remains significant within its attack surface. The exploitation requires that the demo mode be properly configured with writable resources, limiting the scope of potential compromise to systems where demonstration environments are actively enabled and accessible. However, when these conditions are met, an attacker with access to a scoped API key associated with a super administrator account can perform unauthorized baseline captures or force demo resets, potentially exposing sensitive demonstration data or disrupting system operations within the demo environment.
This vulnerability aligns with CWE-284 Access Control Bypass and represents a classic example of improper privilege management where early return logic bypasses intended security checks. The flaw demonstrates poor adherence to the principle of least privilege as defined in cybersecurity best practices, allowing elevated privileges to be used beyond their intended scope. From an ATT&CK perspective, this vulnerability maps to privilege escalation techniques through API manipulation and could potentially lead to information disclosure or denial of service within demonstration environments.
Mitigation strategies should focus on implementing proper permission validation sequences where all access control checks are enforced regardless of early return conditions. The fix requires ensuring that requirePermission() is always called after super admin checks, maintaining the intended scope enforcement for API keys. Additionally, organizations should verify that demo mode configurations do not expose writable resources to untrusted parties and consider implementing additional monitoring for unauthorized API calls to these specific endpoints. Regular security audits of plugin access control implementations should be conducted to identify similar early return patterns that could lead to privilege escalation vulnerabilities.