GHSA-8g7g-hmwm-6rv2: Path Traversal, SSRF, and Information Exposure in n8n-mcp

The n8n-mcp package prior to version 2.50.1 contains three distinct security vulnerabilities that compromise the confidentiality and integrity of the application environment. These vulnerabilities exist across different components: the API client implementation, the webhook trigger handling mechanism, and the telemetry service.

The path traversal vulnerability (CWE-22) allows attackers to escape the intended API endpoint structure. By manipulating identifiers supplied to the API client, an attacker forces the application to request arbitrary restricted endpoints using its own authenticated context. This grants unauthorized access to internal resources such as stored credentials.

The Server-Side Request Forgery (SSRF) vulnerability (CWE-918) circumvents domain validation mechanisms in webhook and trigger endpoints. Attackers bypass initial whitelist checks by supplying endpoints that return HTTP redirects pointing to internal infrastructure. The information exposure vulnerability (CWE-200, CWE-212) leaks sensitive workflow data, including third-party API tokens and passwords, into unredacted telemetry logs.

The path traversal vulnerability originates in the N8nApiClient class. The application constructs outbound API request paths by directly interpolating user-supplied input, such as workflowId, credentialId, or tagId, into string templates. The application fails to apply validation or sanitization to these inputs before executing the outbound HTTP request.

When an attacker provides a payload containing directory traversal sequences (../), the underlying HTTP client normalizes the resulting URL path. Because the outbound request automatically includes the n8n-api-key header, the attacker leverages the application's own authentication context. This design allows the attacker to execute arbitrary authenticated API calls against the n8n server.

The SSRF vulnerability exists in the handler logic for webhook, form, and chat triggers. The application correctly implements initial target validation against a whitelist or domain policy. However, the underlying axios HTTP client is configured to follow HTTP 301 and 302 redirects by default.

Attackers exploit this default behavior by providing a URL that points to an external server under their control. Once the initial validation passes, the attacker's server responds with an HTTP 302 redirect pointing to an internal IP address or cloud metadata endpoint. The axios client blindly follows this redirect, executing an unintended request against internal infrastructure.

The telemetry data leakage vulnerability occurs within the telemetry service component responsible for recording user actions. The application records "mutation payloads," which represent the structural differences (diffs) of changes made to workflows during AI-assisted editing sessions.

These mutation payloads capture the raw state of workflow configurations. The application previously transmitted and stored these payloads without applying sufficient redaction to sensitive property keys.

Consequently, sensitive parameters embedded within the workflows—including webhook secrets, database connection passwords, and third-party API tokens—were written in plain text to telemetry logs or databases. This behavior violates CWE-212 (Improper Removal of Sensitive Information before Storage or Transfer) and permanently compromises the affected secrets if the logs are accessed by unauthorized personnel.

The remediation introduced in commit 1cfe9c6bddb4b1634e6e23323c18ea35fd196999 systematically addresses all three vulnerabilities through strict input validation, client configuration changes, and data sanitization.

For the path traversal flaw, the developers introduced the encodeApiPathSegment utility function in src/utils/validation-schemas.ts. This function strictly enforces an alphanumeric pattern and limits string length. All API methods were updated to wrap user input with this function.

// src/utils/validation-schemas.ts
const API_PATH_SEGMENT_PATTERN = /^[A-Za-z0-9_-]+$/;
export function encodeApiPathSegment(value: unknown, fieldName: string): string {
  if (typeof value !== 'string' || value.length === 0) { /* error handling */ }
  if (!API_PATH_SEGMENT_PATTERN.test(value)) {
    throw new ValidationError(`Invalid ${fieldName}: must contain only alphanumeric characters...`);
  }
  return encodeURIComponent(value);
}
 
// src/services/n8n-api-client.ts (Patched Usage)
const response = await this.client.get(`/workflows/${encodeApiPathSegment(id, 'workflowId')}`);

The SSRF bypass was resolved by modifying the axios client configuration within the trigger handlers (src/triggers/handlers/chat-handler.ts). The maxRedirects property was explicitly set to 0. This configuration change instructs the client to terminate the request immediately upon receiving an HTTP redirect, entirely neutralizing the post-validation redirect attack vector.

// src/triggers/handlers/chat-handler.ts (Patched Configuration)
const config = {
  // ... existing configuration
  maxRedirects: 0, // SECURITY: no redirect-following on validated URLs.
};

The telemetry leakage was mitigated by introducing a WorkflowSanitizer.sanitizeTelemetryObject method in src/telemetry/mutation-tracker.ts. This method traverses mutation payloads and strips or masks values associated with known sensitive keys before the telemetry data is dispatched.

Exploiting the path traversal vulnerability requires the attacker to interact with an application tool that accepts an identifier parameter. For example, if the application exposes a getWorkflow tool, the attacker supplies a crafted payload, such as ../../credentials/list, in place of a valid workflow ID.

The application interpolates this payload into the request path without validation, generating an outbound HTTP GET request to /workflows/../../credentials/list. The underlying n8n API server normalizes this path to /credentials/list. Since the application attaches its own API key to the request headers, the n8n server authorizes the call and returns the system's stored credentials to the attacker.

Exploiting the SSRF vulnerability requires the attacker to specify a trigger URL, such as a webhook endpoint. The attacker provides a URL pointing to a controlled external server, for example, http://attacker-controlled.com/redirect. The application validates this domain against its internal policies and proceeds with the HTTP request.

The attacker's server responds to the initial request with an HTTP 302 redirect, specifying a target like http://169.254.169.254/latest/meta-data/iam/security-credentials/. The unpatched axios client blindly follows this redirect to the AWS IMDS endpoint. The application retrieves the cloud provider IAM credentials and subsequently exposes the response data to the attacker.

The vulnerabilities within n8n-mcp create a multi-faceted risk environment resulting in severe confidentiality degradation and internal network exposure. The path traversal directly facilitates the unauthorized extraction of application-level credentials and secrets stored within the n8n database.

The SSRF vulnerability provides attackers with an unauthenticated pivot point into the internal network environment hosting the application. This access enables the enumeration of internal services, direct interaction with local unauthenticated APIs (e.g., Redis, Elasticsearch), and the extraction of high-value secrets from cloud provider metadata services (IMDS).

The telemetry exposure vulnerability exacerbates the overall risk profile by persisting sensitive workflow secrets in historical logs. Attackers gaining access to these logs or the underlying telemetry storage layer obtain valid authentication tokens for external third-party services configured by the application's users.

Administrators operating n8n-mcp must upgrade to version 2.50.1 immediately. This release contains the requisite input validation schemas, strict redirect policies, and telemetry sanitization logic required to mitigate the vulnerabilities detailed in GHSA-8g7g-hmwm-6rv2.

If immediate patching is not technically feasible, administrators should implement strict egress network filtering on the server hosting the n8n-mcp application. Block outbound HTTP traffic to the link-local address block (169.254.0.0/16) and internal RFC1918 IP spaces to limit the impact of the SSRF vulnerability.

Developers utilizing the n8n-mcp SDK to build custom integrations must review their internal usage of HTTP clients. Ensure that the maxRedirects property is set to 0 when processing user-supplied URLs, and validate all path segments using strict alphanumeric regular expressions before interpolating them into API requests.