CVE-2026-42449 - n8n-mcp IPv4-mapped IPv6 SSRF

rg -n "n8n-mcp|N8NDocumentationMCPServer|N8NMCPEngine|getN8nApiClient|validateInstanceContext|n8nApiUrl" .
npm ls n8n-mcp
pnpm why n8n-mcp
yarn why n8n-mcp
rg -n "169\\.254\\.169\\.254|metadata\\.google|metadata\\.azure|InstanceContext|x-n8n-api-key" .

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-42449 (n8n-mcp IPv4-mapped IPv6 SSRF bypass).
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades `n8n-mcp`, closes reachable
  `n8nApiUrl` SSRF paths, adds regression coverage, and documents operator
  cleanup, or
- TRIAGE.md if this repository does not own an affected SDK embedder or safe
  patch path.

## Rules

- Scope only CVE-2026-42449.
- Do not make live requests to cloud metadata, loopback admin services, or
  private production networks while testing.
- Do not print, snapshot, or commit n8n API keys, MCP secrets, metadata tokens,
  request headers, or SSRF response bodies.
- Do not weaken URL validation to preserve backwards compatibility with unsafe
  IP-literal or private-network instance URLs.
- Do not auto-merge.

## Steps

1. Inventory every `n8n-mcp` dependency and deployment reference in package
   manifests, lockfiles, Dockerfiles, compose files, Helm values, SBOMs,
   generated dependency manifests, and MCP server configuration.
2. Determine whether any resolved version is `>=2.47.4, <2.47.14`.
3. Search application code for SDK embedder usage:
   - `N8NDocumentationMCPServer`;
   - `N8NMCPEngine`;
   - `getN8nApiClient()`;
   - `validateInstanceContext()`;
   - `InstanceContext`;
   - `n8nApiUrl`.
4. If the repository does not embed `n8n-mcp` as an SDK or never accepts a
   user-controlled `n8nApiUrl`, stop with `TRIAGE.md` documenting package
   versions, call-path evidence, and why the vulnerable path is not reachable.
5. Upgrade affected package references to `n8n-mcp >=2.47.14` using the repo's
   package manager. Regenerate lockfiles, container metadata, and SBOMs as
   appropriate.
6. Add or tighten pre-SDK validation for any configurable `n8nApiUrl`:
   - require `https:` unless local development has an explicit test-only path;
   - reject IP-literal hosts, including bracketed IPv6 and IPv4-mapped IPv6;
   - reject localhost, loopback, link-local, RFC1918, and cloud metadata hosts;
   - prefer a finite allow-list for approved n8n instance hostnames;
   - make validation fail closed before an `x-n8n-api-key` can be attached.
7. Add regression tests using inert URLs that prove the app rejects:
   - `http://[::ffff:169.254.169.254]/`;
   - `http://[::ffff:127.0.0.1]/`;
   - `http://169.254.169.254/`;
   - `http://127.0.0.1/`;
   - any project-specific private CIDR or internal host pattern.
8. Add deployment or runbook containment where this repository controls it:
   deny egress from the `n8n-mcp` process to metadata endpoints, loopback,
   RFC1918 ranges, link-local ranges, and internal service CIDRs that should
   never be n8n API targets.
9. Add a PR body section named `CVE-2026-42449 operator actions` that states:
   - whether the SDK embedder path was reachable;
   - which versions were upgraded;
   - whether user-controlled `n8nApiUrl` values existed;
   - which n8n API keys should be rotated if untrusted URLs were possible;
   - which logs should be reviewed for bracketed IPv6, IPv4-mapped IPv6,
     metadata-host, or private-network URL attempts.
10. Run the relevant validation: package-manager install check, unit tests,
    integration tests for URL validation, lint/typecheck, image build, deploy
    rendering, and dependency/security scans available in this repository.
11. Use PR title:
    `fix(sec): remediate CVE-2026-42449 in n8n-mcp`.

## Stop conditions

- This repository only runs the first-party `n8n-mcp` HTTP server and does not
  expose the affected SDK embedder path.
- The project does not control the dependency or container image selection.
- The only known `n8nApiUrl` source is hard-coded internal configuration, and
  a lockfile or image scan proves no vulnerable runtime remains.
- The fix would require accepting user-controlled private-network URLs as a
  product feature; document the risk and require a product/security decision.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.