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.

6271 vulnerabilities reference this CWE, most recent first.

GHSA-C8M8-4468-H6XX

Vulnerability from github – Published: 2026-04-06 06:30 – Updated: 2026-04-06 06:30
VLAI
Details

A vulnerability was identified in hcengineering Huly Platform 0.7.382. This affects an unknown part of the file server/front/src/index.ts of the component Import Endpoint. Such manipulation leads to server-side request forgery. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5623"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-06T06:16:19Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in hcengineering Huly Platform 0.7.382. This affects an unknown part of the file server/front/src/index.ts of the component Import Endpoint. Such manipulation leads to server-side request forgery. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-c8m8-4468-h6xx",
  "modified": "2026-04-06T06:30:29Z",
  "published": "2026-04-06T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5623"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/785632"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355413"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355413/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-C8QJ-JVPH-XJ8W

Vulnerability from github – Published: 2024-05-31 15:30 – Updated: 2024-05-31 15:30
VLAI
Details

The Auto Featured Image (Auto Post Thumbnail) plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 4.0.0 via the upload_to_library AJAX action. This makes it possible for authenticated attackers, with author-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-7073"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-31T15:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The Auto Featured Image (Auto Post Thumbnail) plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 4.0.0 via the upload_to_library AJAX action. This makes it possible for authenticated attackers, with author-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-c8qj-jvph-xj8w",
  "modified": "2024-05-31T15:30:37Z",
  "published": "2024-05-31T15:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7073"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/auto-post-thumbnail/tags/3.9.18/includes/class-apt.php#L947"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/dc024183-0244-4ef9-9171-057ecd1c3e1d?source=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-C928-5V6M-VM5H

Vulnerability from github – Published: 2025-03-29 00:31 – Updated: 2025-03-31 21:32
VLAI
Details

maccms10 v2025.1000.4047 is vulnerable to Server-Side Request Forgery (SSRF) via the Scheduled Task function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-28089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-28T22:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "maccms10 v2025.1000.4047 is vulnerable to Server-Side Request Forgery (SSRF) via the Scheduled Task function.",
  "id": "GHSA-c928-5v6m-vm5h",
  "modified": "2025-03-31T21:32:45Z",
  "published": "2025-03-29T00:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28089"
    },
    {
      "type": "WEB",
      "url": "https://github.com/magicblack/maccms10/releases/tag/v2025.1000.4047"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/wzer7qxh0vwrf6zq"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C94R-CGJW-F264

Vulnerability from github – Published: 2026-09-27 03:31 – Updated: 2026-09-27 03:31
VLAI
Details

AzuraCast is a self-hosted web radio management suite. In AzuraCast before 0.23.8, the station webhook URL validation in AbstractConnector::getValidUrl() (backend/src/Webhook/Connector/AbstractConnector.php), used by the Generic and Discord webhook connectors, rejects only URLs whose host is a literal link-local IP address (169.254.0.0/16 or fe80::/10). Loopback addresses and RFC1918 private ranges are not rejected, and any non-literal-IP hostname causes the IP parsing call to throw, which skips the check entirely. A user holding only the station-scoped WebHooks permission can therefore configure a webhook pointing at an internal, loopback, or private-network target and cause the server to issue an outbound HTTP POST containing the station's Now Playing data, resulting in server-side request forgery. The PUT /station/{id}/webhook/{id}/test endpoint allows the same low-privileged user to trigger the request on demand. At the time of the advisory no patched version was available.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-100849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T02:17:23Z",
    "severity": "HIGH"
  },
  "details": "AzuraCast is a self-hosted web radio management suite. In AzuraCast before 0.23.8, the station webhook URL validation in AbstractConnector::getValidUrl() (backend/src/Webhook/Connector/AbstractConnector.php), used by the Generic and Discord webhook connectors, rejects only URLs whose host is a literal link-local IP address (169.254.0.0/16 or fe80::/10). Loopback addresses and RFC1918 private ranges are not rejected, and any non-literal-IP hostname causes the IP parsing call to throw, which skips the check entirely. A user holding only the station-scoped WebHooks permission can therefore configure a webhook pointing at an internal, loopback, or private-network target and cause the server to issue an outbound HTTP POST containing the station\u0027s Now Playing data, resulting in server-side request forgery. The PUT /station/{id}/webhook/{id}/test endpoint allows the same low-privileged user to trigger the request on demand. At the time of the advisory no patched version was available.",
  "id": "GHSA-c94r-cgjw-f264",
  "modified": "2026-09-27T03:31:05Z",
  "published": "2026-09-27T03:31:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AzuraCast/AzuraCast/security/advisories/GHSA-3jp3-3wqw-jvw4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100849"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/azuracast-before-0.23.8-ssrf-filter-bypass-via-hostname-and-private-ips"
    }
  ],
  "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-C96R-38GV-GRP4

Vulnerability from github – Published: 2024-07-05 12:31 – Updated: 2024-07-08 19:04
VLAI
Summary
ShopXO Server-Side Request Forgery Vulnerability
Details

A vulnerability was found in ShopXO up to 6.1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file extend/base/Uploader.php. The manipulation of the argument source leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-270367. NOTE: The original disclosure confuses CSRF with SSRF.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopxo/shopxo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "6.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-6524"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-08T19:04:34Z",
    "nvd_published_at": "2024-07-05T12:15:02Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in ShopXO up to 6.1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file `extend/base/Uploader.php`. The manipulation of the argument source leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-270367. NOTE: The original disclosure confuses CSRF with SSRF.",
  "id": "GHSA-c96r-38gv-grp4",
  "modified": "2024-07-08T19:04:34Z",
  "published": "2024-07-05T12:31:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6524"
    },
    {
      "type": "WEB",
      "url": "https://github.com/J1rrY-learn/learn/blob/main/shopxo_ssrf.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gongfuxiang/shopxo"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.270367"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.270367"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.365173"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/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"
    }
  ],
  "summary": "ShopXO Server-Side Request Forgery Vulnerability"
}

GHSA-C996-F546-J683

Vulnerability from github – Published: 2026-10-11 15:31 – Updated: 2026-10-11 15:31
VLAI
Details

LLMGateway through 1.20.0 contains a blind server-side request forgery vulnerability that allows API key holders to reach internal hosts via the video-generation callback_url extension. Attackers can supply loopback, private, or cloud-metadata URLs that deliverWebhook POSTs to without the assertSafeWebhookTarget check, reaching internal services from the worker's network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-108719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-11T13:17:15Z",
    "severity": "MODERATE"
  },
  "details": "LLMGateway through 1.20.0 contains a blind server-side request forgery vulnerability that allows API key holders to reach internal hosts via the video-generation callback_url extension. Attackers can supply loopback, private, or cloud-metadata URLs that deliverWebhook POSTs to without the assertSafeWebhookTarget check, reaching internal services from the worker\u0027s network.",
  "id": "GHSA-c996-f546-j683",
  "modified": "2026-10-11T15:31:03Z",
  "published": "2026-10-11T15:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108719"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theopenco/llmgateway"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theopenco/llmgateway/blob/c84ba987da18edd80358a3450ccaea75c5c67ca8/apps/gateway/src/videos/videos.ts#L374-L383"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theopenco/llmgateway/blob/c84ba987da18edd80358a3450ccaea75c5c67ca8/apps/worker/src/services/video-jobs.ts#L2490-L2499"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theopenco/llmgateway/blob/c84ba987da18edd80358a3450ccaea75c5c67ca8/apps/worker/src/worker.ts#L2961-L2971"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@haind03/theopenco-llmgateway-video-callback-ssrf-no-egress-guard"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/llmgateway-through-1.20.0-blind-ssrf-via-video-generation-callback-url"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/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-C9HR-64H3-GXPC

Vulnerability from github – Published: 2026-07-30 14:48 – Updated: 2026-07-30 14:48
VLAI
Summary
Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation
Details

Summary

The HTTP modules that DO call the SSRF guard (http.get, http.request, http.batch) validate only the initial URL, then issue the request with aiohttp's default allow_redirects=True and perform no per-hop revalidation. An attacker hosts a public URL that 302-redirects to an internal address; the guard passes on the public host and aiohttp transparently follows the redirect into internal space, returning the internal body.

Root Cause

src/core/modules/atomic/http/get.py:116 calls session.get(url, ...) with no allow_redirects argument → aiohttp default True. request.py:60 sets allow_redirects=follow_redirects (default True at :327); batch.py:57 likewise. A repo grep of http/ for on_request_redirect / response.history returns NONE — there is no redirect interception or Location revalidation.

Impact

Full readable SSRF that defeats the primary SSRF control on the very modules that correctly validate. Confidentiality of internal/metadata responses (C:H), S:C.

Proof of Concept

Verified live: http.get with allowlisted base 127.0.0.1 followed a 302 Location: http://127.0.0.2/... (non-allowlisted) and returned INTERNAL-VIA-REDIRECT.

attacker hosts http://attacker.tld/r  ->  302 Location: http://<cloud-metadata-ip>/latest/meta-data/...
execute_module http.get {"url":"http://attacker.tld/r"}

Attack Chain

  1. Entry: execute_module http.get {url:"http://attacker.tld/r"} (attacker 302->internal). Guard: validate_url_with_env_config(url) (get.py:104). Bypass proof: validation runs on attacker.tld (public) → passes; never re-run on the redirect target.
  2. Sink: session.get(url) (get.py:116) — no allow_redirects arg → aiohttp default True. Bypass proof: grep of http/ for on_request_redirect/response.history → NONE.
  3. Impact: aiohttp follows 302 to the internal host; internal body returned (get.py:118).

Bypass Evidence

Live PoC followed a 302 into non-allowlisted loopback and returned the internal marker string. aiohttp ClientSession.get default allow_redirects=True; module never sets it False; no per-hop revalidation exists.

Affected Versions

<= 2.26.6 — get.py:116, request.py:60, batch.py:57 present on latest release tag.

Suggested Fix

Set allow_redirects=False and manually revalidate each Location header through validate_url_with_env_config before following, or cap and re-check every hop.

Credit

Vulnerability discovered by zx (Jace).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.26.6"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "flyto-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.26.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-67424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-30T14:48:16Z",
    "nvd_published_at": "2026-07-29T19:16:51Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nThe HTTP modules that DO call the SSRF guard (`http.get`, `http.request`, `http.batch`) validate only the initial URL, then issue the request with aiohttp\u0027s default `allow_redirects=True` and perform no per-hop revalidation. An attacker hosts a public URL that 302-redirects to an internal address; the guard passes on the public host and aiohttp transparently follows the redirect into internal space, returning the internal body.\n\n## Root Cause\n`src/core/modules/atomic/http/get.py:116` calls `session.get(url, ...)` with no `allow_redirects` argument \u2192 aiohttp default `True`. `request.py:60` sets `allow_redirects=follow_redirects` (default True at :327); `batch.py:57` likewise. A repo grep of `http/` for `on_request_redirect` / `response.history` returns NONE \u2014 there is no redirect interception or Location revalidation.\n\n## Impact\nFull readable SSRF that defeats the primary SSRF control on the very modules that correctly validate. Confidentiality of internal/metadata responses (C:H), S:C.\n\n## Proof of Concept\nVerified live: `http.get` with allowlisted base `127.0.0.1` followed a `302 Location: http://127.0.0.2/...` (non-allowlisted) and returned `INTERNAL-VIA-REDIRECT`.\n```\nattacker hosts http://attacker.tld/r  -\u003e  302 Location: http://\u003ccloud-metadata-ip\u003e/latest/meta-data/...\nexecute_module http.get {\"url\":\"http://attacker.tld/r\"}\n```\n\n## Attack Chain\n1. Entry: `execute_module http.get {url:\"http://attacker.tld/r\"}` (attacker 302-\u003einternal). Guard: `validate_url_with_env_config(url)` (get.py:104). Bypass proof: validation runs on `attacker.tld` (public) \u2192 passes; never re-run on the redirect target.\n2. Sink: `session.get(url)` (get.py:116) \u2014 no `allow_redirects` arg \u2192 aiohttp default True. Bypass proof: grep of `http/` for `on_request_redirect`/`response.history` \u2192 NONE.\n3. Impact: aiohttp follows 302 to the internal host; internal body returned (get.py:118).\n\n## Bypass Evidence\nLive PoC followed a 302 into non-allowlisted loopback and returned the internal marker string. aiohttp `ClientSession.get` default `allow_redirects=True`; module never sets it False; no per-hop revalidation exists.\n\n## Affected Versions\n`\u003c= 2.26.6` \u2014 `get.py:116`, `request.py:60`, `batch.py:57` present on latest release tag.\n\n## Suggested Fix\nSet `allow_redirects=False` and manually revalidate each `Location` header through `validate_url_with_env_config` before following, or cap and re-check every hop.\n\n## Credit\n\nVulnerability discovered by zx (Jace).",
  "id": "GHSA-c9hr-64h3-gxpc",
  "modified": "2026-07-30T14:48:17Z",
  "published": "2026-07-30T14:48:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/security/advisories/GHSA-c9hr-64h3-gxpc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67424"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/commit/0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/flytohub/flyto-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flytohub/flyto-core/releases/tag/v2.26.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flyto2 Core: Guarded HTTP modules follow redirects into internal space without per-hop SSRF revalidation"
}

GHSA-C9JJ-9W3R-2HJ8

Vulnerability from github – Published: 2026-09-26 15:31 – Updated: 2026-09-26 15:31
VLAI
Details

Adminer 4.16.0 through 6.0.1 contain a pre-authentication Server-Side Request Forgery (SSRF) vulnerability in the optional Elasticsearch driver (plugins/drivers/elastic.php), fixed in 6.0.2. Because adminer/include/auth.inc.php invokes Driver::connect() before the login result is validated, an unauthenticated attacker who submits crafted auth[server], auth[username], and auth[password] parameters can cause the Adminer server to issue an HTTP GET request (via get_url()/file_get_contents()) to an arbitrary reachable host and port. The driver validates only general server syntax and does not block loopback, private, link-local, or other reserved addresses; if no port is given it appends the default 9200, and Adminer's generic port check rejects ports below 1024. Selected JSON error fields from non-2xx Elasticsearch-style responses, as well as connection failures, are rendered on the login page, providing a port-scanning oracle and enabling internal network reconnaissance and service fingerprinting. Exploitation requires that the optional Elasticsearch driver be explicitly deployed (e.g., via the adminer/elastic.php template or an adminer_object() configuration; it is not loaded in a default build) and that PHP allow_url_fopen be enabled.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-100696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-26T14:16:54Z",
    "severity": "MODERATE"
  },
  "details": "Adminer 4.16.0 through 6.0.1 contain a pre-authentication Server-Side Request Forgery (SSRF) vulnerability in the optional Elasticsearch driver (plugins/drivers/elastic.php), fixed in 6.0.2. Because adminer/include/auth.inc.php invokes Driver::connect() before the login result is validated, an unauthenticated attacker who submits crafted auth[server], auth[username], and auth[password] parameters can cause the Adminer server to issue an HTTP GET request (via get_url()/file_get_contents()) to an arbitrary reachable host and port. The driver validates only general server syntax and does not block loopback, private, link-local, or other reserved addresses; if no port is given it appends the default 9200, and Adminer\u0027s generic port check rejects ports below 1024. Selected JSON error fields from non-2xx Elasticsearch-style responses, as well as connection failures, are rendered on the login page, providing a port-scanning oracle and enabling internal network reconnaissance and service fingerprinting. Exploitation requires that the optional Elasticsearch driver be explicitly deployed (e.g., via the adminer/elastic.php template or an adminer_object() configuration; it is not loaded in a default build) and that PHP allow_url_fopen be enabled.",
  "id": "GHSA-c9jj-9w3r-2hj8",
  "modified": "2026-09-26T15:31:21Z",
  "published": "2026-09-26T15:31:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vrana/adminer/security/advisories/GHSA-q8h3-4cx4-prgm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100696"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/adminer-before-6.0.2-unauthenticated-ssrf-via-elasticsearch-driver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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-C9QC-5G7M-F8W6

Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15
VLAI
Details

In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-41587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-24T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources.",
  "id": "GHSA-c9qc-5g7m-f8w6",
  "modified": "2022-05-24T19:15:42Z",
  "published": "2022-05-24T19:15:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41587"
    },
    {
      "type": "WEB",
      "url": "https://security.gradle.com/advisory/2021-04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-C9XM-49CP-XCR9

Vulnerability from github – Published: 2026-10-02 16:12 – Updated: 2026-10-02 16:12
VLAI
Summary
rmcp OAuth client fetches server-controlled resource_metadata URLs
Details

Summary

The rmcp OAuth client accepts a server-controlled resource_metadata= URL from the WWW-Authenticate header and fetches it without same-origin or private-network validation.

An attacker-controlled MCP server can return a 401 WWW-Authenticate: Bearer resource_metadata="..." header pointing at an internal URL, including localhost, RFC 1918 addresses, or cloud metadata endpoints. The client then performs an outbound GET to that URL from the victim application's network context.

Affected version

  • Repository: modelcontextprotocol/rust-sdk
  • Crate: rmcp
  • Current main reviewed: c330fede90e4729c234f8e87fdbc5ea27a1dd10c
  • Commit date: 2026-05-19
  • Affected file: crates/rmcp/src/transport/auth.rs
  • File blob: 3aa3e91310662c409af9dc38c9d584d6df217e9c
  • Severity framing: High/Medium SSRF, depending on the embedding application's network position and whether response parsing gives the attacker useful success/failure or chained fetch behavior.

Source evidence

extract_www_authenticate_params() accepts an absolute URL from the server-controlled header:

let resource_key = "resource_metadata=";
while let Some(pos) = header_lowercase[search_offset..].find(resource_key) {
    let global_pos = search_offset + pos + resource_key.len();
    let value_slice = &header[global_pos..];
    if let Some((value, consumed)) = Self::parse_next_header_value(value_slice) {
        if let Ok(url) = Url::parse(&value) {
            params.resource_metadata_url = Some(url);
            break;
        }
        if let Ok(url) = base_url.join(&value) {
            params.resource_metadata_url = Some(url);
            break;
        }

There is no check that the parsed URL shares origin with the original MCP server, and no block for loopback, link-local, RFC 1918, or metadata hostnames.

fetch_resource_metadata_from_url() then performs the GET:

let response = match self
    .http_client
    .get(resource_metadata_url.clone())
    .header(HEADER_MCP_PROTOCOL_VERSION, "2024-11-05")
    .send()
    .await

Again, there is no same-origin, scheme, host, DNS, or IP-range validation before the request.

Attack scenario

  1. A Rust MCP client using rmcp connects to an attacker-controlled MCP server, or to a compromised MCP server.
  2. The server responds to OAuth discovery with a 401 and a WWW-Authenticate header such as:
WWW-Authenticate: Bearer resource_metadata="http://169.254.169.254/latest/meta-data/"
  1. The client parses the resource_metadata value as a URL.
  2. The client sends a GET request to that URL from the victim application's network context.

This can be used to probe internal services. In environments where the target endpoint returns JSON matching the expected metadata shape, the flow can also chain into additional authorization-server metadata fetches.

Impact

The direct impact is SSRF from any application embedding the rmcp OAuth client. Depending on where the client runs, this can reach:

  • cloud metadata endpoints;
  • localhost-only services;
  • private VPC or container-network services;
  • internal HTTP APIs not reachable from the attacker.

The attacker controls the URL through the MCP server response. The victim only needs to connect to the attacker's MCP server or a compromised server that can emit the crafted WWW-Authenticate header.

Public duplicate check

On 2026-05-27:

  • Visible repository advisories were:
  • GHSA-9g45-5xwm-f3wc: custom HTTP headers leak to cross-origin redirect targets.
  • GHSA-89vp-x53w-74fx: DNS rebinding in Streamable HTTP server transport.
  • Public issue search for WWW-Authenticate resource_metadata SSRF returned no open or closed matches.
  • Public issue search for resource_metadata returned one closed implementation issue, #517, about authorization discovery fallback behavior, not SSRF/resource validation.

This report is distinct from the redirect-header advisory and the DNS-rebinding advisory.

Suggested fix

Before accepting or fetching a resource_metadata URL:

  • require the URL to be same-origin with the original MCP server URL, unless the spec intentionally permits a narrow trusted exception;
  • reject loopback, link-local, RFC 1918, unique-local IPv6, and known cloud metadata hostnames;
  • reject non-HTTP(S) schemes;
  • apply the same validation to redirect targets and any follow-on metadata URLs.

A minimal same-origin check would compare scheme, host, and effective port:

fn is_same_origin(base: &Url, candidate: &Url) -> bool {
    base.scheme() == candidate.scheme()
        && base.host() == candidate.host()
        && base.port_or_known_default() == candidate.port_or_known_default()
}

If cross-origin resource_metadata is required for compatibility, it should be explicitly opted into and protected by private-network blocking.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T16:12:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `rmcp` OAuth client accepts a server-controlled `resource_metadata=` URL from the `WWW-Authenticate` header and fetches it without same-origin or private-network validation.\n\nAn attacker-controlled MCP server can return a `401 WWW-Authenticate: Bearer resource_metadata=\"...\"` header pointing at an internal URL, including localhost, RFC 1918 addresses, or cloud metadata endpoints. The client then performs an outbound GET to that URL from the victim application\u0027s network context.\n\n## Affected version\n\n- Repository: `modelcontextprotocol/rust-sdk`\n- Crate: `rmcp`\n- Current `main` reviewed: `c330fede90e4729c234f8e87fdbc5ea27a1dd10c`\n- Commit date: 2026-05-19\n- Affected file: `crates/rmcp/src/transport/auth.rs`\n- File blob: `3aa3e91310662c409af9dc38c9d584d6df217e9c`\n- Severity framing: High/Medium SSRF, depending on the embedding application\u0027s network position and whether response parsing gives the attacker useful success/failure or chained fetch behavior.\n\n## Source evidence\n\n`extract_www_authenticate_params()` accepts an absolute URL from the server-controlled header:\n\n```rust\nlet resource_key = \"resource_metadata=\";\nwhile let Some(pos) = header_lowercase[search_offset..].find(resource_key) {\n    let global_pos = search_offset + pos + resource_key.len();\n    let value_slice = \u0026header[global_pos..];\n    if let Some((value, consumed)) = Self::parse_next_header_value(value_slice) {\n        if let Ok(url) = Url::parse(\u0026value) {\n            params.resource_metadata_url = Some(url);\n            break;\n        }\n        if let Ok(url) = base_url.join(\u0026value) {\n            params.resource_metadata_url = Some(url);\n            break;\n        }\n```\n\nThere is no check that the parsed URL shares origin with the original MCP server, and no block for loopback, link-local, RFC 1918, or metadata hostnames.\n\n`fetch_resource_metadata_from_url()` then performs the GET:\n\n```rust\nlet response = match self\n    .http_client\n    .get(resource_metadata_url.clone())\n    .header(HEADER_MCP_PROTOCOL_VERSION, \"2024-11-05\")\n    .send()\n    .await\n```\n\nAgain, there is no same-origin, scheme, host, DNS, or IP-range validation before the request.\n\n## Attack scenario\n\n1. A Rust MCP client using `rmcp` connects to an attacker-controlled MCP server, or to a compromised MCP server.\n2. The server responds to OAuth discovery with a `401` and a `WWW-Authenticate` header such as:\n\n```text\nWWW-Authenticate: Bearer resource_metadata=\"http://169.254.169.254/latest/meta-data/\"\n```\n\n3. The client parses the `resource_metadata` value as a URL.\n4. The client sends a GET request to that URL from the victim application\u0027s network context.\n\nThis can be used to probe internal services. In environments where the target endpoint returns JSON matching the expected metadata shape, the flow can also chain into additional authorization-server metadata fetches.\n\n## Impact\n\nThe direct impact is SSRF from any application embedding the rmcp OAuth client. Depending on where the client runs, this can reach:\n\n- cloud metadata endpoints;\n- localhost-only services;\n- private VPC or container-network services;\n- internal HTTP APIs not reachable from the attacker.\n\nThe attacker controls the URL through the MCP server response. The victim only needs to connect to the attacker\u0027s MCP server or a compromised server that can emit the crafted `WWW-Authenticate` header.\n\n## Public duplicate check\n\nOn 2026-05-27:\n\n- Visible repository advisories were:\n  - `GHSA-9g45-5xwm-f3wc`: custom HTTP headers leak to cross-origin redirect targets.\n  - `GHSA-89vp-x53w-74fx`: DNS rebinding in Streamable HTTP server transport.\n- Public issue search for `WWW-Authenticate resource_metadata SSRF` returned no open or closed matches.\n- Public issue search for `resource_metadata` returned one closed implementation issue, `#517`, about authorization discovery fallback behavior, not SSRF/resource validation.\n\nThis report is distinct from the redirect-header advisory and the DNS-rebinding advisory.\n\n## Suggested fix\n\nBefore accepting or fetching a `resource_metadata` URL:\n\n- require the URL to be same-origin with the original MCP server URL, unless the spec intentionally permits a narrow trusted exception;\n- reject loopback, link-local, RFC 1918, unique-local IPv6, and known cloud metadata hostnames;\n- reject non-HTTP(S) schemes;\n- apply the same validation to redirect targets and any follow-on metadata URLs.\n\nA minimal same-origin check would compare scheme, host, and effective port:\n\n```rust\nfn is_same_origin(base: \u0026Url, candidate: \u0026Url) -\u003e bool {\n    base.scheme() == candidate.scheme()\n        \u0026\u0026 base.host() == candidate.host()\n        \u0026\u0026 base.port_or_known_default() == candidate.port_or_known_default()\n}\n```\n\nIf cross-origin `resource_metadata` is required for compatibility, it should be explicitly opted into and protected by private-network blocking.",
  "id": "GHSA-c9xm-49cp-xcr9",
  "modified": "2026-10-02T16:12:31Z",
  "published": "2026-10-02T16:12:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-c9xm-49cp-xcr9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/pull/935"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/commit/eb435c6f51864df74926ef115befce55c16b01ba"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/rust-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/rust-sdk/releases/tag/rmcp-v2.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "rmcp OAuth client fetches server-controlled resource_metadata 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.