Common Weakness Enumeration

CWE-918

Allowed

Server-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:17
VLAI
Details

InfoDoc 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.

Show details on source website

{
  "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:35
VLAI
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.

Show details on source website

{
  "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:08
VLAI
Summary
WWBN AVideo has an Allowlisted downloadURL media extensions bypass SSRF protection and enable internal response exfiltration (Incomplete fix for CVE-2026-27732)
Details

Summary

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:

  1. the URL extension is extracted from the attacker-controlled path
  2. the extension is checked against an allowlist of normal encoder formats
  3. isSSRFSafeURL() is skipped for common media and archive extensions
  4. the URL is fetched via url_get_contents()
  5. 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

  1. Log in as a low-privilege uploader.
  2. Start an HTTP service reachable only from inside the application environment, for example:
http://127.0.0.1:9998/probe.mp4
  1. Confirm that the service is not reachable externally.
  2. Send:
POST /objects/aVideoEncoder.json.php
downloadURL=http://127.0.0.1:9998/probe.mp4
format=mp4
  1. If needed, replay once against the returned videos_id with first_request=1 so the fetched bytes land in the normal media path.
  2. Query:
GET /objects/videos.json.php?showAll=1
  1. Recover videosURL.mp4.url.
  2. 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 all downloadURL inputs 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
Show details on source website

{
  "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:12
VLAI
Summary
9router: Image prefetch DNS rebinding allows SSRF to internal services
Details

Summary

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/completions with a vision-capable model and an image_url content 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-marker with peer=172.29.0.30 (the proxied-router container), proving the server-side fetch landed on the internal service.
  • mock-provider receives POST /api/chat and the flow completes with HTTP 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.

  1. Build and start the stack: bash docker compose up --build
  2. Confirm internal-admin is 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
  3. Send the request named POST image-prefetch DNS rebinding trigger from requests.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.
Show details on source website

{
  "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:31
VLAI
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's response body is reflected verbatim to the attacker's browser via ActionCable/Turbo Stream error messages, making the SSRF readable.

Show details on source website

{
  "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:35
VLAI
Summary
n8n-mcp webhook and API client paths has an authenticated SSRF
Details

Summary

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:

  1. 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.
  2. Run in stdio mode instead of HTTP if the multi-tenant surface is not needed (no shared AUTH_TOKEN to compromise).
  3. Disable workflow management tools via DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow if the deployment does not need them.

Credit

Reported by @fg0x0.

Show details on source website

{
  "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:31
VLAI
Details

Server-side request forgery (ssrf) in Microsoft Purview allows an unauthorized attacker to elevate privileges over a network.

Show details on source website

{
  "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:30
VLAI
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 <= 1.4.2.

Show details on source website

{
  "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:03
VLAI
Summary
Server-side request forgery (SSRF) in Apache Batik
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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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.