GHSA-75HX-XJ24-MQRW: Unauthenticated Access and Information Exposure in n8n-mcp HTTP Transport

The n8n-mcp package functions as a Model Context Protocol (MCP) server, facilitating interaction between AI assistants and the n8n automation platform. This server utilizes HTTP transport to manage sessions, negotiate protocols, and stream messages between the client and the underlying n8n instance. Proper access control across all HTTP endpoints is critical to maintain session integrity and prevent unauthorized interaction.

Security researchers identified multiple severe flaws in the HTTP transport implementation of n8n-mcp prior to version 2.47.6. Several endpoints responsible for session discovery, termination, and health checking omitted fundamental authentication requirements. These flaws map directly to CWE-306 (Missing Authentication for Critical Function) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

The vulnerability surface encompasses four distinct endpoints: GET /health, GET /mcp, DELETE /mcp, and POST /mcp/test. An unauthenticated network attacker can leverage these exposed interfaces to map active transport connections and disrupt established AI assistant sessions. The combination of an information leak and an unauthenticated state-modification endpoint creates a reliable attack chain for targeted denial-of-service.

The core issue stems from an inconsistent application of the authenticateRequest middleware and the authLimiter rate-limiting component across the application's routing logic. The developers explicitly protected message transmission routes, such as POST /mcp and POST /messages, but failed to apply these same security controls to session management routes. The discovery (GET /mcp) and termination (DELETE /mcp) endpoints relied on implicit application state rather than explicit authorization validation.

Concurrently, the /health endpoint suffered from an insecure design choice. Intended primarily as a Docker health check or liveness probe, the implementation inadvertently functioned as a comprehensive diagnostic interface. It aggregated and returned sensitive internal state data, including memory utilization, security configuration flags, and most critically, an array of all active transport session identifiers.

Because the /health endpoint bypassed authentication by design to accommodate container orchestration probes, it exposed this diagnostic payload to any network-adjacent actor. The application bound session identifiers securely under normal circumstances, but the verbose health response negated these protections by broadcasting the session keys directly. This specific failure mode highlights the danger of conflating liveness probes with diagnostic telemetry.

The patch implemented in commit ca9d4b3df6419b8338983be98f7940400f78bde3 resolves both the missing authentication and the information disclosure flaws. The primary architectural change involves enforcing the authenticateRequest verification pattern and the authLimiter middleware on previously exposed routes. The developers completely removed the unauthenticated POST /mcp/test mock endpoint, eliminating it from the attack surface.

The most substantial modification occurs within the src/http-server-single-session.ts file. The vulnerable implementation of the /health endpoint previously returned a highly verbose JSON object containing a sessions object with an array of activeTransports. The patched version strips this payload down to a minimal liveness envelope containing only a status string, application version, uptime integer, and timestamp string.

// VULNERABLE CODE
app.get('/health', (req, res) => {
  const activeTransports = Object.keys(this.transports);
  res.json({ 
    status: 'ok', 
    sessions: {
      active: sessionMetrics.activeSessions,
      sessionIds: activeTransports
    },
    security: {
      defaultToken: isDefaultToken,
    },
    // ...
  });
});

Furthermore, the session management routes now require explicit authentication prior to processing requests. The patch prepends the authLimiter to the route definition and evaluates the authenticateRequest function before executing route logic.

// PATCHED CODE
app.get('/mcp', authLimiter, async (req, res) => {
  if (!this.authenticateRequest(req, res)) return;
  // Normal route logic proceeds here
});

An attacker exploits this vulnerability chain in two distinct phases: reconnaissance and execution. First, the attacker issues a standard HTTP GET request to the target server's /health endpoint. The target server responds with a JSON payload containing the sessions.sessionIds array, which lists the exact identifiers for all actively connected MCP clients.

GET /health HTTP/1.1
Host: target-ip:3000

Once the attacker possesses a valid session ID, they proceed to the execution phase. The attacker crafts an HTTP DELETE request directed at the /mcp endpoint. Crucially, the attacker includes the newly acquired session ID within the Mcp-Session-Id HTTP header. Because the target server processes this request without evaluating the AUTH_TOKEN, the attack succeeds regardless of the application's credential configuration.

DELETE /mcp HTTP/1.1
Host: target-ip:3000
Mcp-Session-Id: <leaked-id>

Upon receiving the unauthenticated termination request, the target server abruptly closes the transport connection and tears down the associated MCP server instance. The legitimate user loses connectivity immediately, resulting in a targeted denial-of-service condition. This attack requires only standard network routing and zero specialized exploit tooling.

The primary consequence of this vulnerability is an unauthenticated, targeted denial-of-service. Attackers can monitor the /health endpoint continuously to identify new sessions as they initialize. By scripting the extraction and termination phases, an adversary can prevent any legitimate AI assistant from maintaining a stable connection with the n8n-mcp server, completely disrupting automated workflows.

Beyond the denial-of-service capability, the information disclosure flaw presents a secondary risk vector. The vulnerable /health endpoint exposes a security.defaultToken boolean flag. This metric explicitly informs the attacker whether the server administrator failed to rotate the default, hardcoded authentication token (REPLACE_THIS_AUTH_TOKEN_...).

If an attacker identifies that the default token remains active, they bypass the need for session ID hijacking entirely. They can authenticate natively utilizing the known default credential, granting them full administrative control over the MCP interfaces. This elevates the impact from denial-of-service to unauthorized protocol interaction and potential workflow manipulation.

The authoritative remediation for this vulnerability requires upgrading the n8n-mcp package to version 2.47.6 or later. Organizations managing automated workflows via NPM deployments must execute package updates to ensure the patched middleware logic applies to their environment. Deployments utilizing Docker containers should pull the latest version tag and rebuild their deployment artifacts to inherit the secured health endpoint.

For environments where immediate patching is unfeasible, administrators must implement network-level access controls. Configuring firewall rules or reverse proxy restrictions to limit access to the n8n-mcp HTTP port mitigates the risk of external exploitation. Specifically, external actors must not reach the /health or /mcp routes under any circumstances.

Administrators must also review their application configuration to confirm the AUTH_TOKEN environment variable contains a strong, unique cryptographic value. Validating that the security.defaultToken flag evaluates to false ensures the system remains resilient against trivial credential stuffing attacks, regardless of the software version in use.