GHSA-4GGG-H7PH-26QR: Authenticated Server-Side Request Forgery in n8n-mcp Multi-Tenant Mode

The n8n-mcp npm package provides an integration layer between n8n workflow automation and the Model Context Protocol (MCP). The software operates a server component that can function in a multi-tenant HTTP mode. This mode dynamically routes requests to specific n8n instances based on client-provided configuration.

The vulnerability exists within this multi-tenant routing logic. The server extracts instance location data directly from the x-n8n-url HTTP header supplied by the client. It then uses this extracted value as the base URL for backend API calls without performing adequate validation or sanitization on the destination address.

Because the MCP server acts as an intermediary bridge, it reflects the response bodies obtained from these backend requests back to the client via JSON-RPC. This configuration transforms a standard request routing mechanism into a Full Server-Side Request Forgery (SSRF) condition. Authenticated attackers can supply arbitrary URLs and read the resulting response data.

The vulnerability is tracked as GHSA-4GGG-H7PH-26QR and is classified as CWE-918. Successful exploitation requires the attacker to possess valid credentials for the MCP server. The primary impact involves unauthorized information disclosure from internal network segments and contiguous cloud infrastructure.

The root cause of this vulnerability lies in the improper handling of user-controlled input within the server's network request initialization phase. In multi-tenant mode, clients specify their target n8n instance URL and API key using custom HTTP headers. The system extracts the x-n8n-url value to determine where subsequent operational data should be sent.

Prior to version 2.47.4, the application passed this raw header value directly into the baseURL parameter of an axios HTTP client instance. The code lacked structural validation to restrict the hostname, IP address, or port of the provided URL. The server blindly trusted the client-supplied destination.

The absence of specific validation mechanisms means the server evaluates all valid URI formats equally. An attacker can substitute the expected n8n instance URL with an IP address corresponding to a local loopback interface (127.0.0.1), a private network range (RFC1918), or a cloud provider's link-local metadata service. The axios client successfully resolves these addresses and executes the HTTP requests.

Following the execution of the backend request, the MCP server packages the HTTP response payload into a JSON-RPC message. This message is then transmitted back to the original client. This specific architecture upgrades the vulnerability from a blind SSRF, where an attacker only infers success via timing or error states, to a full SSRF where the attacker obtains the complete contents of the internal resource.

The remediation implemented in commit d9d847f230923d96e0857ccecf3a4dedcc9b0096 introduces a dedicated SSRFProtection utility class. This class provides both synchronous and asynchronous validation methods to rigorously inspect user-supplied URLs before they reach the HTTP client component. The synchronous checks perform initial sanitization and format validation.

static validateUrlSync(urlString: string): { valid: boolean; reason?: string } {
    if (typeof urlString !== 'string' || urlString.includes('#')) {
      return { valid: false, reason: 'URL fragments are not allowed' };
    }
    let url: URL;
    try {
      url = new URL(urlString);
    } catch {
      return { valid: false, reason: 'Invalid URL format' };
    }
    if (!['http:', 'https:'].includes(url.protocol)) {
      return { valid: false, reason: 'Invalid protocol. Only HTTP/HTTPS allowed.' };
    }
    if (url.username !== '' || url.password !== '') {
      return { valid: false, reason: 'Userinfo in URL is not allowed' };
    }
    // Additional checks for private IPs and Cloud Metadata omitted for brevity
}

The code block above demonstrates the new validateUrlSync method. It explicitly rejects URL fragments, restricts protocols to HTTP and HTTPS, and prevents the inclusion of embedded credentials via the userinfo component. Subsequent lines in the patched file introduce hardcoded blocklists for loopback addresses and the 169.254.169.254 cloud metadata endpoint.

To address bypass techniques involving DNS rebinding or custom hostnames resolving to internal IPs, the patch includes an asynchronous validateWebhookUrl method. This function performs explicit DNS resolution on the hostname before initiating the request. If the resolved IP address falls within a restricted range, the server aborts the connection attempt.

The SingleSessionHTTPServer component integrates these validation routines by invoking validateInstanceContext immediately after parsing the headers. If the URL fails either the synchronous format checks or the asynchronous DNS resolution constraints, the server terminates the transaction and returns a 400 Bad Request HTTP status code.

Exploiting this vulnerability requires the attacker to possess valid authentication credentials for the n8n-mcp server. The server must also be operating in the vulnerable multi-tenant HTTP mode. With these prerequisites met, the attacker crafts a standard request to the MCP service.

The core of the exploit involves manipulating the HTTP headers sent during the initial connection. The attacker modifies the x-n8n-url header, replacing a legitimate n8n instance URL with a target internal endpoint. A common exploitation target is a cloud provider metadata service, accessed via http://169.254.169.254/latest/meta-data/.

The attacker provides a syntactically valid but functionally arbitrary value for the x-n8n-key header to satisfy basic input requirements. Upon receiving the crafted request, the n8n-mcp server extracts the malicious URL and executes an outbound HTTP GET request to the specified internal address. The server processes the metadata service's response.

The server subsequently wraps the retrieved internal data within its standard JSON-RPC response format and transmits it back to the attacker. The attacker receives the full text of the cloud metadata response. Repeating this process allows the attacker to traverse the metadata directory structure and extract temporary identity tokens or instance profiles.

The primary consequence of this vulnerability is the unauthorized disclosure of sensitive information from restricted network environments. Because the SSRF execution reflects the full response body, attackers can comprehensively map internal network services. They can identify open ports, retrieve internal application banners, and interact with unauthenticated internal administrative interfaces.

The most severe impact materializes when the vulnerable n8n-mcp server is hosted within a cloud infrastructure environment. Attackers can explicitly target the cloud provider metadata endpoints (e.g., AWS IMDS, Azure Instance Metadata Service, GCP Metadata Server). These endpoints often provide sensitive operational data without requiring authentication from the local instance.

By querying specific metadata paths, attackers can extract temporary security credentials assigned to the host instance. If the compromised instance profile possesses elevated Identity and Access Management (IAM) permissions, the attacker can use those credentials to authenticate directly to the cloud provider's API. This facilitates lateral movement and potential escalation of privileges across the broader cloud environment.

The requirement for initial authentication limits the exposure strictly to authorized tenants of the MCP server. However, in environments where tenant isolation is expected to prevent access to underlying infrastructure, this vulnerability completely undermines that boundary. The impact remains high due to the potential compromise of foundational infrastructure credentials.

The definitive remediation for this vulnerability requires upgrading the n8n-mcp package to version 2.47.4 or later. This release incorporates the SSRFProtection module, which effectively neutralizes the attack vector by validating URLs and performing mandatory DNS resolution checks. Administrators must ensure all instances of the application are updated and restarted.

If an immediate software upgrade is not operationally feasible, administrators can apply architectural workarounds. Disabling the multi-tenant HTTP mode entirely removes the vulnerable code path from execution. This configuration forces the server to rely on static, pre-configured instance URLs that clients cannot manipulate via HTTP headers.

Network-level controls provide a defense-in-depth mitigation strategy. Organizations should implement strict egress filtering rules on the host operating the n8n-mcp server. Firewall rules must explicitly deny outbound connections to cloud metadata IP addresses (169.254.169.254) and restrict general internet access to only trusted n8n instance destinations.

Security teams should monitor application and network logs for indicators of compromise. The patched version of the software emits specific log warnings, such as SSRF protection blocked instance context URL, when a blocked request is detected. Additionally, auditing VPC flow logs for unexpected outbound traffic from the MCP server to RFC1918 address space will assist in identifying exploitation attempts.