CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
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:30A 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.
{
"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:30The 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.
{
"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:32maccms10 v2025.1000.4047 is vulnerable to Server-Side Request Forgery (SSRF) via the Scheduled Task function.
{
"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:31AzuraCast 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.
{
"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:04A 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.
{
"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:31LLMGateway 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.
{
"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:48Summary
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
- 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 onattacker.tld(public) → passes; never re-run on the redirect target. - Sink:
session.get(url)(get.py:116) — noallow_redirectsarg → aiohttp default True. Bypass proof: grep ofhttp/foron_request_redirect/response.history→ NONE. - 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).
{
"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:31Adminer 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.
{
"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:15In Gradle Enterprise before 2021.1.3, an attacker with the ability to perform SSRF attacks can potentially discover credentials for other resources.
{
"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:12Summary
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
mainreviewed: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
- A Rust MCP client using
rmcpconnects to an attacker-controlled MCP server, or to a compromised MCP server. - The server responds to OAuth discovery with a
401and aWWW-Authenticateheader such as:
WWW-Authenticate: Bearer resource_metadata="http://169.254.169.254/latest/meta-data/"
- The client parses the
resource_metadatavalue as a URL. - 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 SSRFreturned no open or closed matches. - Public issue search for
resource_metadatareturned 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.
{
"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.