CVE-2026-72822 in Grav
Summary
by MITRE • 08/14/2026
The getgrav/grav-plugin-api Composer package before 1.0.13 (affected <= 1.0.12) fails to enforce API key scope caps on the disable2fa endpoint. Unlike the sibling generate2fa endpoint, disable2fa authorizes the admin (non-self) path solely via ACL reads (isSuperAdmin/hasPermission) and never invokes requirePermission(), so the api_key_scopes cap is never applied. As a result, a holder of a narrow-scope API key on a super account, or a non-super account whose ACL includes api.users.write, can force-disable two-factor authentication on any non-super target account via POST /api/v1/users/{user}/2fa/disable without providing a TOTP code, facilitating account takeover.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/14/2026
The vulnerability in the getgrav/grav-plugin-api Composer package affects versions prior to 1.0.13 and represents a critical authorization flaw that undermines the security of two-factor authentication mechanisms within the Grav CMS platform. This issue manifests specifically in the disable2fa endpoint where the system fails to properly enforce API key scope limitations, creating a pathway for unauthorized account takeovers. The flaw stems from an inconsistent implementation pattern between two similar endpoints within the same plugin, where the generate2fa endpoint correctly applies scope validation while disable2fa does not.
The technical root cause of this vulnerability lies in the improper authorization logic within the disable2fa endpoint implementation. Unlike the generate2fa endpoint which properly calls requirePermission() to validate API key scopes, the disable2fa endpoint relies exclusively on ACL reads through isSuperAdmin() and hasPermission() checks without invoking the critical requirePermission() function that enforces api_key_scopes caps. This design inconsistency creates a security gap where attackers can bypass scope restrictions that should limit what actions a given API key can perform based on its assigned permissions. The vulnerability operates under CWE-284 access control weaknesses, specifically manifesting as insufficient authorization checks within the application's permission model.
The operational impact of this vulnerability is severe and directly enables account takeover scenarios across multiple user levels. An attacker with a narrow-scope API key possessing super user privileges can disable two-factor authentication on any non-super user account without requiring the target user's TOTP code, effectively removing their security protection. Additionally, users with non-super accounts that have api.users.write ACL permissions can also exploit this vulnerability to disable 2FA on any target account, regardless of user level. This creates a privilege escalation pathway where lower-privileged users can compromise higher-privileged accounts through the manipulation of authentication mechanisms rather than direct access to sensitive resources or data.
The implications extend beyond simple unauthorized access as this vulnerability directly violates core security principles established in the ATT&CK framework under privilege escalation techniques. Attackers can leverage this flaw to move laterally within the system, potentially gaining access to additional user accounts and administrative functions that rely on 2FA protection for account security. The vulnerability represents a critical weakness in the application's defense-in-depth strategy, where the integrity of authentication mechanisms is compromised by improper authorization enforcement. Organizations using affected versions of this plugin face significant risk of unauthorized account compromise, particularly in environments where API keys are used to grant programmatic access to CMS functionality.
Mitigation strategies should focus on immediate patching to version 1.0.13 or later where the authorization logic has been corrected to properly enforce api_key_scopes caps across all relevant endpoints. Security teams should also implement comprehensive monitoring for unauthorized 2FA disable activities and consider implementing additional controls such as requiring multi-factor authentication for administrative actions, logging all 2FA modification attempts, and regularly auditing API key permissions to ensure scope limitations are properly enforced. Organizations should also review their overall API security posture and implement proper authorization testing to prevent similar inconsistencies between related endpoints in their applications.