Chatwoot EUVD-2026-55654

Exploitation requires an active Chatwoot session authenticated as an account-level administrator (CVSS PR:H confirmed). The target deployment must be multi-tenant - a single-tenant self-hosted instance with only one account has no other account_id values to target, making exploitation effectively inert. The attacker must know or be able to enumerate the numeric ID of a target account. No special non-default configuration is required beyond the standard API being accessible; the flaw exists in the default permitted-parameters implementation of four controllers. Exploitation is limited by: the administrator authentication barrier, multi-tenant deployment requirement, and the need to know a valid target account ID.

The provided CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L) correctly captures the key risk trade-off: the high-privileges requirement (PR:H - account administrator) substantially limits exploitability to insider threats or compromised admin accounts, while the confidentiality and integrity impacts are high once that bar is cleared. No EPSS score was provided in the intelligence data, so exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV, and no POC exploit code was identified beyond the source diff in the advisory. Real-world risk is highest in multi-tenant SaaS or managed Chatwoot deployments; self-hosted single-tenant installations have no other accounts to target, reducing the attack surface to near zero. The S:U (unchanged scope) rating is debatable: because the impact lands on resources belonging to a different tenant account, a case for S:C could be made. This should be verified against the vendor's own CVSS rationale. Overall, this is a medium-priority issue driven by insider or credential-compromise scenarios rather than opportunistic remote attack.

A malicious or compromised account administrator authenticates to Chatwoot and issues a PATCH request to update an automation rule within their account, injecting account_id: <victim_tenant_id> into the request body. Chatwoot's controller accepts the parameter and persists the resource under the target tenant's account ID, effectively exfiltrating the rule configuration - including any embedded credentials or sensitive logic - into the target account. No POC exploit code is publicly linked, but the technique requires only a standard authenticated API call with a modified parameter.