CVE-2026-42449
SSRF via IPv6 Address Bypass in n8n-MCP
Publication date: 2026-05-07
Last updated on: 2026-05-07
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| n8n | mcp | From 2.47.4 (inc) to 2.47.13 (inc) |
| n8n | mcp | 2.47.14 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability immediately, users should upgrade to version 2.47.14 or later where the issue is fixed.
If upgrading is not possible immediately, the following workarounds are recommended:
- Validate URLs before passing them to the SDK to ensure they do not contain IPv4-mapped IPv6 addresses that bypass checks.
- Restrict egress traffic at the network layer to prevent unauthorized HTTP requests to cloud metadata endpoints, private IP ranges, or localhost services.
- Reject user-controlled n8nApiUrl values to avoid attackers supplying malicious URLs.
Can you explain this vulnerability to me?
This vulnerability exists in n8n-MCP versions 2.47.4 through 2.47.13, where the synchronous URL validator did not properly check IPv6 addresses. Specifically, IPv4-mapped IPv6 addresses could bypass security checks designed to block access to cloud metadata, localhost, and private IP ranges.
An attacker who can supply a malicious n8nApiUrl value could cause the server to make HTTP requests to sensitive internal endpoints such as cloud metadata services, private networks, or localhost. The server returns the response bodies to the attacker and forwards the n8nApiKey in the request header, potentially exposing sensitive information.
This issue affects projects embedding n8n-mcp as an SDK with user-supplied InstanceContext. The vulnerability was fixed in version 2.47.14.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to perform Server-Side Request Forgery (SSRF) attacks, enabling them to access internal cloud metadata endpoints, private network services, or localhost services that are normally protected.
Because the server returns response bodies and forwards the n8nApiKey to the attacker-controlled target, sensitive information such as API keys and internal data could be exposed.
This could lead to unauthorized access, information disclosure, and potentially further exploitation within your internal network or cloud environment.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the n8n-MCP server versions 2.47.4 through 2.47.13 where IPv4-mapped IPv6 addresses bypass URL validation, allowing SSRF attacks. Detection involves identifying if your deployment uses affected versions of n8n-MCP and if user-supplied n8nApiUrl values are accepted without proper validation.
To detect potential exploitation attempts on your network or system, monitor outgoing HTTP requests from the n8n-MCP server to cloud metadata endpoints (e.g., 169.254.169.254), localhost, or private IP ranges. Look for requests containing IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254].
Suggested commands to help detect suspicious activity include:
- Use network monitoring tools like tcpdump or Wireshark to capture outgoing HTTP requests from the n8n-MCP server and filter for requests to private IP ranges or cloud metadata IPs.
- Example tcpdump command to capture HTTP traffic to 169.254.169.254: tcpdump -i <interface> host 169.254.169.254 and port 80
- Check application logs for HTTP requests or errors involving IPv4-mapped IPv6 addresses or suspicious n8nApiUrl values.
- Use curl or similar tools to test if your n8n-MCP instance accepts IPv4-mapped IPv6 addresses in the n8nApiUrl parameter, for example: curl -H "x-n8n-api-key: <key>" "http://<n8n-mcp-server>/api?url=http://[::ffff:169.254.169.254]"
Upgrading to version 2.47.14 or later is recommended to fix this issue. As a temporary mitigation, validate URLs before passing them to the SDK and restrict egress traffic at the network layer.