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.
6670 vulnerabilities reference this CWE, most recent first.
GHSA-F37M-QRRX-WW7W
Vulnerability from github – Published: 2026-10-10 15:30 – Updated: 2026-10-10 15:30Kortix Suna 0.10.7 before 0.13.52 contains a server-side request forgery vulnerability that allows project managers to bypass the isPrivateIp guard by supplying IPv6 6to4 or Teredo addresses that embed private IPv4 destinations. Attackers holding project.connector.write can set connector base_url, OpenAPI, Postman, or MCP URLs to reach internal services and cloud metadata endpoints and read responses.
{
"affected": [],
"aliases": [
"CVE-2026-108115"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-10T15:16:57Z",
"severity": "LOW"
},
"details": "Kortix Suna 0.10.7 before 0.13.52 contains a server-side request forgery vulnerability that allows project managers to bypass the isPrivateIp guard by supplying IPv6 6to4 or Teredo addresses that embed private IPv4 destinations. Attackers holding project.connector.write can set connector base_url, OpenAPI, Postman, or MCP URLs to reach internal services and cloud metadata endpoints and read responses.",
"id": "GHSA-f37m-qrrx-ww7w",
"modified": "2026-10-10T15:30:23Z",
"published": "2026-10-10T15:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108115"
},
{
"type": "WEB",
"url": "https://github.com/kortix-ai/suna/commit/9c949e4d876cd5acf7b23b0a9ee49ca5c53f1332"
},
{
"type": "WEB",
"url": "https://github.com/kortix-ai/suna"
},
{
"type": "WEB",
"url": "https://github.com/kortix-ai/suna/blob/v0.13.45/apps/api/src/shared/ssrf-guard.ts#L98-L113"
},
{
"type": "WEB",
"url": "https://github.com/kortix-ai/suna/releases/tag/v0.13.52"
},
{
"type": "WEB",
"url": "https://hackmd.io/@haind/suna-ssrf-6to4-guard-bypass"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/kortix-suna-0.10.7-before-0.13.52-ssrf-guard-bypass-via-ipv6-6to4-addresses"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/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-F3C6-J4CC-HQC4
Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-05-24 17:49A remote server side request forgery (SSRF) remote code execution vulnerability was discovered in Aruba ClearPass Policy Manager version(s) prior to 6.9.5, 6.8.9, 6.7.14-HF1. Aruba has released patches for Aruba ClearPass Policy Manager that address this security vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-29145"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-29T12:15:00Z",
"severity": "CRITICAL"
},
"details": "A remote server side request forgery (SSRF) remote code execution vulnerability was discovered in Aruba ClearPass Policy Manager version(s) prior to 6.9.5, 6.8.9, 6.7.14-HF1. Aruba has released patches for Aruba ClearPass Policy Manager that address this security vulnerability.",
"id": "GHSA-f3c6-j4cc-hqc4",
"modified": "2022-05-24T17:49:13Z",
"published": "2022-05-24T17:49:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29145"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-009.txt"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F3QF-7C7X-V322
Vulnerability from github – Published: 2026-08-25 18:32 – Updated: 2026-08-30 00:30Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.
{
"affected": [],
"aliases": [
"CVE-2026-76193"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T18:18:04Z",
"severity": "CRITICAL"
},
"details": "Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.",
"id": "GHSA-f3qf-7c7x-v322",
"modified": "2026-08-30T00:30:21Z",
"published": "2026-08-25T18:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76193"
},
{
"type": "WEB",
"url": "https://helpx-internal.corp.adobe.com/content/help/en/security/products/campaign/apsb26-134.html"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/campaign/apsb26-134.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F3QM-VFC3-JG6V
Vulnerability from github – Published: 2024-02-20 18:03 – Updated: 2024-02-20 22:34Impact
The CSRF authenticity token check is currently disabled for the questionnaire templates preview as per: https://github.com/decidim/decidim/blob/3187bdfd40ea1c57c2c12512b09a7fec0b2bed08/decidim-templates/app/controllers/decidim/templates/admin/questionnaire_templates_controller.rb#L11
This was introduced by this commit in the PR that introduced this feature (#6247): https://github.com/decidim/decidim/pull/6247/commits/5542227be66e3b6d7530f5b536069bce09376660
The issue does not imply a serious security thread as you need to have access also to the session cookie in order to see this resource. This URL does not allow modifying the resource but it may allow attackers to gain access to information which was not meant to be public.
Patches
11743
Workarounds
Disable the templates functionality or remove all available templates.
References
11743
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "decidim-templates"
},
"ranges": [
{
"events": [
{
"introduced": "0.23.0"
},
{
"fixed": "0.27.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-47635"
],
"database_specific": {
"cwe_ids": [
"CWE-352",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-20T18:03:12Z",
"nvd_published_at": "2024-02-20T18:15:50Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe CSRF authenticity token check is currently disabled for the questionnaire templates preview as per:\nhttps://github.com/decidim/decidim/blob/3187bdfd40ea1c57c2c12512b09a7fec0b2bed08/decidim-templates/app/controllers/decidim/templates/admin/questionnaire_templates_controller.rb#L11\n\nThis was introduced by this commit in the PR that introduced this feature (#6247):\nhttps://github.com/decidim/decidim/pull/6247/commits/5542227be66e3b6d7530f5b536069bce09376660\n\nThe issue does not imply a serious security thread as you need to have access also to the session cookie in order to see this resource. This URL does not allow modifying the resource but it may allow attackers to gain access to information which was not meant to be public.\n\n### Patches\n#11743\n\n### Workarounds\nDisable the templates functionality or remove all available templates.\n\n### References\n#11743",
"id": "GHSA-f3qm-vfc3-jg6v",
"modified": "2024-02-20T22:34:19Z",
"published": "2024-02-20T18:03:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/security/advisories/GHSA-f3qm-vfc3-jg6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47635"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/pull/11743"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/pull/6247"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/commit/5542227be66e3b6d7530f5b536069bce09376660"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/commit/57a4b467787448307b5d9b01ce6e2c8502e121ac"
},
{
"type": "PACKAGE",
"url": "https://github.com/decidim/decidim"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/blob/3187bdfd40ea1c57c2c12512b09a7fec0b2bed08/decidim-templates/app/controllers/decidim/templates/admin/questionnaire_templates_controller.rb#L11"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/releases/tag/v0.27.5"
},
{
"type": "WEB",
"url": "https://github.com/decidim/decidim/releases/tag/v0.28.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Possible CSRF attack at questionnaire templates preview"
}
GHSA-F3QQ-49M6-RW8F
Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51Summary
The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() in lemur
/certificates/verify.py) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification.
Affected version
Tested against main (the commit that introduced _validate_revocation_url). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in main. Please map the affected range to whichever release will first contain _validate_revocation_url.
Bypass 1 — HTTP redirect (deterministic)
The guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target:
# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))
The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.
Bypass 2 — DNS rebinding / TOCTOU (probabilistic)
The guard resolves once during validation; the fetch re-resolves independently:
# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))
A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).
Relationship to GHSA-54vg-pfh7-jq95
Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.
Affected endpoint
POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).
PoC
- Generate a cert with
crlDistributionPoints = URI:http://attacker.example/crl. - That host returns
302 Location: http://169.254.169.254/latest/meta-data/...(bypass 1), or use a low-TTL rebinding name (bypass 2). - Upload via
POST /api/1/certificates/uploadas an operator user. - Trigger
lemur certificate check_revocation. - Observe the request reach the internal address (
tcpdump -nni any host 169.254.169.254).
Impact
Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.
Remediation
allow_redirects=Falseon CRL fetches (or re-validate every redirect hop).- Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
- Reject names with any internal A/AAAA record.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70667"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-18T20:51:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nThe SSRF mitigation added for GHSA-54vg-pfh7-jq95 (`_validate_revocation_url()` in `lemur\n/certificates/verify.py`) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification.\n\n## Affected version\nTested against `main` (the commit that introduced `_validate_revocation_url`). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in `main`. Please map the affected range to whichever release will first contain `_validate_revocation_url`.\n\n## Bypass 1 \u2014 HTTP redirect (deterministic)\nThe guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target:\n```python\n# lemur/certificates/verify.py:174\nresponse = requests.get(point, timeout=(3.05, 6)) \n```\nThe attacker hosts the CRL URL on a public host they control (passes the guard); that host returns `302 Location: http://169.254.169.254/...`. `requests` follows it to the internal target the guard never inspected.\n\n## Bypass 2 \u2014 DNS rebinding / TOCTOU (probabilistic)\nThe guard resolves once during validation; the fetch re-resolves independently:\n```python\n# lemur/certificates/verify.py:51\naddr = ipaddress.ip_address(socket.gethostbyname(hostname))\n```\n\nA low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (`openssl ocsp -url \u003curl\u003e`, verify.py:90-99).\n\n## Relationship to GHSA-54vg-pfh7-jq95\nIncomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory\u0027s remediation text anticipated (\"pins the resolved IP\") but the code does not implement.\n\n## Affected endpoint\n`POST /api/1/certificates/upload` (operator role) \u2192 verify_string \u2192 crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).\n\n## PoC\n1. Generate a cert with `crlDistributionPoints = URI:http://attacker.example/crl`.\n2. That host returns `302 Location: http://169.254.169.254/latest/meta-data/...` (bypass 1), or use a low-TTL rebinding name (bypass 2).\n3. Upload via `POST /api/1/certificates/upload` as an operator user.\n4. Trigger `lemur certificate check_revocation`.\n5. Observe the request reach the internal address (`tcpdump -nni any host 169.254.169.254`).\n\n\u003cimg width=\"1140\" height=\"277\" alt=\"poc-1\" src=\"https://github.com/user-attachments/assets/f27b9584-b33a-4b9c-b812-8c60302e1892\" /\u003e\n\n## Impact\nBlind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded \u2014 reachability/side-effects, not response exfiltration.\n\n## Remediation\n- `allow_redirects=False` on CRL fetches (or re-validate every redirect hop).\n- Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.\n- Reject names with any internal A/AAAA record.",
"id": "GHSA-f3qq-49m6-rw8f",
"modified": "2026-08-18T20:51:13Z",
"published": "2026-08-18T20:51:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-f3qq-49m6-rw8f"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/commit/ed504a830f38a83825b1570302e9f38d6553938a"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
}
],
"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"
}
],
"summary": "Lemur: SSRF protection in certificate revocation checking bypassable via HTTP redirects and DNS rebinding (incomplete fix for GHSA-54vg-pfh7-jq95)"
}
GHSA-F47C-3C5W-V7P4
Vulnerability from github – Published: 2026-02-17 18:53 – Updated: 2026-02-19 21:29Impact
Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality, but of course it is never intended to let you access "special" targets such as localhost or cloud metadata endpoints.
Patches
You should to update to Indico 3.3.10 as soon as possible. See the docs for instructions on how to update.
Workarounds
If you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn't impact you and you can ignore it (but please upgrade anyway). Also, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.
For additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular http_proxy and https_proxy) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services. Please note that setting up such a proxy is not something we can help you with.
For more information
If you have any questions or comments about this advisory:
- Open a thread in our forum
- Email us privately at indico-team@cern.ch
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "indico"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25738"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-17T18:53:25Z",
"nvd_published_at": "2026-02-19T16:27:15Z",
"severity": "MODERATE"
},
"details": "### Impact\nIndico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico\u0027s functionality, but of course it is never intended to let you access \"special\" targets such as localhost or cloud metadata endpoints.\n\n### Patches\nYou should to update to [Indico 3.3.10](https://github.com/indico/indico/releases/tag/v3.3.10) as soon as possible.\nSee [the docs](https://docs.getindico.io/en/stable/installation/upgrade/) for instructions on how to update.\n\n### Workarounds\nIf you do not have IPs that expose sensitive data without authentication (typically because you do not host Indico on AWS), this vulnerability doesn\u0027t impact you and you can ignore it (but please upgrade anyway).\nAlso, only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. So if you trust your event organizers, the risk is also very limited.\n\nFor additional security, both before and after patching, you could also use the common proxy-related environment variables (in particular `http_proxy` and `https_proxy`) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services. Please note that setting up such a proxy is not something we can help you with.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open a thread in [our forum](https://talk.getindico.io/)\n- Email us privately at [indico-team@cern.ch](mailto:indico-team@cern.ch)",
"id": "GHSA-f47c-3c5w-v7p4",
"modified": "2026-02-19T21:29:46Z",
"published": "2026-02-17T18:53:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/indico/indico/security/advisories/GHSA-f47c-3c5w-v7p4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25738"
},
{
"type": "WEB",
"url": "https://github.com/indico/indico/commit/70d341826116fac5868719a6133f2c26d9345137"
},
{
"type": "PACKAGE",
"url": "https://github.com/indico/indico"
},
{
"type": "WEB",
"url": "https://github.com/indico/indico/releases/tag/v3.3.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Indico has Server-Side Request Forgery (SSRF) in multiple places"
}
GHSA-F48G-5Q5H-XX63
Vulnerability from github – Published: 2023-11-03 06:36 – Updated: 2023-11-10 00:30Bon Presta boninstagramcarousel between v5.2.1 to v7.0.0 was discovered to contain a Server-Side Request Forgery (SSRF) via the url parameter at insta_parser.php. This vulnerability allows attackers to use the vulnerable website as proxy to attack other websites or exfiltrate data via a HTTP call.
{
"affected": [],
"aliases": [
"CVE-2023-43982"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-03T05:15:30Z",
"severity": "CRITICAL"
},
"details": "Bon Presta boninstagramcarousel between v5.2.1 to v7.0.0 was discovered to contain a Server-Side Request Forgery (SSRF) via the url parameter at insta_parser.php. This vulnerability allows attackers to use the vulnerable website as proxy to attack other websites or exfiltrate data via a HTTP call.",
"id": "GHSA-f48g-5q5h-xx63",
"modified": "2023-11-10T00:30:26Z",
"published": "2023-11-03T06:36:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43982"
},
{
"type": "WEB",
"url": "https://security.friendsofpresta.org/modules/2023/11/02/boninstagramcarousel.html"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-F49C-C866-MJCW
Vulnerability from github – Published: 2025-12-24 15:30 – Updated: 2026-04-23 18:32Server-Side Request Forgery (SSRF) vulnerability in bdthemes Prime Slider – Addons For Elementor bdthemes-prime-slider-lite allows Server Side Request Forgery.This issue affects Prime Slider – Addons For Elementor: from n/a through <= 4.0.10.
{
"affected": [],
"aliases": [
"CVE-2025-68500"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-24T13:16:20Z",
"severity": "CRITICAL"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in bdthemes Prime Slider \u2013 Addons For Elementor bdthemes-prime-slider-lite allows Server Side Request Forgery.This issue affects Prime Slider \u2013 Addons For Elementor: from n/a through \u003c= 4.0.10.",
"id": "GHSA-f49c-c866-mjcw",
"modified": "2026-04-23T18:32:01Z",
"published": "2025-12-24T15:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68500"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/bdthemes-prime-slider-lite/vulnerability/wordpress-prime-slider-addons-for-elementor-plugin-4-0-10-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/bdthemes-prime-slider-lite/vulnerability/wordpress-prime-slider-addons-for-elementor-plugin-4-0-10-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"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-F4GW-2P7V-4548
Vulnerability from github – Published: 2026-07-20 22:20 – Updated: 2026-09-01 18:39Summary
Axios versions containing lib/helpers/shouldBypassProxy.js do not treat 0.0.0.0 as a local address when evaluating NO_PROXY rules. In Node.js applications that use HTTP_PROXY or HTTPS_PROXY together with NO_PROXY=localhost,127.0.0.1,::1 or similar, a request to http://0.0.0.0:<port>/ can be routed through the configured proxy instead of bypassing it.
The issue is exploitable when an attacker can influence the axios request URL or a followed redirect target, and when the proxy can reach or relay 0.0.0.0 to local services. This is a Node.js runtime proxy-routing issue, not a browser, install-time, or development-tooling issue.
Impact
Applications are affected when all of the following are true:
- The application runs axios in Node.js with the HTTP adapter.
- The process uses environment proxy variables such as
HTTP_PROXYorHTTPS_PROXY. - The process uses
NO_PROXYentries such aslocalhost,127.0.0.1, or::1to keep local traffic out of the proxy path. - Attacker-controlled input can influence the request URL or redirect target.
- The configured proxy does not reject
0.0.0.0and can reach the local destination.
For plain HTTP targets, the proxy can receive the full request URL, headers, and body, and may be able to observe the local service response. HTTPS targets are less exposed because axios uses CONNECT tunneling in current versions.
Affected Functionality
Affected functionality is limited to environment-derived proxy selection in the Node HTTP adapter:
lib/adapters/http.jscallsgetProxyForUrl(location)and thenshouldBypassProxy(location)before applying the proxy.lib/helpers/shouldBypassProxy.jsnormalizes and comparesNO_PROXYentries.- Explicit caller-provided
config.proxyremains trusted caller configuration. - Browser, React Native, XHR, and fetch adapter behavior are not affected.
Technical Details
lib/helpers/shouldBypassProxy.js defines local loopback equivalence through isLoopback(). The current implementation recognizes localhost, IPv4 127.0.0.0/8, IPv6 ::1, and IPv4-mapped loopback forms, but it does not include 0.0.0.0.
At lib/helpers/shouldBypassProxy.js:176, axios treats two hosts as matching when both are considered loopback:
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
Because isLoopback('0.0.0.0') returns false, NO_PROXY=localhost,127.0.0.1,::1 does not match http://0.0.0.0:<port>/. lib/adapters/http.js:185-193 then applies the environment proxy.
Proof of Concept of Attack
import http from 'http';
import axios from './index.js';
const listen = (handler, host = '127.0.0.1') =>
new Promise((resolve) => {
const server = http.createServer(handler);
server.listen(0, host, () => resolve(server));
});
const close = (server) => new Promise((resolve) => server.close(resolve));
const origin = await listen((req, res) => res.end('origin'), '0.0.0.0');
let proxyRequests = 0;
const proxy = await listen((req, res) => {
proxyRequests += 1;
res.end('proxied');
});
process.env.http_proxy = `http://127.0.0.1:${proxy.address().port}`;
process.env.HTTP_PROXY = process.env.http_proxy;
process.env.no_proxy = 'localhost,127.0.0.1,::1';
process.env.NO_PROXY = process.env.no_proxy;
try {
const direct = await axios.get(`http://127.0.0.1:${origin.address().port}/`);
const zero = await axios.get(`http://0.0.0.0:${origin.address().port}/`);
console.log({ direct: direct.data, zero: zero.data, proxyRequests });
} finally {
await close(origin);
await close(proxy);
}
Expected safe behavior: both 127.0.0.1 and 0.0.0.0 bypass the proxy when the NO_PROXY policy is intended to cover local destinations.
Observed behavior: 127.0.0.1 bypasses the proxy, while 0.0.0.0 is sent through the proxy.
Workarounds
- Add
0.0.0.0explicitly toNO_PROXYwhere local addresses must bypass proxies. - Reject or normalize
0.0.0.0in application URL validation before calling axios. - Set
proxy: falseon axios requests that must never use environment proxies. - Configure the proxy itself to reject
0.0.0.0, loopback, link-local, and internal address ranges.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0.31.0"
},
{
"fixed": "0.33.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67315"
],
"database_specific": {
"cwe_ids": [
"CWE-183",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T22:20:18Z",
"nvd_published_at": "2026-08-06T22:18:25Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nAxios versions containing `lib/helpers/shouldBypassProxy.js` do not treat `0.0.0.0` as a local address when evaluating `NO_PROXY` rules. In Node.js applications that use `HTTP_PROXY` or `HTTPS_PROXY` together with `NO_PROXY=localhost,127.0.0.1,::1` or similar, a request to `http://0.0.0.0:\u003cport\u003e/` can be routed through the configured proxy instead of bypassing it.\n\nThe issue is exploitable when an attacker can influence the axios request URL or a followed redirect target, and when the proxy can reach or relay `0.0.0.0` to local services. This is a Node.js runtime proxy-routing issue, not a browser, install-time, or development-tooling issue.\n\n## Impact\n\nApplications are affected when all of the following are true:\n\n- The application runs axios in Node.js with the HTTP adapter.\n- The process uses environment proxy variables such as `HTTP_PROXY` or `HTTPS_PROXY`.\n- The process uses `NO_PROXY` entries such as `localhost`, `127.0.0.1`, or `::1` to keep local traffic out of the proxy path.\n- Attacker-controlled input can influence the request URL or redirect target.\n- The configured proxy does not reject `0.0.0.0` and can reach the local destination.\n\nFor plain HTTP targets, the proxy can receive the full request URL, headers, and body, and may be able to observe the local service response. HTTPS targets are less exposed because axios uses CONNECT tunneling in current versions.\n\n## Affected Functionality\n\nAffected functionality is limited to environment-derived proxy selection in the Node HTTP adapter:\n\n- `lib/adapters/http.js` calls `getProxyForUrl(location)` and then `shouldBypassProxy(location)` before applying the proxy.\n- `lib/helpers/shouldBypassProxy.js` normalizes and compares `NO_PROXY` entries.\n- Explicit caller-provided `config.proxy` remains trusted caller configuration.\n- Browser, React Native, XHR, and fetch adapter behavior are not affected.\n\n## Technical Details\n\n`lib/helpers/shouldBypassProxy.js` defines local loopback equivalence through `isLoopback()`. The current implementation recognizes `localhost`, IPv4 `127.0.0.0/8`, IPv6 `::1`, and IPv4-mapped loopback forms, but it does not include `0.0.0.0`.\n\nAt `lib/helpers/shouldBypassProxy.js:176`, axios treats two hosts as matching when both are considered loopback:\n\n```js\nreturn hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost));\n```\n\nBecause `isLoopback(\u00270.0.0.0\u0027)` returns `false`, `NO_PROXY=localhost,127.0.0.1,::1` does not match `http://0.0.0.0:\u003cport\u003e/`. `lib/adapters/http.js:185-193` then applies the environment proxy.\n\n## Proof of Concept of Attack\n\n```js\nimport http from \u0027http\u0027;\nimport axios from \u0027./index.js\u0027;\n\nconst listen = (handler, host = \u0027127.0.0.1\u0027) =\u003e\n new Promise((resolve) =\u003e {\n const server = http.createServer(handler);\n server.listen(0, host, () =\u003e resolve(server));\n });\n\nconst close = (server) =\u003e new Promise((resolve) =\u003e server.close(resolve));\n\nconst origin = await listen((req, res) =\u003e res.end(\u0027origin\u0027), \u00270.0.0.0\u0027);\n\nlet proxyRequests = 0;\nconst proxy = await listen((req, res) =\u003e {\n proxyRequests += 1;\n res.end(\u0027proxied\u0027);\n});\n\nprocess.env.http_proxy = `http://127.0.0.1:${proxy.address().port}`;\nprocess.env.HTTP_PROXY = process.env.http_proxy;\nprocess.env.no_proxy = \u0027localhost,127.0.0.1,::1\u0027;\nprocess.env.NO_PROXY = process.env.no_proxy;\n\ntry {\n const direct = await axios.get(`http://127.0.0.1:${origin.address().port}/`);\n const zero = await axios.get(`http://0.0.0.0:${origin.address().port}/`);\n\n console.log({ direct: direct.data, zero: zero.data, proxyRequests });\n} finally {\n await close(origin);\n await close(proxy);\n}\n```\n\nExpected safe behavior: both `127.0.0.1` and `0.0.0.0` bypass the proxy when the `NO_PROXY` policy is intended to cover local destinations.\n\nObserved behavior: `127.0.0.1` bypasses the proxy, while `0.0.0.0` is sent through the proxy.\n\n## Workarounds\n\n- Add `0.0.0.0` explicitly to `NO_PROXY` where local addresses must bypass proxies.\n- Reject or normalize `0.0.0.0` in application URL validation before calling axios.\n- Set `proxy: false` on axios requests that must never use environment proxies.\n- Configure the proxy itself to reject `0.0.0.0`, loopback, link-local, and internal address ranges.\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Report\u003c/summary\u003e\n\n### Summary\n`axios` versions 1.15.0\u20131.16.1 contain an incomplete loopback-address check in `lib/helpers/shouldBypassProxy.js`. The `isLoopback()` function correctly identifies `127.0.0.0/8` and `::1` as loopback addresses but does not recognise `0.0.0.0` \u2014 the IPv4 unspecified address, which routes to the local machine on Linux and macOS.\n\nAn attacker who controls a URL passed to axios can use `http://0.0.0.0/\u003cpath\u003e` to bypass proxy-based SSRF filtering that the application relies upon.\n\n### Details\n## Affected versions\n\n`\u003e= 1.15.0, \u003c= 1.16.1`\n\nThe vulnerability was introduced in v1.15.0 when the `shouldBypassProxy` helper was added as a security improvement (PR #10661).\n\n---\n\n## Root cause\n\n**File:** `lib/helpers/shouldBypassProxy.js`\n\n```javascript\n// Line 1 \u2014 static allowlist (incomplete)\nconst LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]); // \u2190 0.0.0.0 missing\n\nconst isIPv4Loopback = (host) =\u003e {\n const parts = host.split(\u0027.\u0027);\n if (parts.length !== 4) return false;\n if (parts[0] !== \u0027127\u0027) return false; // \u2190 0.0.0.0: parts[0] = \u00270\u0027 \u2192 false\n return parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255);\n};\n\nconst isLoopback = (host) =\u003e {\n if (!host) return false;\n if (LOOPBACK_HOSTNAMES.has(host)) return true; // \u2190 \u00270.0.0.0\u0027 not in set\n if (isIPv4Loopback(host)) return true; // \u2190 returns false for 0.0.0.0\n return isIPv6Loopback(host);\n};\n\nisLoopback(\u00270.0.0.0\u0027) returns false.\n\nNode\u0027s WHATWG URL parser does not normalise 0.0.0.0 to 127.0.0.1. Other bypass forms are safe: new URL(\u0027http://0177.0.0.1/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (octal), new URL(\u0027http://2130706433/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (decimal), new URL(\u0027http://0x7f000001/\u0027).hostname \u2192 \u0027127.0.0.1\u0027 (hex). Only 0.0.0.0 escapes normalisation.\n\n\n### PoC\n\u0027use strict\u0027;\n\n// Verbatim copy of relevant logic from axios v1.16.1 shouldBypassProxy.js\n\nconst LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]);\n\nconst isIPv4Loopback = (host) =\u003e {\n const parts = host.split(\u0027.\u0027);\n if (parts.length !== 4) return false;\n if (parts[0] !== \u0027127\u0027) return false;\n return parts.every((p) =\u003e /^\\d+$/.test(p) \u0026\u0026 Number(p) \u003e= 0 \u0026\u0026 Number(p) \u003c= 255);\n};\n\nconst isLoopback = (host) =\u003e {\n if (!host) return false;\n if (LOOPBACK_HOSTNAMES.has(host)) return true;\n return isIPv4Loopback(host);\n};\n\n// 1. Show URL parser does NOT normalise 0.0.0.0\nconsole.log(new URL(\u0027http://0.0.0.0/\u0027).hostname); // \u2192 \u00270.0.0.0\u0027 \u2190 NOT normalised\nconsole.log(new URL(\u0027http://0177.0.0.1/\u0027).hostname); // \u2192 \u0027127.0.0.1\u0027 \u2190 normalised (safe)\nconsole.log(new URL(\u0027http://2130706433/\u0027).hostname); // \u2192 \u0027127.0.0.1\u0027 \u2190 normalised (safe)\n\n// 2. Show isLoopback fails for 0.0.0.0\nconsole.log(isLoopback(\u00270.0.0.0\u0027)); // \u2192 false \u2190 BUG: should be true\nconsole.log(isLoopback(\u0027127.0.0.1\u0027)); // \u2192 true \u2190 correct\n\nVerified output on Node.js v22 / axios v1.16.1:\n0.0.0.0 \u2190 NOT normalised by URL parser\n127.0.0.1 \u2190 octal normalised correctly\n127.0.0.1 \u2190 decimal normalised correctly\nfalse \u2190 0.0.0.0 not detected as loopback \u26a0\ntrue \u2190 127.0.0.1 correctly detected\n\n### Impact\nApplications that:\n\nAccept user-supplied URLs and pass them to axios\nUse a proxy with NO_PROXY=localhost (or similar) for SSRF filtering\n\u2026can be bypassed by supplying http://0.0.0.0/\u003cpath\u003e. Axios routes the request through the proxy (shouldBypassProxy returns false). If the proxy itself does not filter 0.0.0.0, the connection reaches the local machine \u2014 exposing internal services such as cloud IMDS endpoints, internal admin panels, or microservice APIs.\n\nFix\nMinimal (one line):\n\n- const LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027]);\n+ const LOOPBACK_HOSTNAMES = new Set([\u0027localhost\u0027, \u00270.0.0.0\u0027]);\n\nComprehensive:\n\nconst isIPv4Unspecified = (host) =\u003e host === \u00270.0.0.0\u0027;\n\nconst isLoopback = (host) =\u003e {\n if (!host) return false;\n if (LOOPBACK_HOSTNAMES.has(host)) return true;\n if (isIPv4Loopback(host)) return true;\n if (isIPv4Unspecified(host)) return true; // add this line\n return isIPv6Loopback(host);\n};\n\u003c/details\u003e",
"id": "GHSA-f4gw-2p7v-4548",
"modified": "2026-09-01T18:39:43Z",
"published": "2026-07-20T22:20:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-f4gw-2p7v-4548"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67315"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68946"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/11000"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/11001"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/1417285c69344bbcc6420a021f67dee0c6fedb2d"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/32fc489632377d214db55bfa4e2c48486a7d7ce2"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v0.33.0"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.18.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/axios-before-no-proxy-bypass-via"
}
],
"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:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Axios: NO_PROXY bypass for 0.0.0.0 local addresses in axios"
}
GHSA-F4QF-JJ8G-F9QC
Vulnerability from github – Published: 2026-08-17 21:31 – Updated: 2026-08-18 21:31A blind SSRF attack in DataHub v.1.5.0.1 allows a remote attacker to execute arbitrary code via the server retrieving an image from a crafted URL, and it fails to return the content or any errors directly.
{
"affected": [],
"aliases": [
"CVE-2026-50775"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-17T19:16:31Z",
"severity": "CRITICAL"
},
"details": "A blind SSRF attack in DataHub v.1.5.0.1 allows a remote attacker to execute arbitrary code via the server retrieving an image from a crafted URL, and it fails to return the content or any errors directly.",
"id": "GHSA-f4qf-jj8g-f9qc",
"modified": "2026-08-18T21:31:40Z",
"published": "2026-08-17T21:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50775"
},
{
"type": "WEB",
"url": "https://datahub.com"
},
{
"type": "WEB",
"url": "https://github.com/Henkel-CyberVM/CVEs/tree/main/CVE-2026-50775"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
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.