n8n - 💡(How to fix) Fix [SECURITY] SSRF Protection Only When Credential Domains Configured [1 comments, 2 participants]

{ "title": "[SECURITY] SSRF Protection Only When Credential Domains Configured", "body": "## Summary\n\nThe SSRF protection via allowedDomains in the n8n HTTP Request node is ONLY enforced when credentials are attached with explicit domain restrictions. If no credential is attached, requests can go to ANY URL including internal services.\n\n## Vulnerability Details\n\n- Vulnerability Type: Server-Side Request Forgery (SSRF)\n- Severity: HIGH\n- CVE ID: N8N-SSRF-001 (to be requested)\n\n## Technical Description\n\nThe n8n HTTP Request node provides SSRF protection through the allowedDomains credential property. However, this protection is only active when:\n\n1. Credentials are attached to the HTTP Request node\n2. The credentials have explicit domain restrictions configured\n\nWhen no credential is attached to the HTTP Request node, the SSRF protection is completely bypassed. This allows attackers to:\n\n- Access internal services (localhost, 127.0.0.1)\n- Query cloud metadata endpoints (169.254.169.254)\n- Scan internal networks\n- Access internal APIs and services\n\n## Proof of Concept\n\n1. Create an HTTP Request node in n8n\n2. Do NOT attach any credential to the node\n3. Set URL to http://169.254.169.254/latest/meta-data/\n4. Execute the node\n5. The request succeeds (no SSRF protection applied)\n\n## Impact\n\n- Cloud metadata exposure (AWS, GCP, Azure)\n- Internal service enumeration\n- Potential RCE through internal service exploitation\n\n## Recommended Fix\n\nThe SSRF protection should be enforced regardless of whether credentials are attached. Consider:\n\n1. Applying allowedDomains restrictions even without credentials\n2. Adding a global SSRF protection setting\n3. Warning/blocking requests to known internal IP ranges when no credential is attached\n\n## References\n\n- CWE-918: Server-Side Request Forgery\n- OWASP: Server-Side Request Forgery" }