CVE-2026-42449: IPv4-Mapped IPv6 SSRF Bypass in n8n-mcp

A server-side request forgery vulnerability in the n8n-mcp SDK allows attackers to reach cloud metadata services and internal networks by supplying IPv4-mapped IPv6 addresses. The flaw affects the synchronous URL validator used in the SDK embedder path and was silently patched in v2.47.14.

What Is CVE-2026-42449?

The vulnerability lives in SSRFProtection.validateUrlSync(), the synchronous URL validator called by N8NDocumentationMCPServer, getN8nApiClient(), and validateInstanceContext(). That validator checks for cloud-metadata IPs, localhost, and RFC1918 ranges — but only in IPv4 form. It has no IPv6 checks at all.

An address like http://[::ffff:169.254.169.254] is the IPv4-mapped IPv6 representation of the AWS Instance Metadata Service endpoint. The validator passes it without complaint.

NVD has no record for CVE-2026-42449 yet. The vendor advisory on the GitHub Security Advisory database is the authoritative source: GHSA-56c3-vfp2-5qqj.

Affected Versions

Deployments embedding n8n-mcp as an SDK using N8NDocumentationMCPServer or N8NMCPEngine with user-supplied InstanceContext on v2.47.4 through v2.47.13 are affected.

The first-party HTTP server path is largely unaffected. It runs a second, async validator (validateWebhookUrl) that does catch IPv6 addresses. The gap was specific to the SDK embedder path’s synchronous check.

What an Attacker Can Do

This is non-blind SSRF. Response bodies are returned to the caller, not discarded. An attacker who can supply an n8nApiUrl value can:

• Hit AWS IMDS (169.254.169.254), GCP, Azure, Alibaba, and Oracle cloud metadata endpoints to retrieve instance credentials and configuration
• Reach RFC1918 private network hosts unreachable from the public internet
• Query localhost services running on the same host

There is a second impact: the n8nApiKey is forwarded in the x-n8n-api-key request header to whatever URL the attacker supplies. If the attacker controls a server at that address, they receive the API key directly.

How the Bypass Works

IPv4-mapped IPv6 syntax wraps a standard IPv4 address inside an IPv6 literal: ::ffff:<IPv4>. Browsers and HTTP clients resolve these normally. A blocklist that checks 169.254.169.254 but not ::ffff:169.254.169.254 (or its hex form ::ffff:a9fe:a9fe) will miss the bypass entirely.

The fix requires normalizing any incoming address to its canonical form before running blocklist checks, then rejecting the IPv6 address families the original validator skipped.

Patch

Update to v2.47.14 or later.

npx n8n-mcp@latest

If you pin versions in a package.json, set "n8n-mcp": ">=2.47.14" and run your lockfile update.

What to Check in Your Codebase

If you embed n8n-mcp as a library, search for instantiation of N8NDocumentationMCPServer or N8NMCPEngine with any InstanceContext that accepts external input. Any path where a user or downstream system can influence n8nApiUrl was exposed on the affected versions.

After patching, audit logs for outbound requests to 169.254.0.0/16, ::ffff:169.254.0.0/112, or any RFC1918 range originating from your MCP process. Unexpected hits to those ranges before you patched are worth investigating.

Conclusion

IPv4-mapped IPv6 is a well-known SSRF filter bypass. Any URL validator that builds a blocklist for IPv4 ranges needs to normalize addresses to cover IPv4-mapped and IPv4-compatible IPv6 forms before comparing.

If you run infrastructure where external parties can supply URLs to server-side HTTP clients, that’s exactly the kind of exposure our Infrastructure Scanning work is designed to surface.