<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T23:12:34.748838+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bdu:2026-05497</id>
    <title>bdu:2026-05497</title>
    <updated>2026-10-05T23:12:34.775883+00:00</updated>
    <content>bdu:2026-05497</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-05497"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/brew-n8n-mcp-cve-2026-39974</id>
    <title>BREW-n8n-mcp-CVE-2026-39974 — n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode</title>
    <updated>2026-10-05T23:12:34.775944+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Homebrew: n8n-mcp</p>
<p>## Impact
An authenticated Server-Side Request Forgery in `n8n-mcp` allows a caller holding a valid `AUTH_TOKEN` to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach — including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to.</p>
<p>The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid `AUTH_TOKEN`, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.</p>
<p>## Affected versions
`n8n-mcp` ≤ `2.47.3` (all versions up to and including 2.47.3).</p>
<p>## Patched versions
`n8n-mcp` `2.47.4` and later.</p>
<p>## Workarounds
If you cannot immediately upgrade:
1. **Egress filtering at the network layer** — block outbound traffic from the `n8n-mcp` container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading.
2. **Disable multi-tenant headers** — if your deployment does not require per-request instance switching, unset `ENABLE_MULTI_TENANT` and do not accept `x-n8n-url` / `x-n8n-key` headers at the rever…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/brew-n8n-mcp-cve-2026-39974"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-291016</id>
    <title>EUVD-2026-291016</title>
    <updated>2026-10-05T23:12:34.776038+00:00</updated>
    <content>EUVD-2026-291016</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-291016"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-39974</id>
    <title>fkie_cve-2026-39974</title>
    <updated>2026-10-05T23:12:34.776064+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, an authenticated Server-Side Request Forgery in n8n-mcp allows a caller holding a valid AUTH_TOKEN to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach — including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to. The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid AUTH_TOKEN, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected. This vulnerability is fixed in 2.47.4.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-39974"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-4ggg-h7ph-26qr</id>
    <title>GHSA-4ggg-h7ph-26qr — n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode</title>
    <updated>2026-10-05T23:12:34.776111+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: n8n-mcp</p>
<p>## Impact
An authenticated Server-Side Request Forgery in `n8n-mcp` allows a caller holding a valid `AUTH_TOKEN` to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach — including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to.</p>
<p>The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid `AUTH_TOKEN`, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.</p>
<p>## Affected versions
`n8n-mcp` ≤ `2.47.3` (all versions up to and including 2.47.3).</p>
<p>## Patched versions
`n8n-mcp` `2.47.4` and later.</p>
<p>## Workarounds
If you cannot immediately upgrade:
1. **Egress filtering at the network layer** — block outbound traffic from the `n8n-mcp` container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading.
2. **Disable multi-tenant headers** — if your deployment does not require per-request instance switching, unset `ENABLE_MULTI_TENANT` and do not accept `x-n8n-url` / `x-n8n-key` headers at the rever…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-4ggg-h7ph-26qr"/>
  </entry>
</feed>
