CVE-2026-42449: n8n SSRF bypass — HIGH

Q: Is CVE-2026-42449 actively exploited?

No confirmed active exploitation of CVE-2026-42449 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-42449?

1. **Patch immediately**: Upgrade n8n-mcp to version 2.47.14, which adds IPv6 validation to the synchronous URL validator. 2. **Audit usage pattern**: Confirm whether your deployment uses the SDK embedder path (N8NDocumentationMCPServer or N8NMCPEngine with InstanceContext) vs. the first-party HTTP server — only the SDK path is primarily affected. 3. **Network egress controls**: Block outbound requests to 169.254.0.0/16 (link-local/cloud metadata), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and ::1/128 at the firewall/security group level. 4. **Input rejection**: If patching is delayed, reject any user-supplied n8nApiUrl that is not a pre-approved allowlist of known n8n instance hostnames. 5. **Rotate n8nApiKey**: Treat any n8nApiKey passed to potentially exposed SDK instances as compromised and rotate it. 6. **Audit cloud metadata access logs**: Review IMDS access logs for anomalous requests from n8n-mcp process accounts. 7. **Detection**: Alert on HTTP requests from application processes targeting 169.254.169.254 or private IP ranges with an x-n8n-api-key header present.

Q: What systems are affected by CVE-2026-42449?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, MCP server deployments, Cloud-hosted automation pipelines, Multi-agent orchestration systems, n8n workflow automation integrations.

Q: What is the CVSS score for CVE-2026-42449?

CVE-2026-42449 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.20%.

CISO Take

n8n-mcp versions 2.47.4–2.47.13 contain a non-blind SSRF flaw where IPv4-mapped IPv6 addresses (e.g., http://[::ffff:169.254.169.254]) bypass the synchronous URL validator in SSRFProtection.validateUrlSync(), allowing attackers who control the n8nApiUrl input to reach cloud metadata endpoints, RFC1918 private networks, and localhost services. Any deployment embedding n8n-mcp as an SDK with user-supplied InstanceContext is directly exposed — the attack requires only low privileges and no user interaction, and with 75 prior CVEs in this package and an OpenSSF score of 6/10, this component has a demonstrably poor security track record. What elevates the urgency is the non-blind response: full HTTP response bodies are returned to the caller and the n8nApiKey credential is forwarded in the x-n8n-api-key header to the attacker-controlled target, enabling both cloud IAM credential theft and lateral movement in a single request. Upgrade to 2.47.14 immediately; if patching is delayed, validate all user-supplied URLs before passing to the SDK, block egress to 169.254.0.0/16 and RFC1918 ranges at the network layer, and reject any user-controlled n8nApiUrl values at the application boundary.

Sources: NVD EPSS GitHub Advisory ATLAS OpenSSF

What is the risk?

CVSS 8.5 High with Changed scope reflects accurate blast radius — a single compromised MCP server instance can pivot into cloud infrastructure, internal services, and adjacent networks. Exploitation complexity is low: the IPv4-mapped IPv6 bypass technique (::ffff: prefix) is well-documented and requires no specialized tooling. EPSS at the 92nd percentile, despite a low absolute probability, signals above-average exploitation interest relative to the CVE population. No public exploit or Nuclei template yet, but the technique is trivially reproducible by any attacker familiar with SSRF bypass methods. The credential forwarding behavior — automatically sending the n8nApiKey to attacker infrastructure — creates an immediate secondary impact beyond the SSRF itself, enabling authenticated API abuse even after the SSRF vector is closed.

How does the attack unfold?

Malicious Input Injection

Attacker supplies a crafted n8nApiUrl using an IPv4-mapped IPv6 address (e.g., http://[::ffff:169.254.169.254]/latest/meta-data/) via user-controlled InstanceContext passed to the SDK.

AML.T0049

SSRF Validation Bypass

SSRFProtection.validateUrlSync() passes the IPv6-encoded address because its checks only cover cloud-metadata strings and IPv4 private ranges, with no IPv6 logic implemented.

AML.T0053

Internal Resource Access

The server issues an HTTP request to the cloud metadata endpoint or internal service, receiving the full response body including IAM temporary credentials.

AML.T0075

Credential Exfiltration

The non-blind SSRF response (cloud metadata with IAM credentials) is returned to the attacker, and the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker's endpoint, enabling cloud-wide lateral movement and n8n workflow manipulation.

AML.T0086

Malicious Input Injection

Attacker supplies a crafted n8nApiUrl using an IPv4-mapped IPv6 address (e.g., http://[::ffff:169.254.169.254]/latest/meta-data/) via user-controlled InstanceContext passed to the SDK.

AML.T0049

SSRF Validation Bypass

SSRFProtection.validateUrlSync() passes the IPv6-encoded address because its checks only cover cloud-metadata strings and IPv4 private ranges, with no IPv6 logic implemented.

AML.T0053

Internal Resource Access

The server issues an HTTP request to the cloud metadata endpoint or internal service, receiving the full response body including IAM temporary credentials.

AML.T0075

Credential Exfiltration

The non-blind SSRF response (cloud metadata with IAM credentials) is returned to the attacker, and the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker's endpoint, enabling cloud-wide lateral movement and n8n workflow manipulation.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.47.4, < 2.47.14	`2.47.14`
193.4K OpenSSF 6.6 Pushed 2d ago 55% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

8.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 10% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I Low

A None

What should I do?

7 steps

Patch immediately

Upgrade n8n-mcp to version 2.47.14, which adds IPv6 validation to the synchronous URL validator.
Audit usage pattern

Confirm whether your deployment uses the SDK embedder path (N8NDocumentationMCPServer or N8NMCPEngine with InstanceContext) vs. the first-party HTTP server — only the SDK path is primarily affected.
Network egress controls

Block outbound requests to 169.254.0.0/16 (link-local/cloud metadata), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and ::1/128 at the firewall/security group level.
Input rejection

If patching is delayed, reject any user-supplied n8nApiUrl that is not a pre-approved allowlist of known n8n instance hostnames.
Rotate n8nApiKey

Treat any n8nApiKey passed to potentially exposed SDK instances as compromised and rotate it.
Audit cloud metadata access logs

Review IMDS access logs for anomalous requests from n8n-mcp process accounts.
Detection

Alert on HTTP requests from application processes targeting 169.254.169.254 or private IP ranges with an x-n8n-api-key header present.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Extraction Auth Bypass Supply Chain Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0055 - Unsecured Credentials AML.T0075 - Cloud Service Discovery AML.T0086 - Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.2 - AI risk assessment A.9.2 - AI system security

NIST AI RMF

MAP 5.1 - Likelihood of AI system vulnerabilities MEASURE 2.6 - AI system security and resilience metrics

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-42449?

n8n-mcp versions 2.47.4–2.47.13 contain a non-blind SSRF flaw where IPv4-mapped IPv6 addresses (e.g., http://[::ffff:169.254.169.254]) bypass the synchronous URL validator in SSRFProtection.validateUrlSync(), allowing attackers who control the n8nApiUrl input to reach cloud metadata endpoints, RFC1918 private networks, and localhost services. Any deployment embedding n8n-mcp as an SDK with user-supplied InstanceContext is directly exposed — the attack requires only low privileges and no user interaction, and with 75 prior CVEs in this package and an OpenSSF score of 6/10, this component has a demonstrably poor security track record. What elevates the urgency is the non-blind response: full HTTP response bodies are returned to the caller and the n8nApiKey credential is forwarded in the x-n8n-api-key header to the attacker-controlled target, enabling both cloud IAM credential theft and lateral movement in a single request. Upgrade to 2.47.14 immediately; if patching is delayed, validate all user-supplied URLs before passing to the SDK, block egress to 169.254.0.0/16 and RFC1918 ranges at the network layer, and reject any user-controlled n8nApiUrl values at the application boundary.

Is CVE-2026-42449 actively exploited?

No confirmed active exploitation of CVE-2026-42449 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-42449?

1. **Patch immediately**: Upgrade n8n-mcp to version 2.47.14, which adds IPv6 validation to the synchronous URL validator. 2. **Audit usage pattern**: Confirm whether your deployment uses the SDK embedder path (N8NDocumentationMCPServer or N8NMCPEngine with InstanceContext) vs. the first-party HTTP server — only the SDK path is primarily affected. 3. **Network egress controls**: Block outbound requests to 169.254.0.0/16 (link-local/cloud metadata), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and ::1/128 at the firewall/security group level. 4. **Input rejection**: If patching is delayed, reject any user-supplied n8nApiUrl that is not a pre-approved allowlist of known n8n instance hostnames. 5. **Rotate n8nApiKey**: Treat any n8nApiKey passed to potentially exposed SDK instances as compromised and rotate it. 6. **Audit cloud metadata access logs**: Review IMDS access logs for anomalous requests from n8n-mcp process accounts. 7. **Detection**: Alert on HTTP requests from application processes targeting 169.254.169.254 or private IP ranges with an x-n8n-api-key header present.

What systems are affected by CVE-2026-42449?

This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, MCP server deployments, Cloud-hosted automation pipelines, Multi-agent orchestration systems, n8n workflow automation integrations.

What is the CVSS score for CVE-2026-42449?

CVE-2026-42449 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.20%.

What is the AI security impact?

Affected AI Architectures

AI agent frameworksMCP server deploymentsCloud-hosted automation pipelinesMulti-agent orchestration systemsn8n workflow automation integrations

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0055 Unsecured Credentials

AML.T0075 Cloud Service Discovery

AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1.2, A.9.2

NIST AI RMF: MAP 5.1, MEASURE 2.6

OWASP LLM Top 10: LLM06, LLM07

What are the technical details?

Original Advisory

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. In versions 2.47.4 through 2.47.13, the SDK embedder path (N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext()), the synchronous URL validator in SSRFProtection.validateUrlSync() had no IPv6 checks. IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254] bypassed the cloud-metadata, localhost, and private-IP range checks. An attacker able to supply an n8nApiUrl value could cause the server to issue HTTP requests to cloud metadata endpoints, RFC1918 private networks, or localhost services. Response bodies are returned to the caller (non-blind SSRF), and the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker-controlled target. Projects with deployments embedding n8n-mcp as an SDK using N8NDocumentationMCPServer or N8NMCPEngine with user-supplied InstanceContext are affected. The first-party HTTP server deployment was not primarily affected — it has a second async validator (validateWebhookUrl) that catches IPv6 addresses. This issue has been fixed in version 2.47.14. If users are unable to upgrade immediately as a workaround they can validate URLs before passing to the SDK, restrict egress at the network layer, and reject user-controlled n8nApiUrl values.

Exploitation Scenario

An adversary operating an AI assistant integration that passes user-controlled configuration to N8NDocumentationMCPServer crafts an n8nApiUrl value of http://[::ffff:169.254.169.254]/latest/meta-data/iam/security-credentials/. The synchronous validator in SSRFProtection.validateUrlSync() checks for cloud-metadata strings and private IPv4 ranges but contains no IPv6 logic, so the address passes validation. The server issues an HTTP GET to the AWS IMDS endpoint, forwarding the application's n8nApiKey in the x-n8n-api-key header to the attacker's endpoint if they redirect the request. The IMDS response — containing temporary AWS IAM credentials (AccessKeyId, SecretAccessKey, SessionToken) — is returned in full to the caller. The attacker now holds both the n8n API key (for workflow manipulation) and AWS IAM credentials (for cloud-wide lateral movement), obtained through a single API call requiring only a low-privilege account on the MCP server.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF) Primary

CWE-918 — Server-Side Request Forgery (SSRF): 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.

Source: MITRE CWE corpus.