CVE-2026-39974
Authenticated SSRF in n8n-MCP Enables Internal Data Exposure
Publication date: 2026-04-09
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| n8n-mcp | n8n-mcp | to 2.47.4 (exc) |
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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an attacker with a valid AUTH_TOKEN to perform Server-Side Request Forgery (SSRF) attacks, enabling them to access sensitive internal resources such as cloud instance metadata endpoints and internal network services. Such unauthorized access to sensitive data could lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls over access to personal and sensitive information.
Specifically, the ability to read confidential data from internal services or cloud metadata could result in exposure of personal data or protected health information, thereby compromising confidentiality requirements mandated by these standards.
Mitigations such as restricting AUTH_TOKEN distribution, disabling multi-tenant headers, and implementing egress network filtering are recommended to reduce the risk of exploitation and help maintain compliance.
Can you explain this vulnerability to me?
CVE-2026-39974 is an authenticated Server-Side Request Forgery (SSRF) vulnerability in the n8n-mcp package versions up to 2.47.3. It affects multi-tenant HTTP deployments where an attacker with a valid AUTH_TOKEN can manipulate HTTP headers to make the server send requests to arbitrary URLs. The server then reflects the response bodies back through JSON-RPC, allowing the attacker to read contents from any URL accessible by the server, including sensitive cloud metadata endpoints and internal network services.
This vulnerability arises because the server does not properly validate or restrict URLs it fetches based on client input, specifically in multi-tenant HTTP mode. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.
How can this vulnerability impact me? :
This vulnerability can allow an attacker who has a valid AUTH_TOKEN to read sensitive information from internal or cloud metadata services that the server can access. This includes cloud instance metadata endpoints (such as AWS IMDS, GCP, Azure, Alibaba, Oracle) and internal network services.
The attacker can exploit this to gather confidential data, potentially leading to information disclosure, unauthorized access to internal resources, and further attacks within the network.
- Confidentiality impact is high, meaning sensitive data can be exposed.
- Integrity impact is low, so data modification is unlikely.
- Availability impact is none, so the service remains operational.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusual HTTP requests originating from the n8n-mcp server to arbitrary or internal URLs, especially those involving multi-tenant HTTP headers such as instance-URL headers manipulated by an authenticated user.
To detect potential exploitation attempts, you can inspect network traffic or server logs for outbound HTTP requests to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (AWS IMDS, GCP, Azure, etc.) that should not normally be accessed.
Suggested commands include using network monitoring tools or command-line utilities to capture and analyze traffic from the n8n-mcp server process.
- Use tcpdump or tshark to capture outbound HTTP requests from the server, filtering for suspicious destination IPs or URLs.
- Example tcpdump command: sudo tcpdump -i <interface> 'tcp dst port 80 or tcp dst port 443' and src host <n8n-mcp-server-ip>
- Check server logs for requests containing multi-tenant headers such as x-n8n-url or x-n8n-key that may indicate manipulation.
- Use curl or similar tools to test if the server responds to crafted requests with manipulated multi-tenant headers when authenticated.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps before upgrading to the fixed version 2.47.4 include:
- Implement egress network filtering to block outbound traffic from the n8n-mcp container or server to private IP ranges (RFC1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local addresses (169.254.0.0/16), and other internal networks to prevent SSRF exploitation.
- Disable multi-tenant headers by unsetting the ENABLE_MULTI_TENANT environment variable and configure the reverse proxy to not accept x-n8n-url or x-n8n-key headers if per-request instance switching is not required.
- Restrict the distribution of AUTH_TOKENs to fully trusted operators only, avoiding sharing tokens with less-trusted clients.
Ultimately, upgrade to n8n-mcp version 2.47.4 or later, which includes built-in validation and normalization of URLs to prevent this SSRF vulnerability without requiring additional configuration.