CVE-2026-72719 exposes a fundamental API design error in Chatwoot: the platform treats the target account as a client-supplied parameter rather than a server-enforced session constraint. The vulnerability affects four resource types — Portals, Automation Rules, Macros, and Twilio Channels — where an authenticated administrator can manipulate the account_id parameter to transfer resources across tenant boundaries. The core flaw is not simply missing authorization around a transfer operation — it is that the API design allowed the target tenant to be specified by the client at all.
When developers make account_id a writable parameter, they create a flexible interface that supports administrative workflows across accounts, but they simultaneously open every resource operation on that endpoint to cross-tenant manipulation. The authorization model becomes dependent on correctly scoping every operation, which is fragile compared to deriving the target account from the authenticated session context where it cannot be tampered with. This is the critical distinction: adding authorization checks fixes the symptom, but the underlying design pressure remains. The correct fix is to refuse the account_id parameter entirely and derive tenant context from the session — making it a forbidden parameter in multi-tenant contexts rather than a whitelisted one.
The CVSS 6.7 rating reflects the authentication requirement but significantly underweights the blast radius. Twilio Channels and Automation Rules are not passive data — they are control plane assets. A hostile tenant who transfers a Twilio Channel and reconfigures it creates persistent infrastructure access that does not revoke when the transfer is detected. Automation Rules can reference Macros, and a transferred rule may retain broken references to resources still owned by the source tenant, creating operational inconsistencies that are difficult to diagnose. For a customer engagement suite, losing control of these assets means potential service disruption, data leakage through modified flows, or credential exposure.
Audit your Chatwoot deployment for other endpoints that accept account_id as a writable parameter — this pattern likely exists beyond the four fixed in this CVE. The Rails conventions that enable this (nested resources, strong parameter whitelisting) generate similar patterns across dozens of endpoints. The question to ask of any Chatwoot API endpoint is simple: does it accept tenant context as input, or does it derive it from the session? The former is the vulnerability class; the latter is the fix.