Capgo CVE-2026-56332

Exploitation requires that the target application uses Capgo for user registration and email confirmation flows, and that the confirm-signup endpoint is reachable over the network - which is the expected deployment posture. The attacker must be able to supply or influence the confirmation_url parameter during the signup or confirmation request, and the victim must actively click the resulting confirmation link (UI:A per the CVSS 4.0 vector). No authentication is required by the attacker (PR:N). What limits exploitation is mandatory victim interaction: the attack fails if the user does not click the crafted link. Additionally, the attack is most effective when the attacker controls the initial signup request to inject the malicious URL, though pre-staged confirmation URLs may be distributable depending on implementation. No special server configuration, non-default feature flag, or privileged access is required to reach the vulnerable code path.

The CVSS 4.0 score of 5.1 (Medium) accurately reflects the constrained but real-world relevant threat profile: network-accessible (AV:N), low complexity (AC:L), no privileges required (PR:N), but user interaction is mandatory (UI:A). There is no direct confidentiality or availability impact on the vulnerable Capgo system itself (VC:N, VA:N); the integrity impact is limited to the redirect manipulation (VI:L). No EPSS score was provided in the input data, so exploitation probability cannot be quantified numerically. KEV status is absent and no public exploit code has been identified, meaning this is not a confirmed in-the-wild exploitation scenario. Despite the modest CVSS score, open redirect vulnerabilities in authentication and registration flows carry disproportionate real-world risk: they allow attackers to abuse the trust signals of a legitimate sending domain and a legitimate-looking URL path, which substantially increases phishing success rates compared to raw cold-phishing. The primary risk is to end users of applications built on Capgo, not to the Capgo infrastructure itself. Self-hosted deployments with slower patch cycles face the highest residual exposure.

An attacker submits a signup request to a Capgo-backed application with a crafted confirmation_url pointing to an attacker-controlled phishing page mimicking the legitimate app's login screen. The application sends the victim a legitimate-looking confirmation email from a trusted domain; when the victim clicks the link and completes confirmation, Capgo's server transparently redirects them to the phishing site. No special tooling or exploit code is required - a crafted HTTP request and a social-engineering-ready phishing page are sufficient.