Chatwoot EUVD-2026-31916

Exploitation requires that the Chatwoot instance has an OmniAuth provider (specifically Google OAuth2 or any other configured OmniAuth integration) enabled and reachable for user registration and login. The attacker must pre-register the victim's email address before the victim's first OAuth-based sign-in - once the victim has authenticated via OAuth on a clean (non-pre-registered) account, the attack window for that user is closed. The victim must interact (UI:R) by choosing OAuth login rather than password-based login; a victim who exclusively uses password authentication is not exposed to this specific path. The attack does not require the attacker to hold any prior authentication (PR:N) or system privileges. Exploitation is not automatable per SSVC ('Automatable: no'), as it depends on the attacker correctly predicting which email addresses will later be used with OAuth. Deployments with OAuth disabled, or where email confirmation is enforced at the infrastructure level before account activation, are not exploitable via this path.

CVSS 6.8 (Medium) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N reflects a network-accessible attack requiring no attacker privileges but imposing high complexity (attacker must know and claim the victim's email before the victim's first registration) and user interaction (victim must choose OAuth login). The C:H and I:H scores are consistent with SSVC's 'Technical Impact: total' - a successful exploitation grants the attacker the same workspace access as the victim. However, AC:H and UI:R are genuine limiting factors: the attack window is narrow (before victim's first OAuth sign-in) and requires prior knowledge of the target email. EPSS of 0.04% at the 12th percentile and SSVC 'Exploitation: none' together indicate no observed exploitation activity, and CISA KEV listing is absent. Despite low exploitation probability, the attack is realistic in targeted scenarios (corporate email addresses discoverable via LinkedIn or data breaches), making this a meaningful risk for public-facing Chatwoot instances with OAuth enabled, particularly in B2B support environments handling sensitive customer data. No conflicting signals between data sources were identified.

An attacker discovers a target's corporate email address (e.g., from a LinkedIn profile or leaked contact list), navigates to a public-facing Chatwoot instance's registration page, and pre-registers that email with a password they control before the legitimate user ever creates an account. When the legitimate user later clicks 'Sign in with Google,' the OmniAuth callback silently confirms the pre-existing unconfirmed account without resetting the password, and the attacker subsequently logs in with their original credentials to access the victim's customer support conversations, stored PII, and API keys. No public exploit code has been identified at time of analysis; the attack requires only knowledge of the target's email address and access to the Chatwoot registration endpoint.