# GHSA-8g7g-hmwm-6rv2: n8n-mcp affected by path traversal, redirect-following SSRF, and telemetry payload exposure

> Authenticated attackers can exploit SSRF and path traversal to access internal endpoints and leak sensitive API keys via telemetry.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 8 May 2026

## What is GHSA-8g7g-hmwm-6rv2?

GHSA-8g7g-hmwm-6rv2 is a server-side request forgery vulnerability in n8n-mcp, published on 8 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

## Impact

`n8n-mcp` versions before 2.50.1 contained three independently-reported issues affecting deployments that run the n8n API integration:

1. **Caller-supplied identifiers were not validated before being used as URL path segments** by the n8n API client. An authenticated MCP caller passing a crafted workflow id could cause outbound requests carrying the configured n8n API key to land on other same-origin endpoints, bypassing handler-level access controls (including `DISABLED_TOOLS`).

2. **Validated webhook, form, and chat trigger URLs followed redirects.** A URL that passed initial validation could redirect the outbound request to a host that would otherwise have been rejected, with the response body returned to the caller. Reachable as non-blind SSRF over authenticated MCP calls.

3. **Mutation telemetry stored unredacted operation payloads.** On instances running with the default opt-in telemetry, partial-update operation diffs were uploaded without redaction. Operation values can carry the same node-parameter values the workflow contains, including bearer tokens, API keys, and webhook secrets.

## Severity

CVSS 8.3 (HIGH). Exploitation requires an authenticated MCP caller and an n8n API integration configured with an n8n API key.

## Patched versions

Upgrade to `n8n-mcp >= 2.50.1`.

## Workarounds

- For issues (1) and (2): restrict network access to the HTTP transport (firewall, reverse-proxy ACL, or VPN) so only trusted callers can reach the MCP HTTP port; or switch to stdio mode, which exposes no HTTP surface for these issues.
- For issue (3): set `N8N_MCP_TELEMETRY_DISABLED=true` in the environment before starting the server, or run `npx n8n-mcp telemetry disable` once.

## Credit

Reported by @cybercraftsolutionsllc.

## Which versions are affected by GHSA-8g7g-hmwm-6rv2?

2 open source packages ship an affected version, including n8n-mcp.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `n8n-mcp` | npm | All versions | 2.50.1 |
| `n8n-mcp` | npm | All versions | 2.50.1 |

## How do I fix GHSA-8g7g-hmwm-6rv2?

Upgrade n8n-mcp to 2.50.1 or later.

## Is GHSA-8g7g-hmwm-6rv2 being exploited?

There is no known exploitation of GHSA-8g7g-hmwm-6rv2 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-8g7g-hmwm-6rv2 and fix it if it is affected.

What it is: GHSA-8g7g-hmwm-6rv2 is a server-side request forgery vulnerability in n8n-mcp, published on 8 May 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-8g7g-hmwm-6rv2 in the wild and no public exploit code.

Affected packages and fixed versions:
- n8n-mcp (npm): affected all versions; fixed in 2.50.1
- n8n-mcp (npm): affected all versions; fixed in 2.50.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-8g7g-hmwm-6rv2/ (Markdown: https://insights.sbomify.com/GHSA-8g7g-hmwm-6rv2/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-8g7g-hmwm-6rv2

---
From sbomify Insights: https://insights.sbomify.com/GHSA-8g7g-hmwm-6rv2/
Summaries are generated and may contain mistakes; the official description above is the record.