CVE-2026-100629 in capgo.app
Summary
by MITRE • 09/26/2026
Capgo (capgo.app backend) before 12.127.5 contains an authorization flaw in the PATCH /private/role_bindings/:binding_id endpoint. The handler verifies that the newly assigned role's priority rank does not exceed the caller's own rank, but — unlike the DELETE handler — it never checks the rank of the role currently bound to the target binding. An authenticated user holding the org_admin role (rank 90) can therefore change an org_super_admin binding (rank 95) to a lower-privileged role such as org_member (rank 75). Because the prevent_last_super_admin_binding_delete database trigger fires only BEFORE DELETE and not on UPDATE, an org_admin can demote every org_super_admin, leaving the organization with no super administrator. The issue is fixed in 12.127.5.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Capgo versions prior to 12.127.5 represents a critical authorization flaw within the backend API endpoint responsible for managing role bindings, specifically targeting the PATCH /private/role_bindings/:binding_id operation. This issue stems from an incomplete implementation of access control checks during state transitions involving administrative roles. While the system correctly validates that a user cannot assign themselves or others to a role with a higher priority rank than their own current standing, it fails to perform a symmetric check on the existing assignment being modified. In security architecture, this is often referred to as an asymmetric validation error where the input (the new role) is scrutinized but the context of the target resource (the current binding's privilege level) is ignored during update operations.
From a technical perspective, the flaw lies in the logic governing the PATCH handler compared to the DELETE handler for role bindings. The system employs a rank-based authorization model where roles are assigned numerical priorities, with org_super_admin holding a higher rank than org_admin. When an authenticated user possessing the org_admin role attempts to modify a binding currently associated with an org_super_admin, the application verifies that the target new role does not exceed the caller's rank of 90. However, it neglects to verify whether the modification would result in the removal or demotion of a higher-privileged entity beyond what is permitted by policy. This oversight allows an attacker with moderate privileges to manipulate high-level administrative assignments without triggering appropriate denial logic.
The operational impact of this vulnerability is severe and potentially catastrophic for organizational security posture. An authenticated org_admin can systematically demote every user holding the org_super_admin role down to a lower-privileged status such as org_member, which carries a rank of 75. This action effectively strips all super administrators of their elevated privileges without deleting them from the system entirely. The severity is compounded by database-level constraints; specifically, a trigger named prevent_last_super_admin_binding_delete exists but is configured to fire only on DELETE events rather than UPDATE events. Consequently, while direct deletion of the last super administrator binding would be blocked, demoting that user via an update operation bypasses this safeguard entirely.
This scenario leads to a state where the organization may end up with zero active super administrators if all such accounts are demoted simultaneously or sequentially by a malicious insider or compromised account. The loss of super administrative access can result in operational paralysis, inability to manage critical system configurations, and potential data integrity issues depending on how fallback mechanisms handle the absence of top-tier admins. Furthermore, this vulnerability facilitates privilege escalation in terms of impact rather than direct elevation; while an attacker does not gain higher privileges themselves, they exert control over who holds them, potentially locking out legitimate owners or preparing the ground for further exploitation by other actors seeking to take full control of the tenant environment.
In terms of industry standards and threat modeling, this vulnerability aligns with CWE-269 Improper Privilege Management due to insufficient checks on existing privileges during state changes. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as it requires valid authentication but abuses the permissions associated with those accounts to disrupt administrative controls. The specific behavior of bypassing safeguards through update operations rather than deletions highlights a gap in defense-in-depth strategies where security logic is fragmented across different handlers and database triggers without unified validation rules for all modification types.
To mitigate this vulnerability, organizations running Capgo versions prior to 12.127.5 must upgrade immediately to the patched version which corrects the authorization logic in the PATCH handler. The fix ensures that modifications to role bindings now verify both the caller's rank relative to the new target role and the existing privilege level of the binding being modified, preventing unauthorized demotions of high-ranking administrators. For environments where upgrading is not immediately feasible, temporary mitigations should include restricting access to the affected API endpoint to a minimal set of trusted service accounts or implementing network-level controls such as IP whitelisting for administrative interfaces. Additionally, auditing logs for unusual patterns of role binding updates can help detect potential exploitation attempts in real-time while longer-term architectural reviews are conducted to ensure that all CRUD operations on sensitive resources undergo consistent and comprehensive privilege validation checks.