Capgo CVE-2026-56308

Exploitation requires the attacker to already possess a valid authenticated Capgo session - a live session cookie or an authenticated browser (PR:L) - because the vulnerable email-change endpoint accepts the change based solely on that session, with no current-password prompt and no confirmation sent to the existing email. The specific weakness is the missing step-up verification on the email-change endpoint itself. Limiting factors: the attacker cannot exploit this pre-authentication (a session foothold via cookie theft, XSS, session fixation, or physical device access is a prerequisite), and the CVSS UI:A metric indicates some active interaction is involved rather than a fully silent background exploit; it does not affect unauthenticated users or accounts whose sessions have not been compromised.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:N) scores 8.4 (High) and is internally consistent with the description: network reachable, low complexity, but requiring existing low-privilege authenticated access (PR:L) and some active interaction (UI:A). This is not a pre-auth mass-exploitation bug - the attacker must first obtain a valid session (via cookie theft, XSS, shared/borrowed device, or session fixation), so it functions as a privilege/persistence escalation that turns a transient session compromise into permanent account takeover, which is why confidentiality and integrity are rated High while availability is None. No EPSS score, KEV entry, or POC is provided; absence of KEV and the PR:L prerequisite argue against widespread opportunistic exploitation, so real-world priority is moderate - high impact per incident but bounded by the need for a pre-existing foothold. Signals are mutually consistent (no CVSS-vs-description conflict); the main missing data are EPSS probability and any confirmation of in-the-wild use.

An attacker obtains a victim's Capgo session - for example a cookie exfiltrated via XSS or captured on a shared/unlocked device - and, without knowing the password, submits an email-change request that the endpoint accepts with no re-authentication or old-email confirmation. The attacker then triggers a password reset to the newly controlled address and resets MFA, locking out the legitimate owner and taking full control of the account. No public POC is identified, but the attack requires only standard authenticated HTTP requests and low complexity.