n8n-mcp — SSRF Bypass via IPv4-Mapped IPv6 Addresses (CVE-2026-42349)
AI relevance: MCP servers act as the bridge between LLM agents and external tools; an SSRF in the URL validation layer means a prompted agent can reach internal APIs, cloud metadata services, and private endpoints that the MCP server's host has network access to.
What happened
- GitHub published a high-severity advisory for n8n-mcp, an MCP server implementation used to expose n8n automation workflows as tools to LLM agents.
- The
validateUrlSync()function, responsible for blocking requests to internal addresses before tool invocation, fails to recognize IPv4-mapped IPv6 addresses (e.g.,::ffff:169.254.169.254). - An attacker who controls the URL passed to any n8n-mcp tool can bypass allowlists/denylists and access internal services on the MCP server host's network.
- The vulnerability is rated High severity and affects any project that embeds the n8n-mcp SDK.
- The advisory was published approximately 9 hours ago, with no known in-the-wild exploitation reports yet.
Why it matters
- MCP servers increasingly run alongside LLM agents in production environments, often with broad network access to internal APIs, databases, and cloud metadata endpoints.
- URL validation is a foundational SSRF defense in MCP tooling — bypassing it undermines the entire trust boundary between the agent and the network.
- The IPv4-mapped IPv6 bypass pattern is a known class of vulnerability that keeps resurfacing across different MCP implementations and agent frameworks.
- n8n is a popular workflow automation platform; combining it with MCP means agents can trigger complex automation chains. An SSRF here could pivot into full workflow abuse.
What to do
- Update n8n-mcp to the patched version as soon as it is available.
- Review URL validation logic in any MCP server you deploy — test against IPv4-mapped IPv6, DNS rebinding, and Unicode domain tricks.
- Restrict MCP server network access with egress firewall rules; block access to cloud metadata IPs (
169.254.169.254,100.100.100.200) and internal subnets. - If you embed the n8n-mcp SDK, audit your own
validateUrlSync()wrappers for the same pattern.