CVE-2026-44707: Chatwoot Auth Bypass Vulnerability

CVE-2026-44707 Overview

CVE-2026-44707 is a Pre-Account Takeover (Pre-ATO) vulnerability in Chatwoot, an open-source customer engagement suite. The flaw affects versions from 2.14.0 up to but not including 4.13.0. Chatwoot did not enforce email confirmation before an account became usable. An attacker could pre-register an email they did not own and set a password. When the legitimate owner later authenticated through Google OAuth or another OmniAuth provider, the OAuth flow silently confirmed the existing account without invalidating the attacker's pre-set credentials. The attacker retained password access to the victim's dashboard, including PII, API keys, and conversation data. The issue is fixed in version 4.13.0.

Critical Impact
Attackers gain persistent access to victim accounts and any sensitive data entered after the legitimate owner signs in through OAuth, including PII and API keys.

Affected Products

Chatwoot versions 2.14.0 through 4.12.x
Self-hosted Chatwoot deployments using OmniAuth providers
Chatwoot instances with Google OAuth sign-in enabled

Discovery Timeline

2026-05-26 - CVE-2026-44707 published to NVD
2026-05-26 - Last updated in NVD database

Technical Details for CVE-2026-44707

Vulnerability Analysis

The vulnerability is an Improper Validation of Specified Index, Position, or Offset issue in authentication state [CWE-283]. Chatwoot allowed account creation through standard registration without enforcing email ownership verification before account use. When the same email later authenticated via an OmniAuth provider, the sign_in_user flow in omniauth_callbacks_controller.rb called skip_confirmation! on the existing user record. This confirmed the account but preserved the attacker's previously set password hash.

Root Cause

The root cause is a missing credential rotation step in the OAuth callback path. The application treated OAuth authentication as proof of email ownership but did not invalidate prior passwords on unconfirmed accounts. The pre-existing password remained valid after confirmation, allowing parallel authentication paths to the same account.

Attack Vector

An attacker registers a target email address on Chatwoot and sets a password under their control. The account remains unconfirmed but usable. The victim later signs in using Google OAuth, which silently confirms the existing record. The attacker continues to authenticate using the password they originally set and accesses any data the victim adds to the dashboard.

ruby

   private
 
   def sign_in_user
+    # Capture before skip_confirmation! sets confirmed_at, which would
+    # make oauth_user_needs_password_reset? return false and skip the
+    # password reset for persisted unconfirmed users.
+    needs_password_reset = oauth_user_needs_password_reset?
     @resource.skip_confirmation! if confirmable_enabled?
+    set_random_password_if_oauth_user if needs_password_reset
 
     # once the resource is found and verified
     # we can just send them to the login page again with the SSO params

Source: GitHub Commit 211fb110

Detection Methods for CVE-2026-44707

Indicators of Compromise

Accounts where registration occurred via password signup followed by a later OmniAuth confirmation event for the same email
Successful password-based logins to accounts that have also authenticated via Google OAuth within the same session window
Unexpected API key generation or PII export activity shortly after a user's first OAuth login
Login activity from IP addresses or user agents that differ between password and OAuth sessions for the same account

Detection Strategies

Audit the Chatwoot users table for accounts created before 4.13.0 where confirmed_at was set via OAuth callback while a non-null encrypted_password predates confirmation
Correlate Devise authentication logs to flag accounts with both password and OAuth sign-in records prior to upgrade
Review access_tokens and personal API keys created shortly after first OAuth authentication for legacy accounts

Monitoring Recommendations

Forward Chatwoot application and authentication logs to a centralized logging platform for retrospective analysis
Alert on session creation from geographically distant IP addresses for the same account within short time windows
Monitor changes to user email, password, and integration settings on accounts that existed before the upgrade

How to Mitigate CVE-2026-44707

Immediate Actions Required

Upgrade Chatwoot to version 4.13.0 or later without delay
Force a password reset for all accounts created before the upgrade that used both password and OAuth authentication paths
Rotate API keys and access tokens for any accounts identified as potentially compromised
Notify affected users to review account activity and re-issue any shared credentials stored in the dashboard

Patch Information

The fix is included in Chatwoot 4.13.0. The patch rotates the password on unconfirmed accounts during the OAuth callback by capturing oauth_user_needs_password_reset? before skip_confirmation! runs, then invoking set_random_password_if_oauth_user. See the GitHub Security Advisory GHSA-8qxm-4p4p-cfhm and the upstream pull request #13878 for full remediation details.

Workarounds

Disable OmniAuth providers until the upgrade to 4.13.0 is complete
Require manual email confirmation before allowing password-based sign-in on self-hosted deployments
Audit and purge unconfirmed user records older than a defined threshold to reduce the pre-registration attack surface

bash

# Upgrade Chatwoot to the patched release
git fetch --tags
git checkout v4.13.0
bundle install
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake assets:precompile
sudo systemctl restart chatwoot.target