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.
4747 vulnerabilities reference this CWE, most recent first.
GHSA-HQ39-787X-5F6Q
Vulnerability from github – Published: 2025-09-17 15:30 – Updated: 2025-09-17 18:31WonderCMS 3.5.0 is vulnerable to Server-Side Request Forgery (SSRF) in the custom module installation functionality. An authenticated administrator can supply a malicious URL via the pluginThemeUrl POST parameter. The server fetches the provided URL using curl_exec() without sufficient validation, allowing the attacker to force internal or external HTTP requests.
{
"affected": [],
"aliases": [
"CVE-2025-57055"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-17T15:15:43Z",
"severity": "MODERATE"
},
"details": "WonderCMS 3.5.0 is vulnerable to Server-Side Request Forgery (SSRF) in the custom module installation functionality. An authenticated administrator can supply a malicious URL via the pluginThemeUrl POST parameter. The server fetches the provided URL using curl_exec() without sufficient validation, allowing the attacker to force internal or external HTTP requests.",
"id": "GHSA-hq39-787x-5f6q",
"modified": "2025-09-17T18:31:17Z",
"published": "2025-09-17T15:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57055"
},
{
"type": "WEB",
"url": "https://github.com/thawphone/CVE-2025-57055"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ3C-7R96-PF8G
Vulnerability from github – Published: 2026-05-28 06:31 – Updated: 2026-05-28 06:31The Independent Analytics plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.14.9. This is due to a public tracking route at /wp-json/iawp/search that accepts attacker-controlled referrer_url values when the signature matches, combined with a scheduled favicon fetcher that performs unrestricted cURL requests to stored domains. The signature validation is insufficient because the signature is embedded in publicly-accessible JavaScript and the salt is static per site, allowing attackers to extract valid signatures. The favicon downloader uses raw cURL functions without any SSRF protection mechanisms (no localhost blocking, no private network filtering, and does not use WordPress's wp_safe_remote_* functions). This makes it possible for unauthenticated attackers to inject malicious referrer domains into the database and trigger server-side requests to arbitrary hosts including internal services.
{
"affected": [],
"aliases": [
"CVE-2026-5737"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T05:16:38Z",
"severity": "MODERATE"
},
"details": "The Independent Analytics plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.14.9. This is due to a public tracking route at /wp-json/iawp/search that accepts attacker-controlled referrer_url values when the signature matches, combined with a scheduled favicon fetcher that performs unrestricted cURL requests to stored domains. The signature validation is insufficient because the signature is embedded in publicly-accessible JavaScript and the salt is static per site, allowing attackers to extract valid signatures. The favicon downloader uses raw cURL functions without any SSRF protection mechanisms (no localhost blocking, no private network filtering, and does not use WordPress\u0027s wp_safe_remote_* functions). This makes it possible for unauthenticated attackers to inject malicious referrer domains into the database and trigger server-side requests to arbitrary hosts including internal services.",
"id": "GHSA-hq3c-7r96-pf8g",
"modified": "2026-05-28T06:31:08Z",
"published": "2026-05-28T06:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5737"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/tags/2.14.4/IAWP/Favicon/FaviconDownloader.php#L57"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/tags/2.14.4/IAWP/FetchFaviconsJob.php#L27"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/tags/2.14.4/IAWP/REST_API.php#L409"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/tags/2.14.4/IAWP/Views/View.php#L252"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/trunk/IAWP/Favicon/FaviconDownloader.php#L57"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/trunk/IAWP/FetchFaviconsJob.php#L27"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/trunk/IAWP/REST_API.php#L409"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/independent-analytics/trunk/IAWP/Views/View.php#L252"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3537814%40independent-analytics\u0026new=3537814%40independent-analytics\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/06ecc40c-6a63-4354-9f49-1925896622f5?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ62-8562-72XH
Vulnerability from github – Published: 2026-07-03 21:31 – Updated: 2026-07-03 21:31Server-side request forgery (ssrf) in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.
{
"affected": [],
"aliases": [
"CVE-2026-57993"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T21:17:02Z",
"severity": "HIGH"
},
"details": "Server-side request forgery (ssrf) in Microsoft Edge (Chromium-based) allows an unauthorized attacker to perform spoofing over a network.",
"id": "GHSA-hq62-8562-72xh",
"modified": "2026-07-03T21:31:39Z",
"published": "2026-07-03T21:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57993"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-57993"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ7J-8QV3-MMRM
Vulnerability from github – Published: 2022-05-14 01:33 – Updated: 2022-05-14 01:33The MailConnect feature on D-Link Central WiFiManager CWM-100 1.03 r0098 devices is intended to check a connection to an SMTP server but actually allows outbound TCP to any port on any IP address, leading to SSRF, as demonstrated by an index.php/System/MailConnect/host/127.0.0.1/port/22/secure/ URI.
{
"affected": [],
"aliases": [
"CVE-2018-15517"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-31T19:29:00Z",
"severity": "HIGH"
},
"details": "The MailConnect feature on D-Link Central WiFiManager CWM-100 1.03 r0098 devices is intended to check a connection to an SMTP server but actually allows outbound TCP to any port on any IP address, leading to SSRF, as demonstrated by an index.php/System/MailConnect/host/127.0.0.1/port/22/secure/ URI.",
"id": "GHSA-hq7j-8qv3-mmrm",
"modified": "2022-05-14T01:33:05Z",
"published": "2022-05-14T01:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15517"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/150243/D-LINK-Central-WifiManager-CWM-100-1.03-r0098-Server-Side-Request-Forgery.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2018/Nov/28"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQ8W-9W8W-PMX7
Vulnerability from github – Published: 2023-09-06 20:51 – Updated: 2023-09-07 21:26Impact
WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. Documentation.
Until WireMock Webhooks Extension 3.0.0-beta-15, the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the limitProxyTargets settings.
Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passing a token, discovered using another exploit, via authentication headers.
Affected components
- WireMock Webhooks Extension 2.x versions until 2.35.1 (security patch)
- WireMock 3.x version until 3.0.3 (security patch)
- All versions of WireMock Studio (discontinued). This distribution bundles the WireMock Webhooks Extension and activates it by default
Patches and Mitigation
- For WireMock 2.x and 3.x - upgrade to the versions with the security patches
- Setup network restrictions similarly to https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses
- For WireMock Studio: Stop using discontinued WireMock Studio, migrate to other distributions. The vendor of WireMock Studio recommends migration to WireMock Cloud
NOTE: It was confirmed that WireMock Cloud does not expose sensitive internal APIs and hence not vulnerable to the issue. No action is needed if you use this SaaS distribution.
Workarounds
- Use external firewall rules to define the list of permitted destinations
References
Credits
- @W0rty for reporting CVE-2023-39967 in WireMock Studio
- WireMock Inc. team for discovering similar exploits in Webhooks and the risk in the Proxy mode defaults for WireMock
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock-webhooks-extension"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.0.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.wiremock:wiremock-webhooks-extension"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.35.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41327"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-06T20:51:42Z",
"nvd_published_at": "2023-09-06T21:15:14Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. [Documentation](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). \n\nUntil WireMock Webhooks Extension [3.0.0-beta-15](https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15), the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. \n\nVia the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock\u2019s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passing a token, discovered using another exploit, via authentication headers.\n\n### Affected components\n\n- WireMock Webhooks Extension 2.x versions until 2.35.1 (security patch)\n- WireMock 3.x version until 3.0.3 (security patch)\n- All versions of WireMock Studio (discontinued). This distribution bundles the WireMock Webhooks Extension and activates it by default\n\n### Patches and Mitigation\n\n- For WireMock 2.x and 3.x - upgrade to the versions with the security patches\n- Setup network restrictions similarly to https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses \n- For WireMock Studio: Stop using discontinued WireMock Studio, migrate to other distributions. The vendor of WireMock Studio recommends migration to [WireMock Cloud](https://www.wiremock.io/product)\n\nNOTE: It was confirmed that [WireMock Cloud](https://www.wiremock.io/product) does not expose sensitive internal APIs and hence not vulnerable to the issue. No action is needed if you use this SaaS distribution.\n\n### Workarounds\n\n- Use external firewall rules to define the list of permitted destinations\n\n### References\n\n- CVE-2023-39967\n- [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses)\n\n### Credits\n\n- @W0rty for reporting CVE-2023-39967 in WireMock Studio\n- WireMock Inc. team for discovering similar exploits in Webhooks and the risk in the Proxy mode defaults for WireMock\n\n",
"id": "GHSA-hq8w-9w8w-pmx7",
"modified": "2023-09-07T21:26:41Z",
"published": "2023-09-06T20:51:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/security/advisories/GHSA-hq8w-9w8w-pmx7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41327"
},
{
"type": "PACKAGE",
"url": "https://github.com/wiremock/wiremock"
},
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/releases/tag/2.35.1"
},
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15"
},
{
"type": "WEB",
"url": "https://github.com/wiremock/wiremock/releases/tag/3.0.3"
},
{
"type": "WEB",
"url": "https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "WireMock Controlled Server Side Request Forgery vulnerability through URL"
}
GHSA-HQHP-CMJH-X8Q9
Vulnerability from github – Published: 2024-06-14 06:34 – Updated: 2024-06-14 06:34The ElementsKit PRO plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 3.6.2 via the 'render_raw' function. This can allow authenticated attackers, with contributor-level permissions 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-2024-4404"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-14T06:15:12Z",
"severity": "HIGH"
},
"details": "The ElementsKit PRO plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 3.6.2 via the \u0027render_raw\u0027 function. This can allow authenticated attackers, with contributor-level permissions 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-hqhp-cmjh-x8q9",
"modified": "2024-06-14T06:34:49Z",
"published": "2024-06-14T06:34:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4404"
},
{
"type": "WEB",
"url": "https://wpmet.com/plugin/elementskit/roadmaps"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/6417269d-3d49-4f33-b92a-5aacb052bab0?source=cve"
}
],
"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"
}
]
}
GHSA-HQPJ-XX46-MWVH
Vulnerability from github – Published: 2024-09-17 21:30 – Updated: 2024-09-17 21:30An 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.
{
"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:00This 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.
{
"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** 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.
{
"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:46Summary
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
createRequestfunction 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
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();
});
-
When tryint to access
/adminthe attacker is naturally redirected :sh curl -i http://localhost:4321/admin -
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
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 :
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
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:
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:
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:
empty
x-forwarded-host + the target host in the path
Credits
- Allam Rachid (zhero;)
- Allam Yasser (inzo)
{
"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"
}
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.