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.
5878 vulnerabilities reference this CWE, most recent first.
GHSA-5VXG-7WX9-4FP4
Vulnerability from github – Published: 2025-01-23 06:31 – Updated: 2025-01-23 06:31A server side request forgery vulnerability was identified in Kibana where the /api/fleet/health_check API could be used to send requests to internal endpoints. Due to the nature of the underlying request, only endpoints available over https that return JSON could be accessed. This can be carried out by users with read access to Fleet.
{
"affected": [],
"aliases": [
"CVE-2024-43710"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-23T06:15:27Z",
"severity": "MODERATE"
},
"details": "A server side request forgery vulnerability was identified in Kibana where the /api/fleet/health_check API could be used to send requests to internal endpoints. Due to the nature of the underlying request, only endpoints available over https that return JSON could be accessed. This can be carried out by users with read access to Fleet.",
"id": "GHSA-5vxg-7wx9-4fp4",
"modified": "2025-01-23T06:31:49Z",
"published": "2025-01-23T06:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43710"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/kibana-8-15-0-security-update-esa-2024-29-esa-2024-30/373521"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5W55-FGG7-M5GX
Vulnerability from github – Published: 2025-09-08 06:30 – Updated: 2025-09-08 21:30The Ditty WordPress plugin before 3.1.58 lacks authorization and authentication for requests to its displayItems endpoint, allowing unauthenticated visitors to make requests to arbitrary URLs.
{
"affected": [],
"aliases": [
"CVE-2025-8085"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-08T06:15:34Z",
"severity": "HIGH"
},
"details": "The Ditty WordPress plugin before 3.1.58 lacks authorization and authentication for requests to its displayItems endpoint, allowing unauthenticated visitors to make requests to arbitrary URLs.",
"id": "GHSA-5w55-fgg7-m5gx",
"modified": "2025-09-08T21:30:59Z",
"published": "2025-09-08T06:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8085"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/f42c37bb-1ae0-49ab-bd81-7864dff0fcff"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5W5H-C32Q-R6W9
Vulnerability from github – Published: 2026-05-11 18:31 – Updated: 2026-05-11 18:31OpenClaw before 2026.4.20 contains a server-side request forgery vulnerability in browser CDP profile creation that skips strict-mode SSRF policy checks. Attackers can create stored profiles pointing to private-network or metadata endpoints that bypass security policies and are later probed during normal profile status operations.
{
"affected": [],
"aliases": [
"CVE-2026-45000"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-11T18:16:40Z",
"severity": "LOW"
},
"details": "OpenClaw before 2026.4.20 contains a server-side request forgery vulnerability in browser CDP profile creation that skips strict-mode SSRF policy checks. Attackers can create stored profiles pointing to private-network or metadata endpoints that bypass security policies and are later probed during normal profile status operations.",
"id": "GHSA-5w5h-c32q-r6w9",
"modified": "2026-05-11T18:31:47Z",
"published": "2026-05-11T18:31:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-j4c5-89f5-f3pm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45000"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/1fd049e3074cac72f6734a7fe88468c84f5f8bd7"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/e90c89cf8b1459f2aa1f3a665be67392b6c03fdf"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-server-side-request-forgery-via-browser-cdp-profile-creation"
}
],
"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:P/PR:L/UI:N/VC:N/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-5WJ3-M77Q-J278
Vulnerability from github – Published: 2026-07-08 18:31 – Updated: 2026-07-08 18:31repomix contains a server-side request forgery vulnerability in the POST /api/pack endpoint that allows unauthenticated attackers to make arbitrary outbound requests. The endpoint fails to properly validate http://, https://, and file:// URLs before passing them to git clone, enabling attackers to access private network addresses, GCP metadata services, or local filesystem paths.
{
"affected": [],
"aliases": [
"CVE-2026-59702"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-08T16:16:31Z",
"severity": "CRITICAL"
},
"details": "repomix contains a server-side request forgery vulnerability in the POST /api/pack endpoint that allows unauthenticated attackers to make arbitrary outbound requests. The endpoint fails to properly validate http://, https://, and file:// URLs before passing them to git clone, enabling attackers to access private network addresses, GCP metadata services, or local filesystem paths.",
"id": "GHSA-5wj3-m77q-j278",
"modified": "2026-07-08T18:31:36Z",
"published": "2026-07-08T18:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59702"
},
{
"type": "WEB",
"url": "https://github.com/yamadashy/repomix/issues/1703"
},
{
"type": "WEB",
"url": "https://github.com/CrazyForks/repomix/commit/c748b524f41225e7fc6f89ad0084520901a453cf"
},
{
"type": "WEB",
"url": "https://github.com/yamadashy/repomix"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/repomix-server-side-request-forgery-via-unvalidated-repository-urls-in-post-api-pack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/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-5WW6-XVHM-X8Q3
Vulnerability from github – Published: 2024-06-30 18:30 – Updated: 2024-06-30 18:30IBM InfoSphere Information Server 11.7 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 275774.
{
"affected": [],
"aliases": [
"CVE-2023-50952"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-30T18:15:02Z",
"severity": "MODERATE"
},
"details": "IBM InfoSphere Information Server 11.7 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 275774.",
"id": "GHSA-5ww6-xvhm-x8q3",
"modified": "2024-06-30T18:30:38Z",
"published": "2024-06-30T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50952"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275774"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7158437"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5X44-6VJC-WRHM
Vulnerability from github – Published: 2022-05-24 17:39 – Updated: 2022-05-24 17:39In Aruba AirWave Glass before 1.3.3, there is a Server-Side Request Forgery vulnerability through an unauthenticated endpoint that if successfully exploited can result in disclosure of sensitive information. This can be used to perform an authentication bypass and ultimately gain administrative access on the web administrative interface.
{
"affected": [],
"aliases": [
"CVE-2020-24641"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-15T19:15:00Z",
"severity": "HIGH"
},
"details": "In Aruba AirWave Glass before 1.3.3, there is a Server-Side Request Forgery vulnerability through an unauthenticated endpoint that if successfully exploited can result in disclosure of sensitive information. This can be used to perform an authentication bypass and ultimately gain administrative access on the web administrative interface.",
"id": "GHSA-5x44-6vjc-wrhm",
"modified": "2022-05-24T17:39:16Z",
"published": "2022-05-24T17:39:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24641"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2021-001.txt"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5X7X-4C3C-QF5W
Vulnerability from github – Published: 2026-09-09 23:54 – Updated: 2026-09-09 23:54Summary
Open WebUI protects server-side web fetches with two controls: the operator's list of excluded hosts, and a check that refuses private and internal addresses. Neither control was applied to the destination of an HTTP redirect. On a deployment where redirect following is enabled, any authenticated user who can cause the server to fetch a URL could submit a page that redirects, and the server would fetch the redirect destination without either control being applied to it. The server therefore connects to hosts the operator excluded, and to internal addresses including loopback, private networks and cloud metadata endpoints.
Preconditions
AIOHTTP_CLIENT_ALLOW_REDIRECTS must be set to true. Its default is false, and on the default the affected fetch paths do not follow redirects at all, so a deployment that has not changed this setting is not affected.
The attacker needs an authenticated account of any role, with access to any feature that causes the server to fetch a URL. Web search, ingesting a URL into a collection, the built-in page fetch tool and image URLs in chat all reach it. No internal hostnames need to be known, because the loopback and cloud metadata addresses are fixed and identical on every deployment.
Neither ENABLE_LOCAL_WEB_FETCH at its default of false nor any set of entries in WEB_FETCH_FILTER_LIST prevents this.
Impact
An authenticated user can make the server issue requests to hosts the operator deliberately excluded, and to addresses on the internal network including loopback, private ranges and the cloud metadata endpoints of the major providers.
What reaches the attacker depends on which HTTP client the fetch path uses, and is stated here as verified rather than assumed. On the paths built on requests, the fetched body is returned to the caller, so the response of an excluded host is readable: the built-in page fetch tool hands it to the model, and the URL ingestion endpoint returns it in its response. Those paths kept a working private-address check at connection time, so what they reach is excluded public hosts and internal names, not private IP addresses. On the paths built on aiohttp, which are the ones that reach private addresses written as IP literals, fetched content reaches the web search response, a retrievable collection, or model input as base64 through chat image URLs. A path on that client returning an attacker-chosen response verbatim to the requester was not demonstrated.
The operator has no configuration that prevents this. 169.254.169.254 ships in the default excluded list, so an operator reviewing their configuration would reasonably conclude the metadata endpoint is out of reach. The documentation for the redirect setting further recommends the excluded-host list as a compensating control when enabling redirects, and that is precisely the control the redirect path skipped.
Fix
Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/27823. The excluded-host list is now evaluated once per request on both HTTP clients, where the real destination is known and a reused connection cannot skip it, so it applies to every redirect hop. The private-address check stays at connection time and is now hooked where aiohttp resolves a host, which is also reached for hosts written as IP literals.
One case is not resolved by the upgrade alone. Where the server reaches the internet through a forward proxy, the private-address check sees the proxy's address rather than the final destination, so it does not constrain where the proxy is asked to connect. The excluded-host list is still applied to the destination on that path. Operators who route outbound fetches through a proxy should enforce destination restrictions on the proxy itself.
Root cause
Affected components:
- the web retrieval fetch paths, on both the aiohttp and
requestsclients - the built-in page fetch tool
- the URL ingestion endpoint
Affected setup: builds that carry the redirect-following setting, which was introduced in 0.9.5. Earlier builds have no such setting.
The two controls sat at different layers, and each sat where only the originally submitted URL passes through. The excluded-host list was consulted inside URL validation, which runs once against what the user submitted, so a redirect destination never reached it on either client. The private-address check was placed inside the aiohttp resolver, and aiohttp answers a host written as an IP address itself without consulting a resolver, so for exactly those hosts the check never ran. Redirect following was added later as an option, and neither control was revisited at that point, so turning it on moved the real destination out of reach of both.
Proof of concept
Both vectors were reproduced against the shipped code of 0.11.0 and confirmed closed against 0.11.1, with AIOHTTP_CLIENT_ALLOW_REDIRECTS=true in both runs. A local HTTP server serves a redirect and a body, DNS is stubbed so the test hostnames resolve to loopback, and the guards themselves are unmodified.
Excluded-host list, redirect destination 203.0.113.1 excluded, submitted URL not excluded:
0.11.0 no check runs against the redirect destination, the server opens a connection to it
0.11.1 blocked at the redirect hop before any connection is attempted
Private-address check, host written as an IP literal, with ENABLE_LOCAL_WEB_FETCH at its default of false:
0.11.0 fetch returned 'LOOPBACK-CONTENT-REACHED', no check ran
0.11.1 blocked, non-global address 127.0.0.1
Instrumenting 0.11.1 on a redirect that is allowed shows both controls running against the redirect destination as well as the submitted URL, and an ordinary public fetch is unaffected.
Credits
- @arpitjain099, original report: the excluded-host list is not re-applied to redirect destinations.
- @Classic298: the private-address check is bypassed for redirect destinations written as IP literals, through aiohttp's resolver shortcut.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.11.0"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.5"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88001"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-09T23:54:08Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nOpen WebUI protects server-side web fetches with two controls: the operator\u0027s list of excluded hosts, and a check that refuses private and internal addresses. Neither control was applied to the destination of an HTTP redirect. On a deployment where redirect following is enabled, any authenticated user who can cause the server to fetch a URL could submit a page that redirects, and the server would fetch the redirect destination without either control being applied to it. The server therefore connects to hosts the operator excluded, and to internal addresses including loopback, private networks and cloud metadata endpoints.\n\n## Preconditions\n\n`AIOHTTP_CLIENT_ALLOW_REDIRECTS` must be set to `true`. Its default is `false`, and on the default the affected fetch paths do not follow redirects at all, so a deployment that has not changed this setting is not affected.\n\nThe attacker needs an authenticated account of any role, with access to any feature that causes the server to fetch a URL. Web search, ingesting a URL into a collection, the built-in page fetch tool and image URLs in chat all reach it. No internal hostnames need to be known, because the loopback and cloud metadata addresses are fixed and identical on every deployment.\n\nNeither `ENABLE_LOCAL_WEB_FETCH` at its default of `false` nor any set of entries in `WEB_FETCH_FILTER_LIST` prevents this.\n\n## Impact\n\nAn authenticated user can make the server issue requests to hosts the operator deliberately excluded, and to addresses on the internal network including loopback, private ranges and the cloud metadata endpoints of the major providers.\n\nWhat reaches the attacker depends on which HTTP client the fetch path uses, and is stated here as verified rather than assumed. On the paths built on `requests`, the fetched body is returned to the caller, so the response of an excluded host is readable: the built-in page fetch tool hands it to the model, and the URL ingestion endpoint returns it in its response. Those paths kept a working private-address check at connection time, so what they reach is excluded public hosts and internal names, not private IP addresses. On the paths built on aiohttp, which are the ones that reach private addresses written as IP literals, fetched content reaches the web search response, a retrievable collection, or model input as base64 through chat image URLs. A path on that client returning an attacker-chosen response verbatim to the requester was not demonstrated.\n\nThe operator has no configuration that prevents this. `169.254.169.254` ships in the default excluded list, so an operator reviewing their configuration would reasonably conclude the metadata endpoint is out of reach. The documentation for the redirect setting further recommends the excluded-host list as a compensating control when enabling redirects, and that is precisely the control the redirect path skipped.\n\n## Fix\n\nFixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/27823. The excluded-host list is now evaluated once per request on both HTTP clients, where the real destination is known and a reused connection cannot skip it, so it applies to every redirect hop. The private-address check stays at connection time and is now hooked where aiohttp resolves a host, which is also reached for hosts written as IP literals.\n\nOne case is not resolved by the upgrade alone. Where the server reaches the internet through a forward proxy, the private-address check sees the proxy\u0027s address rather than the final destination, so it does not constrain where the proxy is asked to connect. The excluded-host list is still applied to the destination on that path. Operators who route outbound fetches through a proxy should enforce destination restrictions on the proxy itself.\n\n## Root cause\n\nAffected components:\n\n- the web retrieval fetch paths, on both the aiohttp and `requests` clients\n- the built-in page fetch tool\n- the URL ingestion endpoint\n\nAffected setup: builds that carry the redirect-following setting, which was introduced in 0.9.5. Earlier builds have no such setting.\n\nThe two controls sat at different layers, and each sat where only the originally submitted URL passes through. The excluded-host list was consulted inside URL validation, which runs once against what the user submitted, so a redirect destination never reached it on either client. The private-address check was placed inside the aiohttp resolver, and aiohttp answers a host written as an IP address itself without consulting a resolver, so for exactly those hosts the check never ran. Redirect following was added later as an option, and neither control was revisited at that point, so turning it on moved the real destination out of reach of both.\n\n## Proof of concept\n\nBoth vectors were reproduced against the shipped code of 0.11.0 and confirmed closed against 0.11.1, with `AIOHTTP_CLIENT_ALLOW_REDIRECTS=true` in both runs. A local HTTP server serves a redirect and a body, DNS is stubbed so the test hostnames resolve to loopback, and the guards themselves are unmodified.\n\nExcluded-host list, redirect destination `203.0.113.1` excluded, submitted URL not excluded:\n\n```\n0.11.0 no check runs against the redirect destination, the server opens a connection to it\n0.11.1 blocked at the redirect hop before any connection is attempted\n```\n\nPrivate-address check, host written as an IP literal, with `ENABLE_LOCAL_WEB_FETCH` at its default of `false`:\n\n```\n0.11.0 fetch returned \u0027LOOPBACK-CONTENT-REACHED\u0027, no check ran\n0.11.1 blocked, non-global address 127.0.0.1\n```\n\nInstrumenting 0.11.1 on a redirect that is allowed shows both controls running against the redirect destination as well as the submitted URL, and an ordinary public fetch is unaffected.\n\n## Credits\n\n- @arpitjain099, original report: the excluded-host list is not re-applied to redirect destinations.\n- @Classic298: the private-address check is bypassed for redirect destinations written as IP literals, through aiohttp\u0027s resolver shortcut.",
"id": "GHSA-5x7x-4c3c-qf5w",
"modified": "2026-09-09T23:54:08Z",
"published": "2026-09-09T23:54:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-5x7x-4c3c-qf5w"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/27823"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/e3e4bd87df6fc629e7e22081d980d55a7632b8b7"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Server-side fetches reach blocked and internal hosts via unvalidated HTTP redirect targets"
}
GHSA-5XCH-82FP-5J4W
Vulnerability from github – Published: 2025-12-01 21:30 – Updated: 2025-12-02 21:31PublicCMS V5.202506.b is vulnerable to SSRF. in the chat interface of SimpleAiAdminController.
{
"affected": [],
"aliases": [
"CVE-2025-65836"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-01T20:15:57Z",
"severity": "CRITICAL"
},
"details": "PublicCMS V5.202506.b is vulnerable to SSRF. in the chat interface of SimpleAiAdminController.",
"id": "GHSA-5xch-82fp-5j4w",
"modified": "2025-12-02T21:31:27Z",
"published": "2025-12-01T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65836"
},
{
"type": "WEB",
"url": "https://github.com/sanluan/PublicCMS/issues/99"
},
{
"type": "WEB",
"url": "https://github.com/Hyperkopite/PublicCMS_Vulns/blob/main/SSRF_1.md"
},
{
"type": "WEB",
"url": "https://github.com/sanluan/PublicCMS"
}
],
"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-5XHR-994V-5G9P
Vulnerability from github – Published: 2025-04-28 18:30 – Updated: 2025-04-28 18:30DevExpress before 23.1.3 allows AsyncDownloader SSRF.
{
"affected": [],
"aliases": [
"CVE-2023-35817"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-28T16:15:26Z",
"severity": "MODERATE"
},
"details": "DevExpress before 23.1.3 allows AsyncDownloader SSRF.",
"id": "GHSA-5xhr-994v-5g9p",
"modified": "2025-04-28T18:30:57Z",
"published": "2025-04-28T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35817"
},
{
"type": "WEB",
"url": "https://code-white.com/public-vulnerability-list"
},
{
"type": "WEB",
"url": "https://supportcenter.devexpress.com/ticket/details/t1157209/server-side-request-forgery-via-asyncdownloader"
},
{
"type": "WEB",
"url": "https://supportcenter.devexpress.com/ticket/details/t1161404/report-and-dashboard-server-improper-default-configuration-can-lead-to-ssrf-attacks"
},
{
"type": "WEB",
"url": "https://supportcenter.devexpress.com/ticket/details/t1162045/reporting-bi-dashboard-office-file-api-web-app-configuration-to-help-prevent-ssrf-attacks"
},
{
"type": "WEB",
"url": "https://supportcenter.devexpress.com/ticket/details/t394936/devexpress-security-advisory-updated-on-april-27-2023"
}
],
"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"
}
]
}
GHSA-5XJP-M73Q-2884
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15There is a server-side request forgery vulnerability in HUAWEI P40 versions 10.1.0.118(C00E116R3P3). This vulnerability is due to insufficient validation of parameters while dealing with some messages. A successful exploit could allow the attacker to gain access to certain resource which the attacker are supposed not to do.
{
"affected": [],
"aliases": [
"CVE-2021-37104"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-28T15:15:00Z",
"severity": "HIGH"
},
"details": "There is a server-side request forgery vulnerability in HUAWEI P40 versions 10.1.0.118(C00E116R3P3). This vulnerability is due to insufficient validation of parameters while dealing with some messages. A successful exploit could allow the attacker to gain access to certain resource which the attacker are supposed not to do.",
"id": "GHSA-5xjp-m73q-2884",
"modified": "2022-05-24T19:15:59Z",
"published": "2022-05-24T19:15:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37104"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210922-01-ssrf-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.