EUVD-2026-35194Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (VulnCheck) · only source for this CVE.
CVSS VectorVendor: VulnCheck
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
5DescriptionCVE.org
WACRM prior to commit 73041bf contain an authorization bypass vulnerability in the automation engine that allows authenticated attackers to access and modify contacts belonging to other tenants by supplying an arbitrary caller-controlled contact_id in the POST request body without tenant ownership verification. Attackers can exploit the service-role client that bypasses row-level security to modify victim contact fields including name, email, and company across tenant boundaries using only a known contact UUID.
AnalysisAI
Cross-tenant contact tampering in WACRM (arnasdon/wacrm) before commit 73041bf allows any authenticated tenant user to read and modify contacts owned by other tenants by passing an arbitrary contact_id to the automation engine endpoint, which invokes a Supabase service-role client that bypasses row-level security. The flaw is an IDOR/authorization bypass (CWE-639) reported by VulnCheck; no public exploit is identified at time of analysis and the issue is not listed in CISA KEV.
Technical ContextAI
WACRM is a multi-tenant WhatsApp/CRM application built on Supabase, which enforces tenant separation via row-level security (RLS) tied to the account_id. The vulnerable code path is the automation engine's runAutomationsForTrigger function (src/lib/automations/engine.ts), which used the supabaseAdmin (service-role) client - a privileged client that intentionally bypasses RLS for legitimate background tasks. Because the engine accepted a caller-supplied contact_id without first verifying that the contact's account_id matched the authenticated tenant, the service-role client became a confused deputy: every subsequent read/update on the contacts table executed with admin privileges against any UUID the attacker chose. This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key), and the regression tests added in PR #194 codify the fix by asserting an ownership lookup runs first and that the update_contact_field step is scoped with an eq filter on the automation's own account.
RemediationAI
Upstream fix available (commit 73041bfa6420f5e1ecbfa1dd4fa847d8529320f5 via pull request https://github.com/ArnasDon/wacrm/pull/194); a released patched version is not independently confirmed, so self-hosters should pull main at or after that commit and redeploy. The fix adds an ownership guard that uses the service-role client only to look up the contact's account_id and aborts the automation run when it does not match the caller's tenant, and additionally scopes update_contact_field writes with an explicit eq filter on the automation's own account. As a compensating control until the patch is applied, restrict access to the automation trigger endpoint (e.g., disable the automations feature or block POSTs that carry a contact_id in the body at a reverse proxy) - this disables legitimate automation workflows but eliminates the vulnerable code path; alternatively, replace the supabaseAdmin call in runAutomationsForTrigger with the standard RLS-bound user client, accepting that any other legitimate cross-tenant work in that function will also break until properly re-authorized. Rotate any contact UUIDs known to have been exposed in shared resources and audit automation_logs for unexpected contact updates. Reference: https://github.com/ArnasDon/wacrm/pull/194.
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today