GHSA-WG4G-395P-MQV3: Cleartext Logging of Sensitive Tool-Call Arguments in n8n-mcp

The n8n-mcp package provides a Model Context Protocol (MCP) server implementation for interacting with n8n workflows. When the server is configured to operate in HTTP mode (Single Session), it handles incoming JSON-RPC requests from AI assistants and other clients. The implementation of the HTTP handler inadvertently records the entire parsed request body to standard logging facilities.

This behavior introduces a CWE-532 (Insertion of Sensitive Information into Log File) vulnerability. The Model Context Protocol uses the params field of the JSON-RPC request to transmit operational data, which frequently includes API keys, authentication tokens, private infrastructure URLs, and sensitive user input destined for workflow processing.

By persisting this cleartext data to standard output or log files, the application breaks the confidentiality boundary of the encrypted HTTP transport. Log management systems, which typically possess less stringent access controls than production databases or secret managers, will permanently index these credentials.

The root cause exists within the SingleSessionHTTPServer class located in the http-server-single-session.ts file. This component is responsible for intercepting and routing HTTP requests containing MCP tool calls. When a request is authenticated and processed, the server logs an informational message indicating that a request is being handled.

The developers explicitly constructed the log object by referencing the params attribute of the incoming JSON body. Unlike HTTP headers, where developers frequently apply redaction filters, the JSON-RPC payload was treated as safe diagnostic data. The application did not differentiate between generic operational arguments and sensitive authentication material passed within the same object structure.

The logging instruction executes synchronously upon request receipt. Because the log aggregator records the raw properties of the req.body object, any AI assistant executing a tool call that requires secrets will automatically inject those secrets into the application's logging stream. The vulnerability is fundamentally a failure to sanitize untrusted structured data before passing it to an I/O subsystem.

The vulnerability stems from an explicit logging call in the HTTP request handler. The code constructs an object using properties directly extracted from the incoming request body, notably including the params field.

// PRE-PATCH (Vulnerable)
logger.info('handleRequest: Processing MCP request', {
    method: req.body?.method,
    params: req.body?.params,  // Vulnerable parameter logging
    id: req.body?.id
});

The patch implemented in version 2.47.3 (commit 643c98bcf7663fe8f08f6dfd21d2ddeb56634387) removes the params field from the logging output entirely. This fix directly addresses the CodeQL js/clear-text-logging alert by dropping the untrusted data from the diagnostic output.

// POST-PATCH (Fixed)
logger.info('handleRequest: Processing MCP request', {
    method: req.body?.method,
    id: req.body?.id           // Safe attributes retained
});

This remediation is complete for this specific code path. By strictly limiting the logged fields to operational metadata (method and id), the developers ensure that user-provided arguments cannot inadvertently bleed into the logging infrastructure. This approach is superior to implementing a regex-based redaction filter, which is prone to bypasses and maintenance overhead.

Exploitation of this vulnerability requires access to the application's logging infrastructure rather than direct network access to the MCP server. The attack is passive; the threat actor monitors log files, container stdout streams, or centralized logging platforms (such as ELK, Splunk, or Datadog) to extract harvested credentials.

A typical exploitation scenario involves an attacker who has compromised a secondary system or holds internal privileges that grant log read access. When a legitimate user interacts with an AI assistant to trigger an n8n workflow, the assistant generates a tool call.

The resulting log entry provides the attacker with structured, easily parseable cleartext credentials. A sample log entry appears as follows: info: handleRequest: Processing MCP request { method: 'tools/call', params: { name: 'n8n_run_workflow', arguments: { apiKey: 'SECRET_VALUE' } }, id: 1 }. Attackers can utilize automated scripts to continuously scrape these logs for regex patterns matching API keys or session tokens.

The primary impact is a severe loss of confidentiality for systems integrating with the n8n-mcp service. API keys, database connection strings, and user credentials passed as arguments to n8n workflows are routinely exposed. This exposure facilitates horizontal privilege escalation, allowing an attacker to authenticate to internal services bypassing normal access controls.

The severity of the impact depends heavily on the deployment environment's log retention and access policies. In environments where logs are forwarded to shared dashboards or retained indefinitely, the window of exposure is significant. Developers often assume that authenticated HTTP traffic is secure, making the silent leakage into backend logs particularly dangerous.

Furthermore, this logging behavior violates standard compliance frameworks (such as SOC2, PCI-DSS, and GDPR) which strictly prohibit the cleartext storage of sensitive authentication material or personally identifiable information (PII). Organizations discovering this vulnerability must assume that any credentials used in conjunction with the MCP server prior to patching have been compromised.

The primary remediation is to upgrade the n8n-mcp package to version 2.47.3 or later. This version implements the necessary code changes to prevent the logging of the params object. Developers should verify the installed version by inspecting the package.json lockfiles and executing npm update n8n-mcp.

Applying the patch does not secure credentials that have already been written to log files. Organizations must identify the location of their logging data and execute a purge of historical logs containing the handleRequest: Processing MCP request string. If targeted log deletion is not feasible, log rotation policies should be aggressively accelerated to drop the vulnerable historical data.

Finally, all security tokens, API keys, and passwords that were transmitted to the MCP server during the vulnerable period must be considered compromised and rotated immediately. Relying solely on patching the library without rotating exposed credentials leaves the system vulnerable to exploitation using historical log data.