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.

Sources