Chatwoot vulnerabilities

Chatwoot prior to version 4.9.0 allowed authenticated account administrators to transfer Portals, Automation Rules, Macros, and Twilio Channels to other accounts through the writable account_id parameter. This could break tenant isolation and cause cross-account data exposure, unauthorized configuration changes, or loss of access to transferred resources.

Chatwoot before version 4.16.0 contains an authentication bypass vulnerability in the direct uploads controller that allows unauthenticated attackers to create arbitrary ActiveStorage blobs in any tenant account. Attackers can exploit missing authentication checks to resolve any account and conversation, then obtain signed PUT URLs to write arbitrary data to the application's storage backend.

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.

SQL injection vulnerability in Chatwoot versions 2.2.0 through 4.11.2 in conversation and contact filter APIs. An authenticated attacker can inject arbitrary SQL via date or number filter parameters.

In chatwoot up to version 4.11.2, the Webhooks::Trigger function in lib/webhooks/trigger.rb does not validate the url argument, leading to server-side request forgery (SSRF). The attack is remotely exploitable and the exploit is publicly available.