Capgo CVE-2026-56215

Exploitation requires (1) an authenticated low-privilege Capgo account on the target instance (PR:L), (2) the target instance to use corporate SSO with the provision-user endpoint enabled and configured to treat the email claim as an account-merge key, and (3) the victim SSO user to have not yet completed a first SSO login on Capgo (otherwise the canonical SSO identity is already bound). Limiting factors: the attacker must know the victim's corporate SSO email in advance, the window closes once the victim has been legitimately provisioned, and Capgo deployments that do not use SSO are not exploitable for this issue.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L) and 8.7 base score are well-aligned with the described threat: network-reachable provisioning endpoint, low attacker privileges (any registered Capgo account), no user interaction, and high confidentiality and integrity impact on the hijacked tenant. Real-world risk is concentrated in organizations that have onboarded Capgo with corporate SSO but have not yet had every user perform a first SSO login - the attacker must pre-position before the legitimate provisioning occurs, which makes the bug opportunistic and targeted rather than mass-exploitable. There is no EPSS score, no KEV listing, and no POC referenced in the supplied advisories, so urgency should be driven by exposure (do you use Capgo with SSO?) rather than by external exploitation signals; the SSRF-style trust-boundary error is, however, simple enough to weaponize once understood, so the absence of a public POC should not be read as low likelihood for SSO-enabled tenants.

An attacker registers an ordinary Capgo account, then updates their public.users.email to the corporate SSO address of a targeted executive (e.g., cfo@victimcorp.com). When the executive later signs in via their corporate IdP for the first time, the provision-user endpoint locates the attacker's account by email and merges the SSO identity into it, granting the attacker authenticated access to the victim's workspace, app credentials, and update channels. No public exploit identified at time of analysis, but the attack only requires HTTP access and one low-privilege account.