What is the CVSS score of EUVD-2026-31916?

EUVD-2026-31916 has a CVSS 3.1 base score of 6.8 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for EUVD-2026-31916?

Yes, a patch is available for EUVD-2026-31916. Update the affected software to the latest version immediately.

Chatwoot EUVD-2026-31916

| CVE-2026-44707 MEDIUM

Unverified Ownership (CWE-283)

2026-05-26 GitHub_M

Information Disclosure Google Chatwoot

6.8

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

6.8 MEDIUM

AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Primary rating from Vendor (GitHub_M) · only source for this CVE.

CVSS VectorVendor: GitHub_M

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 11:41 vuln.today

Analysis Generated

Jun 08, 2026 - 11:41 vuln.today

Patch available

May 26, 2026 - 19:02 EUVD

DescriptionCVE.org

Chatwoot is a customer engagement suite. From 2.14.0 to before 4.13.0, a Pre-Account Takeover (Pre-ATO) vulnerability existed in Chatwoot's authentication flow. Because email confirmation was not enforced before an account became usable, an attacker could pre-register an email address they did not own and set a password. If the legitimate owner of that email later signed in to Chatwoot using Google OAuth (or another OmniAuth provider), the OAuth flow silently confirmed the existing account without invalidating the attacker's pre-set credentials. The attacker could then continue to log in with the password they had originally chosen and access any data the victim subsequently entered into the dashboard, including PII, API keys, and other sensitive information. This vulnerability is fixed in 4.13.0.

AnalysisAI

Pre-Account Takeover in Chatwoot's OmniAuth integration affects all releases from 2.14.0 through 4.12.x, allowing an attacker who pre-registers a victim's email address to retain persistent login access after the legitimate owner authenticates via Google OAuth. The OAuth callback controller failed to invalidate attacker-set password credentials when confirming a pre-existing unconfirmed account, leaving the attacker's session viable indefinitely. No public exploit identified at time of analysis and EPSS is 0.04% (12th percentile), consistent with SSVC's 'Exploitation: none' finding, though SSVC rates technical impact as 'total' given the attacker gains full workspace access including PII, API keys, and conversation history.

Technical ContextAI

The root cause is CWE-283 (Unverified Ownership): Chatwoot's Devise-based OmniAuth callback controller at app/controllers/devise_overrides/omniauth_callbacks_controller.rb called skip_confirmation! during an OAuth sign-in to mark an account as confirmed, but never checked whether a persisted, unconfirmed record with attacker-controlled credentials already existed for that email. Because skip_confirmation! sets confirmed_at in place, the account transitioned to confirmed status while retaining whatever password was previously set by the pre-registrant. The PR #13878 fix introduces two guard methods: oauth_user_needs_password_reset? (detects persisted-but-unconfirmed accounts) and set_random_password_if_oauth_user (overwrites the stored password digest with a cryptographically random value satisfying Devise secure_password requirements before confirmation proceeds), neutralizing any attacker-set credential. The affected CPE is cpe:2.3:a:chatwoot:chatwoot:*:*:*:*:*:*:*:*, encompassing the full version range from 2.14.0 onward until the fix.

RemediationAI

Upgrade to Chatwoot 4.13.0, the vendor-confirmed fixed release documented in security advisory GHSA-8qxm-4p4p-cfhm and implemented via commit 211fb1102dd208daee414cff1b8d71ea27ac5ebf (https://github.com/chatwoot/chatwoot/commit/211fb1102dd208daee414cff1b8d71ea27ac5ebf) and PR #13878 (https://github.com/chatwoot/chatwoot/pull/13878). If immediate upgrade is not possible, disabling Google OAuth and all OmniAuth providers in Chatwoot's installation settings removes the trigger condition entirely; note this forces all users to password-based login and will break any existing SSO or social-login workflows. As a targeted compensating control, administrators can audit for unconfirmed user accounts (accounts where confirmed_at is null) with email addresses matching known user or corporate domains, then force-confirm legitimate accounts or delete suspicious pre-registered ones - this closes the attack window for already-staged pre-ATO attempts. Neither workaround substitutes for patching, as the underlying confirmation logic flaw persists.