EUVD-2026-83178Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege viewer
-
DeliveryCall flow/automation write API route
-
ExploitMembership check passes, role check absent
-
ExecutionService-role client bypasses RLS write
-
ImpactDelete/alter flows and fire outbound WhatsApp sends
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization verification
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated account with the low-privilege 'viewer' (membership-only) role on a WACRM instance version 0.7.0 or earlier; the attacker then invokes the flow and automation write routes (src/app/api/flows/[id]/route.ts, flows/[id]/activate/route.ts, flows/route.ts, automations/route.ts, automations/engine/route.ts). Exploitation works against default configurations because the missing agent-role enforcement is in the application code itself, and the service-role database client bypasses the row-level-security policies that would otherwise block viewer writes. LIMITING factors: an attacker must already hold a valid viewer-level account on the target tenant (PR:L), and instances that only ever grant agent/admin roles have no lower-privileged principal to abuse; no user interaction is required. |
| Impact | This is a genuine broken-authorization (CWE-285) flaw, not merely a high-CVSS paper cut. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, I:H/A:H, 8.1) is internally consistent with the description and the PR#351 diff: a low-privilege authenticated 'viewer' can reach flow/automation write routes over the network with no user interaction. The root cause is confirmed by the vendor's own patch - every affected route (flows GET/PUT/DELETE, flows/[id]/activate POST, automations GET-that-creates/engine, automations/[id] PATCH/DELETE/duplicate) checked account membership only, then wrote via a service-role Supabase client that bypasses row-level security, so the agent-gated RLS policies (flows_insert/update/delete, automations_insert/update/delete) never applied. Signals that TEMPER urgency: no EPSS score, no CISA KEV entry, and no public exploit code are provided; the affected product is a niche self-hostable template rather than widely-deployed enterprise software; and exploitation still requires a valid low-privilege account on a WACRM instance (PR:L, not PR:N). The 'Authentication Bypass' tag is misleading - this is authorization/access-control, not authentication bypass. Net: patch promptly on any WACRM <=0.7.0 that has multiple account roles, but this is a targeted-instance authorization bug, not a wormable internet-wide threat. |
| Exploit ScenarioDerived | An attacker holding a legitimate read-only 'viewer' account on a self-hosted WACRM instance sends authenticated API requests directly to the flow and automation write endpoints (e.g. DELETE /api/flows/[id], POST /api/flows/[id]/activate, POST /api/automations/engine). Because the routes only verify membership and then write with the RLS-bypassing service-role client, the viewer destructively deletes or alters production flows and triggers outbound WhatsApp sends they should never be able to perform. No public exploit code is identified at time of analysis, but the fix diff plainly discloses the exact vulnerable routes and missing role check. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 18, 2026
Missing role enforcement in WACRM 0.7.0 and earlier allows any authenticated user holding the low-privilege 'viewer' role to perform write operations that should be restricted to 'agent' or higher - creating, editing, activating, and deleting WhatsApp flows, creating and modifying automations, and triggering outbound WhatsApp sends through the automation engine. The affected route handlers (src/app/api/flows/[id]/route.ts, src/app/api/flows/[id]/activate/route.ts, src/app/api/flows/route.ts, src/app/api/automations/route.ts, and src/app/api/automations/engine/route.ts) check only account membership before writing through a service-role database client that bypasses row-level security, so the server-side RLS policies that would otherwise require the agent role never apply. There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV); exploitation requires only a valid viewer-level account on the target instance, making this a straightforward post-authentication privilege escalation with high integrity impact but no direct confidentiality loss.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed. The authoritative fix is commit 03e851bea56dcf6bb21ff1b80ba531372bf3269f (pull request 351), which introduces requireRole('agent') into each affected write handler so that route-level enforcement matches the RLS policies; apply that commit or deploy a build that contains it, since no numbered patched release is confirmed in the available data. Consult the GitHub security advisory https://github.com/ArnasDon/wacrm/security/advisories/GHSA-34q7-fv77-625j for the vendor's guidance and track releases for a tagged version containing the commit. If patching must be deferred, the most effective compensating control is to eliminate the exploitable principal: audit account memberships and remove or temporarily suspend every viewer-role user, accepting the trade-off that legitimate read-only staff lose access. As a second layer, place a reverse-proxy or middleware rule that rejects authenticated viewer sessions from the /api/flows and /api/automations endpoints (including the /activate, /engine, and /[id] subpaths), noting that this is brittle because it duplicates authorization logic that the upstream patch places in code, and it must be reviewed whenever routes change. Additionally, review existing flows and automations for unauthorized creation, activation, or deletion, inspect application and outbound WhatsApp logs for sends initiated by viewer accounts, and rotate any database service-role credentials if the deployment's logging cannot establish whether the bypass was exercised - recognizing that credential rotation will not remediate the underlying authorization flaw and requires a coordinated restart of the WACRM service.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
WACRM is a self-hostable, Next.js-based CRM template whose API is implemented as App Router route handlers under src/app/api. Authorization is layered: server routes are expected to enforce a role via a requireRole('agent') helper, while the database layer enforces the same constraint through Supabase-style row-level-security policies (flows_insert, flows_update, flows_delete, automations_insert, automations_update, automations_delete) that are conditioned on the agent role. The vulnerable code called only getCurrentAccount(), which verifies that the caller belongs to an account (membership check) but does not verify the caller's role, and then performed the write with a service-role database client that intentionally bypasses RLS. The result is a confused-deputy / broken-authorization condition in the CWE-285 class: the two controls that were each supposed to gate writes (route-level role check and RLS policy) were both effectively absent for viewer principals, because the route omitted the check and the service-role client neutralized the policy. The upstream fix adds explicit requireRole('agent') calls to ten write handlers across the flows and automations APIs (and additionally to automation duplication), restoring parity between the route-level and policy-level authorization models. Per the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, the flaw is network-reachable, low complexity, requires low privileges (authenticated viewer), needs no user interaction, and yields high integrity and availability impact with no confidentiality impact.
Know when Wacrm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Authenticated viewer (PR:L) reaches network write routes with no interaction; unauthorized flow/automation tampering gives I:H and destructive flow deletion gives A:H, with no confidentiality gain beyond what a viewer already reads (C:N).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
DescriptionCVE.org
WACRM is a self-hostable CRM template for WhatsApp. In version 0.7.0 and earlier, WACRM flow and automation write routes authenticate account viewers but do not enforce the agent role before using a service-role database client that bypasses row-level security. In src/app/api/flows/[id]/route.ts, src/app/api/flows/[id]/activate/route.ts, and src/app/api/flows/route.ts, a viewer can create, edit, activate, or delete flows because membership-only checks are followed by service-role writes. In src/app/api/automations/route.ts and src/app/api/automations/engine/route.ts, a viewer can create active automations and trigger outbound WhatsApp actions without the role required by the underlying write policies. This can permit unauthorized workflow changes, destructive flow deletion, and outbound actions from a role intended to be read-only. This vulnerability is fixed with commit 03e851bea56dcf6bb21ff1b80ba531372bf3269f.
Technical POC Analysis
CWE-285 (Improper Authorization), with CWE-269 noted in the advisory.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
WACRM 0.7.0 and earlier allows any user holding a basic 'viewer' account to create, edit, activate, and delete WhatsApp flows, modify automations, and trigger outbound WhatsApp messages that should be reserved for higher-privileged agents. Because the affected API routes verify only account membership and write through a service-role database client that bypasses row-level security, routine low-trust accounts can quietly reshape customer-facing messaging without any approval. Leadership should care because this is a privilege-boundary failure touching customer communications: unauthorized outbound sends, altered automations, and deletion of live flows create consent, brand, and regulatory exposure, and no vendor patch is available yet.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce role checks on the affected flow and automation write routes via application middleware or a reverse proxy/API gateway rule that rejects viewer-role sessions; replace the service-role database client in those route handlers with a user-scoped client so row-level security policies apply; strictly limit and audit viewer-role account assignments; restrict network exposure of WACRM instances to trusted networks or VPN; and monitor/alert on flow mutations and outbound WhatsApp send volume for anomalous activity.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Privilege escalation and cross-tenant data disclosure in WACRM 0.7.0 and earlier allow any authenticated user - a read-o
Server-side request forgery in WACRM 0.7.0 and earlier allows any authenticated user holding automation privileges to co
Cross-tenant contact tampering in WACRM (arnasdon/wacrm) before commit 73041bf allows any authenticated tenant user to r
Exploit-DB