EUVD-2026-51294Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
PR:L confirmed by automation privilege requirement; S:C reflects server crossing from application to internal network boundary; no availability impact identified.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
WACRM is a self-hostable CRM template for WhatsApp. In 0.7.0 and earlier, the automation send_webhook action in src/lib/automations/engine.ts and its validation in src/lib/automations/validate.ts allowed an authenticated user with automation privileges to submit an arbitrary webhook URL that the server fetched without the existing isDeliverableUrl SSRF guard in src/lib/webhooks/ssrf.ts, allowing requests to private, loopback, link-local, or cloud metadata addresses such as the cloud metadata endpoint at 169.254.169.254. This vulnerability is fixed with commit 23838a9959550e975d732ae08a44a3a2f0cc084b.
AnalysisAI
Server-side request forgery in WACRM 0.7.0 and earlier allows any authenticated user holding automation privileges to coerce the application server into fetching arbitrary internal URLs, including cloud instance metadata endpoints such as 169.254.169.254. The send_webhook automation action in src/lib/automations/engine.ts was missing a call to the existing isDeliverableUrl SSRF guard that already protected the webhook_endpoints delivery path, creating an inconsistent and exploitable gap. No public exploit code has been independently identified and the vulnerability is not listed in CISA KEV; however, the fix commit and GitHub security advisory are publicly available, substantially lowering the bar for any attacker who has read the diff.
Technical ContextAI
WACRM is a self-hostable CRM template (CPE: cpe:2.3:a:arnasdon:wacrm:*:*:*:*:*:*:*:*) built on a Node.js/TypeScript stack and designed to integrate with WhatsApp. Its automation engine allows users to define event-driven workflows; one action type, send_webhook, instructs the server to make an outbound HTTP request to a user-supplied URL. CWE-918 (Server-Side Request Forgery) describes exactly this root cause: user-controlled input reaching a server-side HTTP fetch without sufficient filtering of private address space. The codebase already contained an isDeliverableUrl guard in src/lib/webhooks/ssrf.ts that was applied to the primary webhook delivery path (lib/webhooks/deliver.ts), but that import was never added to the automation engine path. The fix (commit 23838a9959550e975d732ae08a44a3a2f0cc084b) imports isDeliverableUrl into engine.ts, calls it before the outbound fetch, and additionally sets redirect: 'manual' to prevent open-redirect chains from bypassing the guard, plus a 10-second AbortSignal timeout to limit impact from slow internal hosts.
RemediationAI
Apply the upstream fix by updating to a commit at or after 23838a9959550e975d732ae08a44a3a2f0cc084b from the WACRM repository (https://github.com/ArnasDon/wacrm). Because no tagged release version has been confirmed as patched at the time of analysis, self-hosters should verify their checkout is at or beyond this commit. The advisory is at https://github.com/ArnasDon/wacrm/security/advisories/GHSA-8jqh-598v-rfxc. If patching immediately is not possible, the most effective compensating control for cloud deployments is enabling IMDSv2 (token-required mode) on AWS EC2 instances, which blocks unauthenticated metadata retrieval even if SSRF is achieved - note this does not eliminate SSRF to other internal services. Network-level egress filtering can restrict the server's outbound HTTP to known external destinations only, blocking 169.254.0.0/16 and RFC-1918 ranges at the firewall or cloud security group level; the trade-off is operational overhead if legitimate webhooks require broad egress. Restricting the automation privilege to a minimal set of trusted users reduces the exploitable population while a patch is staged.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today