The n8n-mcp SDK versions 2.47.4 to 2.47.13 contain an SSRF vulnerability due to insufficient IPv6 validation in the synchronous URL validator (SSRFProtection.validateUrlSync). Specifically, IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254] bypass checks designed to block requests to cloud metadata services, localhost, and private IP ranges. This allows an attacker who can supply the n8nApiUrl parameter to induce the server to send HTTP requests to these protected endpoints. The server returns the response body to the attacker and forwards the n8nApiKey in the x-n8n-api-key header, potentially exposing sensitive information. The vulnerability affects projects embedding n8n-mcp as an SDK with user-supplied InstanceContext. The first-party HTTP server deployment is less affected due to an additional asynchronous validator that blocks IPv6 addresses. The vulnerability is resolved in version 2.47.14. Until upgrading, users can mitigate risk by validating URLs before passing them to the SDK, restricting egress traffic at the network layer, and rejecting user-controlled n8nApiUrl values.

An attacker with the ability to supply the n8nApiUrl parameter can exploit this SSRF vulnerability to make the server issue HTTP requests to internal services such as cloud metadata endpoints, localhost, and private IP ranges. The server returns the response bodies to the attacker, enabling information disclosure (non-blind SSRF). Additionally, the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker-controlled target, which could lead to further unauthorized access or privilege escalation. This vulnerability has a CVSS score of 8.5 (high severity), indicating a significant risk of confidentiality impact and partial integrity impact without availability impact.

A fixed version 2.47.14 of n8n-mcp is available and should be applied to remediate this vulnerability. If immediate upgrade is not possible, users should validate URLs before passing them to the SDK to ensure they do not point to internal or sensitive endpoints. Additionally, restricting egress network traffic to prevent unauthorized outbound requests and rejecting user-controlled n8nApiUrl values can mitigate exploitation risk. The first-party HTTP server deployment is less affected due to an additional asynchronous validator, but upgrading is still recommended.