Capgo CVE-2026-56212

Exploitation requires an authenticated Capgo user account with explicit permission to manage team or organization security settings (corresponding to PR:H in the CVSS vector). The flaw is only meaningful when the initiating user does not have 2FA enabled on their own account - an attacker who already has 2FA would trigger the same policy change without exploiting the logic flaw. The vulnerability is present in all Capgo deployments (cloud or self-hosted) running versions before 12.128.2. Exploitation is strictly bounded by the high-privilege prerequisite: unauthenticated external actors and low-privilege team members without security settings access cannot trigger this flaw. The impact on victims (team lockout, inconsistent policy) is operational and organizational rather than a direct system compromise.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N) accurately captures the real-world risk profile: network-reachable but requiring high privileges (PR:H), with limited confidentiality and integrity impact (VC:L/VI:L) and no availability impact to the system itself. The practical blast radius is organizational rather than technical - team members can be locked out of their accounts when forced into 2FA enrollment without notice, and the policy inconsistency undermines the intended security posture. No EPSS data is provided, but the absence of KEV listing and public PoC, combined with the PR:H constraint, makes opportunistic mass exploitation implausible. The realistic threat actor is an insider (rogue admin, compromised privileged account) rather than an external attacker. There is no conflicting signal between the CVSS vector and the description - PR:H is consistent with the 'permission to manage security settings' prerequisite stated in the advisory.

An authenticated Capgo team member holding the 'manage security settings' role - but without 2FA configured on their own account - accesses the organization security panel and activates the mandatory 2FA policy. All other team members are immediately subject to the 2FA enrollment requirement and may be locked out of workflows, while the initiating account continues to operate without 2FA, violating the policy it created. No public proof-of-concept exists, but the attack requires only standard UI interaction by the privileged user.