CVE-2026-42282 in n8n-mcpinfo

Summary

by MITRE • 05/08/2026

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.13, when n8n-mcp runs in HTTP transport mode, authenticated MCP tools/call requests had their full arguments and JSON-RPC params written to server logs by the request dispatcher and several sibling code paths before any redaction. When a tool call carries credential material — most notably n8n_manage_credentials.data — the raw values can be persisted in logs. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens and OAuth credentials sent through n8n_manage_credentials, per-tenant API keys and webhook auth headers embedded in tool arguments, arbitrary secret-bearing payloads passed to any MCP tool. The issue requires authentication (AUTH_TOKEN accepted by the server), so unauthenticated callers cannot trigger it; the runtime exposure is also reduced by an existing console-silencing layer in HTTP mode, but that layer is fragile and the values are still constructed and passed into the logger. This issue has been patched in version 2.47.13.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 05/08/2026

The n8n-MCP vulnerability represents a critical logging exposure that undermines the security of authenticated AI assistant workflows within n8n's infrastructure. This flaw exists in the HTTP transport mode implementation where the request dispatcher and associated code paths fail to redact sensitive information before writing full arguments and JSON-RPC parameters to server logs. The vulnerability is particularly concerning because it affects authenticated tool calls that inherently carry credential material, making it a direct threat to the confidentiality of sensitive data flowing through the system. The issue manifests when n8n_manage_credentials.data parameters contain bearer tokens, OAuth credentials, per-tenant API keys, and webhook authentication headers that are logged in their entirety without any sanitization or redaction mechanisms.

The operational impact of this vulnerability extends far beyond the immediate scope of the request processing layer. When deployed in environments where logs are collected, forwarded to external systems, or accessible outside the trust boundary, the raw credential values become permanently exposed to unauthorized parties. This creates a significant risk for organizations that rely on shared log storage solutions, SIEM pipelines, or support/operations teams with broad access permissions. The vulnerability affects any MCP tool that receives secret-bearing payloads, making it a systemic issue rather than an isolated incident. The exposure occurs at the point of request handling where the system constructs the full argument set and passes it to the logging infrastructure, bypassing any existing security controls that might otherwise prevent credential leakage.

Security practitioners should recognize this vulnerability as a direct violation of fundamental security principles regarding data protection in transit and at rest. The issue aligns with CWE-532, which addresses information exposure through log files, and demonstrates how insufficient input validation and sanitization can create persistent security risks. From an ATT&CK perspective, this vulnerability enables credential access and privilege escalation through the exploitation of insecure logging practices, representing a path to lateral movement and persistent access within the n8n ecosystem. The requirement for authentication to trigger the vulnerability does provide some mitigation, but the fragile console-silencing layer that exists in HTTP mode creates additional risk as it can be bypassed or fail, leaving sensitive data exposed during normal operational procedures. The patch implemented in version 2.47.13 addresses this by ensuring that all arguments and JSON-RPC parameters are properly redacted before logging, preventing the accidental disclosure of sensitive credential information. Organizations using n8n-MCP in HTTP mode should immediately upgrade to version 2.47.13 or later to remediate this vulnerability and prevent potential credential compromise through log-based attacks.

Responsible

GitHub M

Reservation

04/26/2026

Disclosure

05/08/2026

Moderation

accepted

CPE

ready

EPSS

0.00250

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!