AI Threat Alert
n8n-mcp's HTTP transport mode logged all incoming request metadata—including bearer tokens and per-tenant API keys—prior to completing authentication validation, meaning every rejected probe persisted credentials in plaintext across log infrastructure. With 16 downstream dependents, 75 prior CVEs in the same package, and an OpenSSF score of only 6.1/10, this package carries an elevated supply-chain risk profile; its 86th-percentile EPSS ranking signals above-average exploitation interest relative to the broader CVE population. Any deployment forwarding logs to a SIEM, shared log aggregator, or third-party observability platform should treat those log stores as potentially compromised and rotate all bearer tokens and x-n8n-key API keys immediately upon patching to version 2.47.11.
What is the risk?
Medium severity (CVSS 5.3) with no active exploitation confirmed and no public exploit available. However, attack complexity is low—no authentication required to trigger the credential-logging behavior—and the real risk multiplier is log forwarding architecture: any pipeline routing logs to a SIEM, centralized aggregator, or shared ops tooling effectively broadcasts credentials to every party with log read access. In multi-tenant deployments, per-tenant API keys from all tenants are exposed simultaneously, amplifying blast radius beyond a single-tenant compromise.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | < 2.47.11 | 2.47.11 |
Do you use n8n? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Patch immediately: upgrade n8n-mcp to version 2.47.11, which redacts sensitive headers prior to log writes.
-
Rotate all credentials: invalidate and reissue all bearer tokens and x-n8n-key API keys that may have transited the MCP endpoint.
-
Audit historical logs: search log stores for 'Authorization: Bearer' and 'x-n8n-key' patterns—any matches should be treated as compromised.
-
Restrict log access: enforce least-privilege on log storage and SIEM pipelines until credential rotation is confirmed complete.
-
Workaround (if patching is delayed): switch n8n-mcp to stdio transport mode instead of HTTP, which does not exhibit this logging behavior.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-41495?
n8n-mcp's HTTP transport mode logged all incoming request metadata—including bearer tokens and per-tenant API keys—prior to completing authentication validation, meaning every rejected probe persisted credentials in plaintext across log infrastructure. With 16 downstream dependents, 75 prior CVEs in the same package, and an OpenSSF score of only 6.1/10, this package carries an elevated supply-chain risk profile; its 86th-percentile EPSS ranking signals above-average exploitation interest relative to the broader CVE population. Any deployment forwarding logs to a SIEM, shared log aggregator, or third-party observability platform should treat those log stores as potentially compromised and rotate all bearer tokens and x-n8n-key API keys immediately upon patching to version 2.47.11.
Is CVE-2026-41495 actively exploited?
No confirmed active exploitation of CVE-2026-41495 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-41495?
1. Patch immediately: upgrade n8n-mcp to version 2.47.11, which redacts sensitive headers prior to log writes. 2. Rotate all credentials: invalidate and reissue all bearer tokens and x-n8n-key API keys that may have transited the MCP endpoint. 3. Audit historical logs: search log stores for 'Authorization: Bearer' and 'x-n8n-key' patterns—any matches should be treated as compromised. 4. Restrict log access: enforce least-privilege on log storage and SIEM pipelines until credential rotation is confirmed complete. 5. Workaround (if patching is delayed): switch n8n-mcp to stdio transport mode instead of HTTP, which does not exhibit this logging behavior.
What systems are affected by CVE-2026-41495?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, workflow automation, multi-tenant AI platforms.
What is the CVSS score for CVE-2026-41495?
CVE-2026-41495 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.26%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0025 Exfiltration via Cyber Means AML.T0036 Data from Information Repositories AML.T0055 Unsecured Credentials Compliance Controls Affected
What are the technical details?
Original Advisory
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.11, 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. This issue has been patched in version 2.47.11.
Exploitation Scenario
An adversary with read access to any log aggregation system receiving n8n-mcp HTTP transport logs—a SIEM operator account, shared ops tooling, or a third-party log storage breach—scans for Authorization header values in the POST /mcp endpoint logs. Because unauthenticated requests are logged with full headers before rejection, the attacker does not need to successfully authenticate to generate loggable credential entries; they simply send probing requests to the endpoint. Once bearer tokens or x-n8n-key values are extracted from logs, the adversary replays them against the MCP HTTP API to authenticate as legitimate users, gaining full access to n8n node operations and the ability to invoke AI agent tool calls within connected workflows.
Weaknesses (CWE)
CWE-532 Insertion of Sensitive Information into Log File
Primary
CWE-532 Insertion of Sensitive Information into Log File
Primary
CWE-532 — Insertion of Sensitive Information into Log File: The product writes sensitive information to a log file.
- [Architecture and Design, Implementation] Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
- [Distribution] Remove debug log files before deploying the application into production.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2026-27577 9.9 n8n: Code Injection enables RCE
Same package: n8n CVE-2026-27494 9.9 n8n: security flaw enables exploitation
Same package: n8n