CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
6083 vulnerabilities reference this CWE, most recent first.
GHSA-CJW6-FCR4-7QRH
Vulnerability from github – Published: 2023-07-20 12:30 – Updated: 2024-04-04 06:17InfoDoc Document On-line Submission and Approval System lacks sufficient restrictions on the available tags within its HTML to PDF conversion function, and allowing an unauthenticated attackers to load remote or local resources through HTML tags such as iframe. This vulnerability allows unauthenticated remote attackers to perform Server-Side Request Forgery (SSRF) attacks, gaining unauthorized access to arbitrary system files and uncovering the internal network topology.
{
"affected": [],
"aliases": [
"CVE-2023-37290"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-20T11:15:10Z",
"severity": "HIGH"
},
"details": "\nInfoDoc Document On-line Submission and Approval System lacks sufficient restrictions on the available tags within its HTML to PDF conversion function, and allowing an unauthenticated attackers to load remote or local resources through HTML tags such as iframe. This vulnerability allows unauthenticated remote attackers to perform Server-Side Request Forgery (SSRF) attacks, gaining unauthorized access to arbitrary system files and uncovering the internal network topology.\n\n",
"id": "GHSA-cjw6-fcr4-7qrh",
"modified": "2024-04-04T06:17:37Z",
"published": "2023-07-20T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37290"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7226-12195-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CM65-67CQ-FQ4V
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35The Canto plugin 1.3.0 for WordPress contains a blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/detail.php?subdomain=SSRF.
{
"affected": [],
"aliases": [
"CVE-2020-28976"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-30T14:15:00Z",
"severity": "MODERATE"
},
"details": "The Canto plugin 1.3.0 for WordPress contains a blind SSRF vulnerability. It allows an unauthenticated attacker can make a request to any internal and external server via /includes/lib/detail.php?subdomain=SSRF.",
"id": "GHSA-cm65-67cq-fq4v",
"modified": "2022-05-24T17:35:15Z",
"published": "2022-05-24T17:35:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28976"
},
{
"type": "WEB",
"url": "https://gist.github.com/p4nk4jv/87aebd999ce4b28063943480e95fd9e0"
},
{
"type": "WEB",
"url": "https://github.com/CantoDAM/Canto-Wordpress-Plugin"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/canto/#developers"
},
{
"type": "WEB",
"url": "https://www.canto.com/integrations/wordpress"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160358/WordPress-Canto-1.3.0-Server-Side-Request-Forgery.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-CMCR-Q4JF-P6Q9
Vulnerability from github – Published: 2026-04-08 00:08 – Updated: 2026-04-08 00:08Summary
The fix for CVE-2026-27732 is incomplete.
objects/aVideoEncoder.json.php still allows attacker-controlled downloadURL values with common media or archive extensions such as .mp4, .mp3, .zip, .jpg, .png, .gif, and .webm to bypass SSRF validation. The server then fetches the response and stores it as media content.
This allows an authenticated uploader to turn the upload-by-URL flow into a reliable SSRF response-exfiltration primitive.
Details
objects/aVideoEncoder.json.php accepts attacker-controlled downloadURL and passes it to downloadVideoFromDownloadURL().
Inside that function:
- the URL extension is extracted from the attacker-controlled path
- the extension is checked against an allowlist of normal encoder formats
isSSRFSafeURL()is skipped for common media and archive extensions- the URL is fetched via
url_get_contents() - the fetched body is written into video storage and exposed through normal media metadata
The current code still contains:
- an extension-based bypass for SSRF validation
- no mandatory initial-destination SSRF enforcement inside
url_get_contents()itself
This means internal URLs such as:
http://127.0.0.1:9998/probe.mp4
remain reachable from the application host.
This issue is best described as an incomplete fix / patch bypass of CVE-2026-27732, not a separate unrelated SSRF class.
Proof of concept
- Log in as a low-privilege uploader.
- Start an HTTP service reachable only from inside the application environment, for example:
http://127.0.0.1:9998/probe.mp4
- Confirm that the service is not reachable externally.
- Send:
POST /objects/aVideoEncoder.json.php
downloadURL=http://127.0.0.1:9998/probe.mp4
format=mp4
- If needed, replay once against the returned
videos_idwithfirst_request=1so the fetched bytes land in the normal media path. - Query:
GET /objects/videos.json.php?showAll=1
- Recover
videosURL.mp4.url. - Download that media URL and observe that the body matches the internal-only response byte-for-byte.
Impact
An authenticated uploader can make the AVideo server fetch loopback or internal HTTP resources and persist the response as media content by supplying a downloadURL ending in an allowlisted extension such as .mp4, .jpg, .gif, or .zip. Because SSRF validation is skipped for those extensions, the fetched body is stored and later retrievable through the generated /videos/... media URL. Successful exploitation allows internal response exfiltration from private APIs, admin endpoints, or other internal services reachable from the application host.
Recommended fix
- Apply
isSSRFSafeURL()to alldownloadURLinputs regardless of extension - Remove extension-based exceptions from SSRF enforcement
- Move initial-destination SSRF validation into
url_get_contents()so call sites cannot skip it - Avoid storing arbitrary fetched content directly as publicly retrievable media
- Consider restricting upload-by-URL to an explicit allowlist of trusted fetch origins
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "WWBN/AVideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39370"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:08:47Z",
"nvd_published_at": "2026-04-07T20:16:31Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe fix for [CVE-2026-27732](https://github.com/WWBN/AVideo/security/advisories/GHSA-h39h-7cvg-q7j6) is incomplete.\n\n`objects/aVideoEncoder.json.php` still allows attacker-controlled `downloadURL` values with common media or archive extensions such as `.mp4`, `.mp3`, `.zip`, `.jpg`, `.png`, `.gif`, and `.webm` to bypass SSRF validation. The server then fetches the response and stores it as media content.\n\nThis allows an authenticated uploader to turn the upload-by-URL flow into a reliable SSRF response-exfiltration primitive.\n\n## Details\n\n`objects/aVideoEncoder.json.php` accepts attacker-controlled `downloadURL` and passes it to `downloadVideoFromDownloadURL()`.\n\nInside that function:\n\n1. the URL extension is extracted from the attacker-controlled path\n2. the extension is checked against an allowlist of normal encoder formats\n3. `isSSRFSafeURL()` is skipped for common media and archive extensions\n4. the URL is fetched via `url_get_contents()`\n5. the fetched body is written into video storage and exposed through normal media metadata\n\nThe current code still contains:\n\n- an extension-based bypass for SSRF validation\n- no mandatory initial-destination SSRF enforcement inside `url_get_contents()` itself\n\nThis means internal URLs such as:\n\n`http://127.0.0.1:9998/probe.mp4`\n\nremain reachable from the application host.\n\nThis issue is best described as an incomplete fix / patch bypass of `CVE-2026-27732`, not a separate unrelated SSRF class.\n\n## Proof of concept\n\n1. Log in as a low-privilege uploader.\n2. Start an HTTP service reachable only from inside the application environment, for example:\n\n```text\nhttp://127.0.0.1:9998/probe.mp4\n```\n\n3. Confirm that the service is not reachable externally.\n4. Send:\n\n```text\nPOST /objects/aVideoEncoder.json.php\ndownloadURL=http://127.0.0.1:9998/probe.mp4\nformat=mp4\n```\n\n5. If needed, replay once against the returned `videos_id` with `first_request=1` so the fetched bytes land in the normal media path.\n6. Query:\n\n```text\nGET /objects/videos.json.php?showAll=1\n```\n\n7. Recover `videosURL.mp4.url`.\n8. Download that media URL and observe that the body matches the internal-only response byte-for-byte.\n\n## Impact\n\nAn authenticated uploader can make the AVideo server fetch loopback or internal HTTP resources and persist the response as media content by supplying a `downloadURL` ending in an allowlisted extension such as `.mp4`, `.jpg`, `.gif`, or `.zip`. Because SSRF validation is skipped for those extensions, the fetched body is stored and later retrievable through the generated `/videos/...` media URL. Successful exploitation allows internal response exfiltration from private APIs, admin endpoints, or other internal services reachable from the application host.\n\n\n## Recommended fix\n\n- Apply `isSSRFSafeURL()` to all `downloadURL` inputs regardless of extension\n- Remove extension-based exceptions from SSRF enforcement\n- Move initial-destination SSRF validation into `url_get_contents()` so call sites cannot skip it\n- Avoid storing arbitrary fetched content directly as publicly retrievable media\n- Consider restricting upload-by-URL to an explicit allowlist of trusted fetch origins",
"id": "GHSA-cmcr-q4jf-p6q9",
"modified": "2026-04-08T00:08:47Z",
"published": "2026-04-08T00:08:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-cmcr-q4jf-p6q9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39370"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "WWBN AVideo has an Allowlisted downloadURL media extensions bypass SSRF protection and enable internal response exfiltration (Incomplete fix for CVE-2026-27732)"
}
GHSA-CMHJ-WH2F-9CGX
Vulnerability from github – Published: 2026-09-23 18:12 – Updated: 2026-09-23 18:12Summary
9router validates image URLs by resolving the host before fetching, but the later server-side fetch performs a separate DNS resolution. An attacker-controlled DNS name can resolve to a public IP during validation and then rebind to an internal Docker/private IP during the fetch. This allows the server-side image prefetch to reach internal-only HTTP services (SSRF).
Details
- Affected version / commit: 9router
v0.4.80@b282f05. - Reachable through
/v1/chat/completionswith a vision-capable model and animage_urlcontent part. A vision-capable model name is required so the image survives modality stripping and the server-side prefetch is armed. - The provider used in this reproduction is the bundled mock provider — no real API key and no real provider call.
- internal-admin (the SSRF target) is not exposed to the host network; it is reachable only from inside the Docker network.
- rebind-dns behaviour for
rebind.9r.test: - first A response →
1.1.1.1(public) to pass the public-host guard, - second A response →
172.29.0.10(internal-admin) during the fetch. - internal-admin logs
GET /ssrf-markerwithpeer=172.29.0.30(theproxied-routercontainer), proving the server-side fetch landed on the internal service. - mock-provider receives
POST /api/chatand the flow completes withHTTP 200. - Root cause: DNS TOCTOU — the IP is not pinned between the validation resolution (the public-host guard) and the fetch resolution. The guard and the fetch each resolve the hostname independently, so a TTL-0 rebinding authority can return a public IP to the guard and an internal IP to the fetch.
Proof of Concept
This repository is a self-contained Docker Compose reproduction. No real provider is called and no real API key is required.
- Build and start the stack:
bash docker compose up --build - Confirm
internal-adminis unreachable from the host:bash curl -i http://127.0.0.1:18083/ssrf-marker # connection refused / fail docker compose ps # internal-admin has NO host port mapping - Send the request named
POST image-prefetch DNS rebinding triggerfromrequests.http, or with curl:bash curl -i -X POST http://127.0.0.1:18082/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "ollama-local/gemma3", "messages": [{"role":"user","content":[ {"type":"text","text":"reproduction image-prefetch trigger"}, {"type":"image_url","image_url":{"url":"http://rebind.9r.test:8080/ssrf-marker?case=rebind-trigger"}} ]}], "stream": false }'
Impact
- SSRF to internal HTTP services reachable from the 9router host/container.
- Depending on the environment, this can reach cloud metadata endpoints, internal admin panels, or be used for internal service discovery.
- Blind / semi-blind SSRF when the fetched response is not returned to the attacker; an exfil variant (pointing the image at an internal endpoint that returns valid image bytes) can return internal content base64-encoded to the upstream.
- Requires a code path that prefetches/normalizes remote images for vision-capable providers.
- No real credential is needed for the reproduction.
Suggested Fix
- Pin the resolved IP after validation and connect to that IP (resolve once, then reuse the address for the fetch).
- Block private, loopback, link-local, multicast, and cloud-metadata ranges at connect time, not only at validation time.
- Perform DNS resolution and IP checks immediately before the request and against the address actually used to connect.
- Disable redirects, or re-validate every redirect target with the same checks.
- Enforce an allowlist for image-fetch domains where feasible.
- Add a timeout, a response size limit, and a content-type check.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.80"
},
"package": {
"ecosystem": "npm",
"name": "9router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56676"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-23T18:12:28Z",
"nvd_published_at": "2026-07-10T16:16:34Z",
"severity": "HIGH"
},
"details": "## Summary\n\n9router validates image URLs by resolving the host before fetching, but the later\nserver-side fetch performs a separate DNS resolution. An attacker-controlled DNS name can\nresolve to a public IP during validation and then rebind to an internal Docker/private IP\nduring the fetch. This allows the server-side image prefetch to reach internal-only HTTP\nservices (SSRF).\n\n## Details\n\n- **Affected version / commit:** 9router `v0.4.80` @ `b282f05`.\n- **Reachable through** `/v1/chat/completions` with a **vision-capable model** and an\n `image_url` content part. A vision-capable model name is required so the image survives\n modality stripping and the server-side prefetch is armed.\n- The provider used in this reproduction is the bundled **mock provider** \u2014 **no real API\n key and no real provider call**.\n- **internal-admin** (the SSRF target) is **not exposed to the host network**; it is\n reachable only from inside the Docker network.\n- **rebind-dns** behaviour for `rebind.9r.test`:\n - first A response \u2192 `1.1.1.1` (public) to pass the public-host guard,\n - second A response \u2192 `172.29.0.10` (internal-admin) during the fetch.\n- **internal-admin** logs `GET /ssrf-marker` with `peer=172.29.0.30` (the `proxied-router`\n container), proving the server-side fetch landed on the internal service.\n- **mock-provider** receives `POST /api/chat` and the flow completes with `HTTP 200`.\n- **Root cause:** DNS TOCTOU \u2014 the IP is **not pinned** between the validation resolution\n (the public-host guard) and the fetch resolution. The guard and the fetch each resolve the\n hostname independently, so a TTL-0 rebinding authority can return a public IP to the guard\n and an internal IP to the fetch.\n\n## Proof of Concept\n\nThis repository is a self-contained Docker Compose reproduction. No real provider is called\nand no real API key is required.\n\n1. Build and start the stack:\n ```bash\n docker compose up --build\n ```\n2. Confirm `internal-admin` is unreachable from the host:\n ```bash\n curl -i http://127.0.0.1:18083/ssrf-marker # connection refused / fail\n docker compose ps # internal-admin has NO host port mapping\n ```\n3. Send the request named **`POST image-prefetch DNS rebinding trigger`** from\n [`requests.http`](./requests.http), or with curl:\n ```bash\n curl -i -X POST http://127.0.0.1:18082/v1/chat/completions \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"model\": \"ollama-local/gemma3\",\n \"messages\": [{\"role\":\"user\",\"content\":[\n {\"type\":\"text\",\"text\":\"reproduction image-prefetch trigger\"},\n {\"type\":\"image_url\",\"image_url\":{\"url\":\"http://rebind.9r.test:8080/ssrf-marker?case=rebind-trigger\"}}\n ]}],\n \"stream\": false\n }\u0027\n ```\n\n## Impact\n\n- SSRF to internal HTTP services reachable from the 9router host/container.\n- Depending on the environment, this can reach cloud metadata endpoints, internal admin\n panels, or be used for internal service discovery.\n- Blind / semi-blind SSRF when the fetched response is not returned to the attacker; an\n exfil variant (pointing the image at an internal endpoint that returns valid image bytes)\n can return internal content base64-encoded to the upstream.\n- Requires a code path that prefetches/normalizes remote images for vision-capable\n providers.\n- No real credential is needed for the reproduction.\n\n## Suggested Fix\n\n- **Pin the resolved IP** after validation and connect to **that** IP (resolve once, then\n reuse the address for the fetch).\n- Block private, loopback, link-local, multicast, and cloud-metadata ranges **at connect\n time**, not only at validation time.\n- Perform DNS resolution and IP checks immediately before the request and against the\n address actually used to connect.\n- Disable redirects, or re-validate every redirect target with the same checks.\n- Enforce an allowlist for image-fetch domains where feasible.\n- Add a timeout, a response size limit, and a content-type check.",
"id": "GHSA-cmhj-wh2f-9cgx",
"modified": "2026-09-23T18:12:28Z",
"published": "2026-09-23T18:12:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decolua/9router/security/advisories/GHSA-cmhj-wh2f-9cgx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56676"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/commit/c7d07448c58bec1200741de0b73305b860416b82"
},
{
"type": "PACKAGE",
"url": "https://github.com/decolua/9router"
},
{
"type": "WEB",
"url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "9router: Image prefetch DNS rebinding allows SSRF to internal services"
}
GHSA-CMM3-FP9X-P8HX
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-25 21:31In Dradis Community Edition, the ProvidersController and AgentsController gate their admin_required before_action on defined?(Dradis::Pro), a constant that is never defined in CE, so the authorization check is never applied. As a result, any authenticated (non-admin) user can create an AI provider pointing to an arbitrary HTTP/HTTPS address (including internal/link-local hosts such as http://169.254.169.254) and reassign the built-in Roslin agent to use it. When an AI interaction is triggered, the server issues a request to the attacker-supplied URL (server-side request forgery). For non-2xx responses, the target's response body is reflected verbatim to the attacker's browser via ActionCable/Turbo Stream error messages, making the SSRF readable.
{
"affected": [],
"aliases": [
"CVE-2026-79788"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T19:16:55Z",
"severity": "HIGH"
},
"details": "In Dradis Community Edition, the ProvidersController and AgentsController gate their admin_required before_action on `defined?(Dradis::Pro)`, a constant that is never defined in CE, so the authorization check is never applied. As a result, any authenticated (non-admin) user can create an AI provider pointing to an arbitrary HTTP/HTTPS address (including internal/link-local hosts such as http://169.254.169.254) and reassign the built-in Roslin agent to use it. When an AI interaction is triggered, the server issues a request to the attacker-supplied URL (server-side request forgery). For non-2xx responses, the target\u0027s response body is reflected verbatim to the attacker\u0027s browser via ActionCable/Turbo Stream error messages, making the SSRF readable.",
"id": "GHSA-cmm3-fp9x-p8hx",
"modified": "2026-08-25T21:31:30Z",
"published": "2026-08-25T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79788"
},
{
"type": "WEB",
"url": "https://github.com/dradis/dradis-ce/issues/1641"
},
{
"type": "WEB",
"url": "https://github.com/dradis/dradis-ce"
},
{
"type": "WEB",
"url": "https://github.com/dradis/dradis-ce/blob/v5.2.0/engines/dradis-echo/app/controllers/dradis/plugins/echo/providers_controller.rb"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dradis-community-edition-5.1.0-through-5.2.0-server-side-request-forgery-via-unrestricted-ai-provider-address"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-CMRH-WVQ6-WM9R
Vulnerability from github – Published: 2026-05-08 16:59 – Updated: 2026-05-13 13:35Summary
Authenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (N8N_API_URL), and per-request URLs supplied via the x-n8n-url header in multi-tenant HTTP mode.
Impact
A caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel.
- Multi-tenant HTTP deployments where tenants share an
AUTH_TOKEN: any tenant with valid credentials can reach the operator's cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials. - Single-tenant deployments: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM's tool calls can read internal services from the n8n-mcp host.
- Stdio deployments are reachable via the same prompt-injection path.
Patched Versions
Fixed in n8n-mcp@2.50.2.
Note for operators: The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If N8N_API_URL points at http://localhost:5678 (n8n on the same host) or an RFC1918 address (n8n on the same private network), set WEBHOOK_SECURITY_MODE=moderate (allows localhost, still blocks RFC1918 and cloud metadata) or WEBHOOK_SECURITY_MODE=permissive (allows RFC1918 too — only safe on a trusted private network). Default strict is correct for deployments where n8n is reachable at a public hostname.
Workarounds
For deployments that cannot upgrade immediately:
- Restrict network egress from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (
169.254.169.254,169.254.170.2,100.100.100.200,192.0.0.192, and the GCPmetadata.google.internalresolved IP) and any RFC1918 networks the server does not legitimately need to reach. - Run in stdio mode instead of HTTP if the multi-tenant surface is not needed (no shared
AUTH_TOKENto compromise). - Disable workflow management tools via
DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflowif the deployment does not need them.
Credit
Reported by @fg0x0.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "2.18.7"
},
{
"fixed": "2.50.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44694"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T16:59:17Z",
"nvd_published_at": "2026-05-08T20:16:31Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAuthenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (`N8N_API_URL`), and per-request URLs supplied via the `x-n8n-url` header in multi-tenant HTTP mode.\n\n### Impact\n\nA caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel.\n\n- **Multi-tenant HTTP deployments** where tenants share an `AUTH_TOKEN`: any tenant with valid credentials can reach the operator\u0027s cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials.\n- **Single-tenant deployments**: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM\u0027s tool calls can read internal services from the n8n-mcp host.\n- **Stdio deployments** are reachable via the same prompt-injection path.\n\n### Patched Versions\n\nFixed in `n8n-mcp@2.50.2`.\n\n**Note for operators:** The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If `N8N_API_URL` points at `http://localhost:5678` (n8n on the same host) or an RFC1918 address (n8n on the same private network), set `WEBHOOK_SECURITY_MODE=moderate` (allows localhost, still blocks RFC1918 and cloud metadata) or `WEBHOOK_SECURITY_MODE=permissive` (allows RFC1918 too \u2014 only safe on a trusted private network). Default `strict` is correct for deployments where n8n is reachable at a public hostname.\n\n### Workarounds\n\nFor deployments that cannot upgrade immediately:\n\n1. **Restrict network egress** from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (`169.254.169.254`, `169.254.170.2`, `100.100.100.200`, `192.0.0.192`, and the GCP `metadata.google.internal` resolved IP) and any RFC1918 networks the server does not legitimately need to reach.\n2. **Run in stdio mode** instead of HTTP if the multi-tenant surface is not needed (no shared `AUTH_TOKEN` to compromise).\n3. **Disable workflow management tools** via `DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow` if the deployment does not need them.\n\n### Credit\n\nReported by [@fg0x0](https://github.com/fg0x0).",
"id": "GHSA-cmrh-wvq6-wm9r",
"modified": "2026-05-13T13:35:05Z",
"published": "2026-05-08T16:59:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-cmrh-wvq6-wm9r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44694"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/commit/bcaba839409d470abeb4a6ad9b361b553a1098eb"
},
{
"type": "PACKAGE",
"url": "https://github.com/czlonkowski/n8n-mcp"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.50.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "n8n-mcp webhook and API client paths has an authenticated SSRF"
}
GHSA-CMWJ-WRW7-W4JX
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31Server-side request forgery (ssrf) in Microsoft Purview allows an unauthorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-26150"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T22:16:23Z",
"severity": "HIGH"
},
"details": "Server-side request forgery (ssrf) in Microsoft Purview allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-cmwj-wrw7-w4jx",
"modified": "2026-04-24T00:31:51Z",
"published": "2026-04-24T00:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26150"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-26150"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CMX3-J49Q-67WW
Vulnerability from github – Published: 2026-03-13 21:31 – Updated: 2026-03-16 15:30Server-Side Request Forgery (SSRF) vulnerability in MailerPress Team MailerPress mailerpress allows Server Side Request Forgery.This issue affects MailerPress: from n/a through <= 1.4.2.
{
"affected": [],
"aliases": [
"CVE-2026-32353"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-13T19:54:47Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in MailerPress Team MailerPress mailerpress allows Server Side Request Forgery.This issue affects MailerPress: from n/a through \u003c= 1.4.2.",
"id": "GHSA-cmx3-j49q-67ww",
"modified": "2026-03-16T15:30:34Z",
"published": "2026-03-13T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32353"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/mailerpress/vulnerability/wordpress-mailerpress-plugin-1-4-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CMX4-P4V5-HMR5
Vulnerability from github – Published: 2022-02-09 00:46 – Updated: 2022-02-08 22:03Apache Batik is vulnerable to server-side request forgery, caused by improper input validation by the "xlink:href" attributes. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.xmlgraphics:batik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-17566"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-31T20:43:02Z",
"nvd_published_at": "2020-11-12T18:15:00Z",
"severity": "HIGH"
},
"details": "Apache Batik is vulnerable to server-side request forgery, caused by improper input validation by the \"xlink:href\" attributes. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.",
"id": "GHSA-cmx4-p4v5-hmr5",
"modified": "2022-02-08T22:03:08Z",
"published": "2022-02-09T00:46:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17566"
},
{
"type": "WEB",
"url": "https://github.com/apache/xmlgraphics-batik/commit/bc6078ca949039e2076cd08b4cb169c84c1179b1"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/xmlgraphics-batik"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/BATIK-1276"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rab94fe68b180d2e2fba97abf6fe1ec83cff826be25f86cd90f047171%40%3Ccommits.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rab94fe68b180d2e2fba97abf6fe1ec83cff826be25f86cd90f047171@%3Ccommits.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcab14a9ec91aa4c151e0729966282920423eff50a22759fd21db6509%40%3Ccommits.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcab14a9ec91aa4c151e0729966282920423eff50a22759fd21db6509@%3Ccommits.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202401-11"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://xmlgraphics.apache.org/security.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Server-side request forgery (SSRF) in Apache Batik"
}
GHSA-CMXV-7R4V-G73C
Vulnerability from github – Published: 2026-09-14 09:30 – Updated: 2026-09-14 09:30In OpenStack Glance before 32.0.1, the location API does not validate destination hosts when adding an HTTP location to an image. Unlike the web-download import path, the location API only checks the URL scheme and does not apply the import_filtering_opts host restrictions. An authenticated user can add a location pointing to internal endpoints such as the cloud metadata service (169.254.169.254), and retrieve the response by downloading the image data. This affects both the new POST /v2/images/{id}/locations API and the old PATCH API when show_multiple_locations is enabled. Deployments with the HTTP store backend enabled are affected.
{
"affected": [],
"aliases": [
"CVE-2026-71198"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T07:17:16Z",
"severity": "HIGH"
},
"details": "In OpenStack Glance before 32.0.1, the location API does not validate destination hosts when adding an HTTP location to an image. Unlike the web-download import path, the location API only checks the URL scheme and does not apply the import_filtering_opts host restrictions. An authenticated user can add a location pointing to internal endpoints such as the cloud metadata service (169.254.169.254), and retrieve the response by downloading the image data. This affects both the new POST /v2/images/{id}/locations API and the old PATCH API when show_multiple_locations is enabled. Deployments with the HTTP store backend enabled are affected.",
"id": "GHSA-cmxv-7r4v-g73c",
"modified": "2026-09-14T09:30:59Z",
"published": "2026-09-14T09:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71198"
},
{
"type": "WEB",
"url": "https://launchpad.net/bugs/2161330"
},
{
"type": "WEB",
"url": "https://openwall.com/lists/oss-security/2026/09/03/2"
},
{
"type": "WEB",
"url": "https://security.openstack.org/ossa/OSSA-2026-038.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.