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

EUVD-2026-31913 has a CVSS 3.1 base score of 8.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N. EPSS exploitation probability: 0.0%.

Which versions of Chatwoot are affected by EUVD-2026-31913?

Chatwoot versions 2.2.0-4.11.1 contain a SQL injection vulnerability (CVSS 8.5) that allows any authenticated user to access sensitive customer data across the entire database without authorization.. A patch is available.

How to fix or mitigate EUVD-2026-31913?

Within 24 hours: Inventory all Chatwoot deployments and identify affected versions (2.2.0-4.11.1). Within 7 days: Upgrade all instances to Chatwoot 4.11.2 or later. Within 30 days: Audit logs for indicators of exploitation and validate patch deployment across all systems.

Chatwoot EUVD-2026-31913

| CVE-2026-44706 HIGH

SQL Injection (CWE-89)

2026-05-26 GitHub_M

SQLi Chatwoot

8.5

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.5 HIGH

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

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

CVSS VectorVendor: GitHub_M

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 08, 2026 - 09:34 vuln.today

Patch available

May 26, 2026 - 19:02 EUVD

DescriptionCVE.org

Chatwoot is a customer engagement suite. From 2.2.0 to before 4.11.2, a SQL injection vulnerability exists in the conversation and contact filter APIs. When filtering by a custom attribute of type date or number using the is_greater_than or is_less_than operators, user-supplied values in the values field of the filter payload are interpolated directly into the SQL query without parameterization. Any authenticated user with access to an account can exploit this to execute arbitrary SQL via time-based blind injection. This affects /api/v1/accounts/{account_id}/conversations/filter, /api/v1/accounts/{account_id}/contacts/filter, and /api/v1/accounts/{account_id}/custom_attribute_definitions. This vulnerability is fixed in 4.11.2.

AnalysisAI

SQL injection in Chatwoot versions 2.2.0 through 4.11.1 allows any authenticated account user to execute arbitrary SQL via time-based blind injection by abusing unparameterized values in custom-attribute filter operators on the conversation, contact, and custom attribute definition APIs. No public exploit identified at time of analysis, and EPSS exploitation probability is very low (0.03%, 8th percentile), but CVSS 8.5 with scope-changed confidentiality impact reflects the ability to read data beyond the attacker's account boundary. The vulnerability is fixed in Chatwoot 4.11.2.

Technical ContextAI

Chatwoot is an open-source customer engagement and support platform written primarily in Ruby on Rails, where dynamic filter APIs translate user-supplied filter payloads into ActiveRecord/SQL queries. The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command): when a filter targets a custom attribute of type date or number and uses the is_greater_than or is_less_than operators, the values field is interpolated directly into the generated SQL string instead of being passed as a bound parameter. Because numeric and date comparison operators are not wrapped in the parameterization path that string operators use, the user-controlled value becomes part of the query text, enabling injection. Per the CPE (cpe:2.3:a:chatwoot:chatwoot) and EUVD data, all Chatwoot deployments at versions 2.2.0 through 4.11.1 are affected.

RemediationAI

Upgrade Chatwoot to 4.11.2 or later, which is the vendor-released patch that adds parameterization for the is_greater_than and is_less_than operators on date and number custom attributes; see the GitHub Security Advisory at https://github.com/chatwoot/chatwoot/security/advisories/GHSA-9pgm-75gg-6948 for the authoritative fix reference. If immediate upgrade is not possible, compensating controls include restricting access to /api/v1/accounts/{account_id}/conversations/filter, /api/v1/accounts/{account_id}/contacts/filter, and /api/v1/accounts/{account_id}/custom_attribute_definitions at a reverse proxy or WAF layer with rules that reject filter payloads containing SQL meta-characters in the values field for numeric/date attributes, and tightening account membership and role assignments so that only fully trusted users hold accounts that can invoke filter APIs - both controls trade off legitimate filtering and onboarding flexibility against risk reduction. Database-side hardening such as enforcing least privilege for the Chatwoot DB role (revoking unnecessary read access to non-Chatwoot schemas) limits blast radius if injection is achieved but does not block the vulnerability itself.