SSRF vulnerability in n8n
- Feb 12
- 2 min read
What this means (non-technical)
This issue appears when a workflow builds an HTTP request URL using user-provided input. For example, a webhook sends a field called url, and your HTTP Request node uses that value directly as the request target.
This allows external users to influence where your server sends requests.
What usually goes wrong
Instead of calling a trusted external API, someone could make your server send requests to:
Internal services inside your network.
Private IP addresses.
Cloud metadata endpoints that expose credentials.
Because the request comes from your server, it may bypass normal firewall protections.
This can lead to internal systems being accessed in ways you never intended. It’s especially confusing because the workflow looks like it’s just making a normal HTTP call.
When this becomes urgent
This becomes urgent when:
Your workflow accepts URLs or hostnames from webhooks.
Your n8n instance runs inside a private network or cloud environment.
The server has access to internal databases or admin services.
The more access your server has internally, the more impact this issue can have.
Detect issues in your n8n workflows
|
Definitions
HTTP request: A call your workflow makes to another web service.
Internal network: Services that are only accessible from inside your server or cloud environment.
Cloud metadata endpoint: A special internal address used by cloud providers that can expose instance credentials.
Disclaimer
This article highlights common patterns and risks seen in real-world n8n workflows. It’s meant to help you build more confidently and avoid surprises as your automation grows. Behavior can vary depending on your setup, version, and configuration.