GHSA-wg4g-395p-mqv3: n8n-mcp: credential exposure via HTTP transport logging
GHSA-wg4g-395p-mqv3 MEDIUMn8n-mcp's HTTP transport mode (MCP_MODE=http) writes raw tool-call arguments — including OAuth tokens, bearer credentials, and API keys passed through n8n_manage_credentials — verbatim to server logs before any redaction occurs. Any organization routing n8n-mcp logs to shared infrastructure (SIEM pipelines, centralized log storage, support-accessible log systems) may have already captured sensitive credentials in plaintext from ordinary authenticated tool invocations. While the CVSS 4.3 rating and authentication requirement limit direct exploitation, the real blast radius is the log pipeline: with 16 downstream dependents, 75 other CVEs in this package, and an OpenSSF Scorecard of 6.1/10, the overall security posture demands prompt action. Upgrade to v2.47.13+ immediately, rotate all credentials that transited HTTP mode tool calls, and audit existing logs for exposed secrets.
What is the risk?
The CVSS 4.3 Medium rating understates operational risk in enterprise deployments. Authentication is required but only at low privilege — any authenticated caller triggers credential logging through normal tool invocations, with no anomalous behavior detectable by standard controls. The blast radius is determined by log pipeline reach: SIEM systems, log aggregators, and support staff with read access to logs may have captured credentials without any exploit code involved. The 75 other CVEs in this package and OpenSSF Scorecard of 6.1/10 indicate systemic security debt. No KEV listing and no public exploit reduce immediate urgency, but credential rotation should be treated as urgent given log data persistence and potential retroactive exposure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | < 2.47.13 | 2.47.13 |
Do you use n8n? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Upgrade to n8n-mcp v2.47.13+ immediately: npm users run 'npx n8n-mcp@latest', Docker users run 'docker pull ghcr.io/czlonkowski/n8n-mcp:latest'.
-
Rotate all credentials (OAuth tokens, API keys, webhook secrets) that may have been passed through n8n_manage_credentials tool calls while running HTTP transport mode on v2.47.12 or earlier — treat the exposure window as the full runtime of the vulnerable version.
-
If immediate upgrade is not possible: switch to stdio transport (MCP_MODE=stdio) and firewall the HTTP port to trusted clients only via reverse proxy or VPN.
-
Audit server logs and SIEM pipelines for plaintext credential patterns in n8n-mcp log entries; purge or scrub affected log segments.
-
Review log pipeline access controls to ensure only authorized personnel can read n8n-mcp HTTP mode logs until patching is confirmed.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-wg4g-395p-mqv3?
n8n-mcp's HTTP transport mode (MCP_MODE=http) writes raw tool-call arguments — including OAuth tokens, bearer credentials, and API keys passed through n8n_manage_credentials — verbatim to server logs before any redaction occurs. Any organization routing n8n-mcp logs to shared infrastructure (SIEM pipelines, centralized log storage, support-accessible log systems) may have already captured sensitive credentials in plaintext from ordinary authenticated tool invocations. While the CVSS 4.3 rating and authentication requirement limit direct exploitation, the real blast radius is the log pipeline: with 16 downstream dependents, 75 other CVEs in this package, and an OpenSSF Scorecard of 6.1/10, the overall security posture demands prompt action. Upgrade to v2.47.13+ immediately, rotate all credentials that transited HTTP mode tool calls, and audit existing logs for exposed secrets.
Is GHSA-wg4g-395p-mqv3 actively exploited?
No confirmed active exploitation of GHSA-wg4g-395p-mqv3 has been reported, but organizations should still patch proactively.
How to fix GHSA-wg4g-395p-mqv3?
1. Upgrade to n8n-mcp v2.47.13+ immediately: npm users run 'npx n8n-mcp@latest', Docker users run 'docker pull ghcr.io/czlonkowski/n8n-mcp:latest'. 2. Rotate all credentials (OAuth tokens, API keys, webhook secrets) that may have been passed through n8n_manage_credentials tool calls while running HTTP transport mode on v2.47.12 or earlier — treat the exposure window as the full runtime of the vulnerable version. 3. If immediate upgrade is not possible: switch to stdio transport (MCP_MODE=stdio) and firewall the HTTP port to trusted clients only via reverse proxy or VPN. 4. Audit server logs and SIEM pipelines for plaintext credential patterns in n8n-mcp log entries; purge or scrub affected log segments. 5. Review log pipeline access controls to ensure only authorized personnel can read n8n-mcp HTTP mode logs until patching is confirmed.
What systems are affected by GHSA-wg4g-395p-mqv3?
This vulnerability affects the following AI/ML architecture patterns: AI agent frameworks, MCP tool servers, Workflow automation agents.
What is the CVSS score for GHSA-wg4g-395p-mqv3?
GHSA-wg4g-395p-mqv3 has a CVSS v3.1 base score of 4.3 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0037 Data from Local System AML.T0053 AI Agent Tool Invocation AML.T0055 Unsecured Credentials AML.T0083 Credentials from AI Agent Configuration Compliance Controls Affected
What are the technical details?
Original Advisory
### Impact 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. The fix removes the leak at the source. Impact category: **CWE-532** (Insertion of Sensitive Information into Log File). CVSS 3.1 score: **4.3 Medium** (`AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N`). ### Affected Deployments running n8n-mcp **v2.47.12 or earlier** in HTTP transport mode (`MCP_MODE=http`). The stdio transport short-circuits the relevant log calls and is not affected in practice. ### Patched **v2.47.13** and later. - npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.13`) - Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest` The patch routes tool-call arguments through a metadata-only summarizer (`summarizeToolCallArgs`) that records type, top-level key names, and approximate size — never values. The same pattern was adopted earlier for HTTP request bodies in GHSA-pfm2-2mhg-8wpx. ### Workarounds If developers cannot upgrade immediately: - Restrict access to the HTTP port (firewall, reverse proxy, or VPN) so only trusted clients can authenticate. - Restrict access to server logs (no shared SIEM ingestion, no support read-only access) until the upgrade lands. - Switch to stdio transport (`MCP_MODE=stdio`, the default for CLI invocation), which has no HTTP surface and short-circuits the affected log calls. ### Credit n8n-MCP thanks [@Mirr2](https://github.com/Mirr2) (Organization / Jormungandr) for reporting this issue.
Exploitation Scenario
An attacker with low-privilege access to the n8n-mcp HTTP endpoint — obtained through credential theft, phishing, or insider access — sends authenticated MCP tools/call requests to n8n_manage_credentials with OAuth tokens or API keys embedded in the tool arguments. These credential values are written verbatim to server logs by the request dispatcher before the console-silencing layer acts. The attacker then pivots to the organization's log aggregation system — a Splunk index, ELK cluster, or cloud log service — which typically has weaker access controls than the MCP endpoint itself, and searches for credential patterns in n8n-mcp log entries. Harvested credentials are then used to access third-party services or infrastructure directly, entirely bypassing n8n-mcp authentication.
Weaknesses (CWE)
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:L/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-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n