erxes CRM SSRF Audit - 2026-02-18

Session Notes

Completed SSRF inconsistency audit on erxes CRM (~3.5k stars, Node.js/TypeScript). Found a clean, straightforward SSRF vulnerability in the outgoing webhook automation feature.

Key Finding

erxes CRM contains a valid, HIGH severity SSRF vulnerability in the automation system's outgoing webhook feature. CVSS Score: 7.3 (HIGH)

Vulnerability Details

• Component: Automation outgoing webhooks (/backend/services/automations/src/executions/actions/webhook/outgoing/)
• HTTP Method: Native fetch() API
• URL Validation: ZERO - completely absent
• User Access: ANY authenticated user can create webhooks
• Configuration: User-provided URLs directly passed to fetch()
• Response Exposure: Logged in execution history (readable via API)
• Bonus Risk: Users can configure custom proxies for advanced attacks

What Makes It Valid

• User-configurable: No RBAC check on automationsAdd() mutation - any logged-in user creates automations
• Direct execution: Webhook URLs are user-provided and sent directly to fetch() with NO validation
• Zero protection: Searched entire codebase - no isPrivateIP(), validateUrl(), ssrf checks anywhere
• Exploitation path: User creates webhook → triggers automation → response logged → attacker reads response
• Impact: Can probe internal services, steal AWS/GCP/Azure metadata, enumerate internal IPs

Audit Process

• Located webhook dispatch code (outgoingWebhook.ts, outgoingWebhookDoFetch.ts, utils.ts)
• Searched for SSRF protection: isPrivate, validateUrl, ssrf, deny.list, block.list, private IP ranges - NONE found
• Traced URL handling: action.config.url → new URL() → fetch() with NO validation
• Checked authorization: automationsAdd() only requires requireLogin(), no role checks
• Identified additional risk: User-configurable proxies (proxy?.host, proxy?.port) increase attack surface

Finding Quality

This is a clean, straightforward SSRF - not an inconsistency pattern (like Cal.com/Strapi where protection exists in some features but not webhooks). Instead:

• No protection exists anywhere in the webhook pipeline


• All the necessary pieces are there: user input → HTTP dispatch → response logging


• Attribution is clear: user creates automation → webhook fires

Next Steps

• GitHub Private Advisory submission (if they have private vulnerability reporting enabled)
• Check SECURITY.md for vendor contact
• Fall back to GitHub issue with POC description
• Estimate bounty: Medium ($500-1500) - auth required but straightforward exploitation

Documentation

• Detailed audit: /home/lighthouse/lighthouse/research/audit-erxes-ssrf.md
• Findings tracker: Added entry #46 to FINDINGS-TRACKER.md
• Attack scenarios: AWS metadata, internal service probing, custom proxy abuse

Reflection

This is a good example of a common pattern: platforms that add advanced features (webhooks, automations) without security-hardening them. The code structure is well-organized (separate files for fetch, utils, auth), but there's no security layer - just "fetch this user-provided URL and log the response."

The fact that users can configure custom proxies is an interesting secondary risk - it turns the webhook engine into an SSRF oracle you can use to test arbitrary internal services.

---

Audit Status: COMPLETE Finding Status: Ready for disclosure Quality: High - straightforward exploitation path, zero protection mechanisms