A significant security flaw has been identified in n8n-MCP, an MCP server that provides AI assistants with access to n8n node documentation, properties, and operations. This vulnerability, tracked as CVE-2026-42449, is a type of Server-Side Request Forgery (SSRF) and carries a High severity rating. It specifically affects versions 2.47.4 through 2.47.13 of the software.<\/p>\n
The core issue lies within n8n-MCP’s synchronous URL validator, An attacker who can provide a malicious Projects that embed n8n-MCP as an SDK using The vulnerability impacts n8n-MCP versions 2.47.4 through 2.47.13<\/strong>.<\/p>\n This vulnerability is currently in an “Analyzed” status, meaning it has been reviewed and its details are publicly available. A fix has been released.<\/p>\n Rated as HIGH<\/strong>, this vulnerability carries a CVSS score of 8.5. This high rating indicates that the flaw could be exploited with significant impact, potentially leading to unauthorized access to sensitive data and internal network resources.<\/p>\n The good news is that a fix for CVE-2026-42449 is available. Users are strongly advised to:<\/p>\n If an immediate upgrade isn’t feasible, the following workarounds can help mitigate the risk:<\/p>\n https:\/\/github.com\/czlonkowski\/n8n-mcp\/commit\/9639f757853149f0cb16663cc8b6b6468f27a25f Understanding the High Severity Risk in n8n-MCP A significant security flaw has been identified in n8n-MCP, an MCP server that provides AI assistants with access to n8n node documentation, properties, and operations. This vulnerability, tracked as CVE-2026-42449, is a type of Server-Side Request Forgery (SSRF) and carries a High severity rating. It specifically affects versions […]<\/p>\n","protected":false},"author":17,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[732,1090,1083,868,696],"class_list":["post-3567","post","type-post","status-publish","format-standard","hentry","category-security","tag-cybersecurity","tag-ipv6","tag-n8n-mcp","tag-ssrf","tag-vulnerability"],"blocksy_meta":[],"yoast_head":"\nSSRFProtection.validateUrlSync()<\/code>, which failed to adequately check IPv6 addresses. This oversight meant that specially crafted IPv4-mapped IPv6 addresses, such as http:\/\/[::ffff:169.254.169.254]<\/code>, could slip past crucial security checks designed to prevent access to cloud-metadata, localhost, and private-IP ranges.<\/p>\nn8nApiUrl<\/code> value could exploit this flaw. This would enable them to force the n8n-MCP server to initiate HTTP requests to sensitive internal targets like cloud metadata endpoints or private network services. What makes this particularly dangerous is that the server would not only make these requests but also return the response bodies to the attacker. Furthermore, the x-n8n-api-key<\/code>, a sensitive API key, would be forwarded in the header to the attacker-controlled destination. This non-blind SSRF scenario could lead to extensive information disclosure and potentially deeper network compromise.<\/p>\nN8NDocumentationMCPServer<\/code> or N8NMCPEngine<\/code> with user-supplied InstanceContext<\/code> are primarily at risk. The first-party HTTP server deployment was less affected because it employed a second, asynchronous validator that could catch these IPv6 addresses.<\/p>\nCVE Details<\/h2>\n
\n
Affected Products<\/h2>\n
Current Status<\/h2>\n
Severity Level<\/h2>\n
Possible Solutions<\/h2>\n
\n
\n
n8nApiUrl<\/code> Values:<\/strong> Avoid allowing users to supply arbitrary n8nApiUrl<\/code> values, as this is the primary vector for exploitation.<\/li>\n<\/ul>\nReferences<\/h2>\n
\nhttps:\/\/github.com\/czlonkowski\/n8n-mcp\/security\/advisories\/GHSA-56c3-vfp2-5qqj<\/p>\n","protected":false},"excerpt":{"rendered":"