What is the CVSS score of CVE-2026-41495?

CVE-2026-41495 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-41495?

Yes, a patch is available for CVE-2026-41495. Update the affected software to the latest version immediately.

n8n-mcp CVE-2026-41495

MEDIUM

Insertion of Sensitive Information into Log File (CWE-532)

2026-04-23 https://github.com/czlonkowski/n8n-mcp

GHSA-pfm2-2mhg-8wpx

Docker Information Disclosure Node.js

5.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Patch released

Apr 24, 2026 - 02:30 nvd

Patch available

Analysis Generated

Apr 23, 2026 - 15:30 vuln.today

Analysis Generated

Apr 23, 2026 - 15:00 vuln.today

CVE Published

Apr 23, 2026 - 14:31 nvd

MEDIUM 5.3

DescriptionGitHub Advisory

Impact

When n8n-mcp runs in HTTP transport mode, incoming requests to the POST /mcp endpoint had their request metadata written to server logs regardless of the authentication outcome. 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 from the Authorization header
per-tenant API keys from the x-n8n-key header in multi-tenant setups
JSON-RPC request payloads sent to the MCP endpoint

Access control itself was not bypassed - unauthenticated requests were correctly rejected with 401 Unauthorized - but sensitive values from those rejected requests could still be persisted in logs.

Impact category: CWE-532 (Insertion of Sensitive Information into Log File).

Affected

Deployments running n8n-mcp v2.47.10 or earlier in HTTP transport mode (MCP_MODE=http). The stdio transport is not affected.

Patched

v2.47.11 and later.

npm: npx n8n-mcp@latest (or pin to >= 2.47.11)
Docker: docker pull ghcr.io/czlonkowski/n8n-mcp:latest

Workarounds

If users cannot upgrade immediately:

Restrict network access to the HTTP port (firewall, reverse proxy, or VPN) so only trusted clients can reach the endpoint.
Switch to stdio transport (MCP_MODE=stdio, the default for CLI invocation), which has no HTTP surface.

Credit

n8n-MCP thanks @S4nso (Organization / Jormungandr) for reporting this issue.

AnalysisAI

n8n-mcp v2.47.10 and earlier in HTTP transport mode logs sensitive authentication credentials and request metadata regardless of authentication outcome, allowing disclosure of bearer tokens, API keys, and JSON-RPC payloads to any system with access to server logs. While access control correctly rejects unauthenticated requests with 401 responses, the sensitive data from those rejected requests is persisted in logs before authentication is enforced, creating an information disclosure vulnerability (CWE-532) with CVSS 5.3 (low confidentiality impact). No public exploit code or active exploitation is documented; patch is available in v2.47.11.

Technical ContextAI

n8n-mcp is a Node.js-based Model Context Protocol (MCP) server implementation used for integrating AI models with n8n workflows. The vulnerability exists in the HTTP transport mode (MCP_MODE=http), which exposes a POST /mcp endpoint for receiving JSON-RPC requests. The root cause is premature logging of entire request metadata (including headers) before authentication validation occurs. In HTTP transport, the server logs incoming request details at the framework or middleware level before reaching authentication middleware that checks the Authorization header (bearer tokens) or x-n8n-key header (multi-tenant API keys). The stdio transport variant (default for CLI) is unaffected because it does not have an HTTP surface exposed to untrusted network clients. This is a classic timing-of-check vulnerability where sensitive data is logged during request processing before authentication gates determine whether the request should be trusted.

RemediationAI

Upgrade to n8n-mcp v2.47.11 or later immediately using npm install n8n-mcp@latest or npm install n8n-mcp@>=2.47.11, or pull the patched Docker image via docker pull ghcr.io/czlonkowski/n8n-mcp:latest. If immediate upgrade is not possible, apply one of two workarounds: (1) Restrict network access to the HTTP port using firewall rules, reverse proxy authentication, or VPN, ensuring only trusted clients within your organization's network can reach the POST /mcp endpoint - this prevents external attackers from sending malicious requests whose metadata would be logged, though internal threats and log visibility remain a concern; or (2) Switch to stdio transport mode by setting MCP_MODE=stdio (the default for CLI invocation), which eliminates the HTTP surface entirely and removes the network exposure vector, though this may require changes to your deployment architecture if HTTP transport is relied upon for client communication. Note that neither workaround addresses the underlying logging issue if it exists in stdio mode or if internal requests are logged - upgrade is the only complete fix.