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.
6723 vulnerabilities reference this CWE, most recent first.
GHSA-4QQR-VV2Q-CMR5
Vulnerability from github – Published: 2026-06-16 21:00 – Updated: 2026-07-20 21:12Summary
The Docker API server's SSRF protection (validate_webhook_url / validate_url_destination in deploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. 169.254.169.254) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address.
Because the Docker API is unauthenticated by default (jwt_enabled: false), no credentials are required.
Affected paths
The blocklist was applied to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /execute_js) and webhook URLs (/crawl/job, /llm/job). All shared the same incomplete check.
Bypasses
The following all resolve to (or route to) blocked internal addresses but were NOT caught:
- IPv6 unspecified ::
- NAT64 64:ff9b::a9fe:a9fe (embeds 169.254.169.254)
- 6to4 2002:a9fe:a9fe:: (embeds 169.254.169.254)
- IPv4-mapped ::ffff:169.254.169.254
- IPv4-compatible ::a9fe:a9fe
The error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak.
Impact
Server-Side Request Forgery: an unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints, potentially exposing internal services and cloud credentials.
Fix
The blocklist is replaced by a single rule: reject any resolved IP where not ip.is_global, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT64 64:ff9b::/96, 6to4 2002::/16, v4-compat ::/96). Error messages are now opaque and no longer echo the resolved IP.
Workarounds
- Upgrade to the patched version.
- Enable authentication (
CRAWL4AI_API_TOKEN). - Restrict the container's outbound network access (egress firewall / no metadata route).
Credits
Internal security audit (Crawl4AI maintainers).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.7"
},
"package": {
"ecosystem": "PyPI",
"name": "crawl4ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53754"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T21:00:04Z",
"nvd_published_at": "2026-06-23T19:17:07Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe Docker API server\u0027s SSRF protection (`validate_webhook_url` / `validate_url_destination` in `deploy/docker/utils.py`) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. `169.254.169.254`) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address.\n\nBecause the Docker API is unauthenticated by default (`jwt_enabled: false`), no credentials are required.\n\n### Affected paths\n\nThe blocklist was applied to crawl URLs (`POST /crawl`, `/md`, `/html`, `/screenshot`, `/pdf`, `/execute_js`) and webhook URLs (`/crawl/job`, `/llm/job`). All shared the same incomplete check.\n\n### Bypasses\n\nThe following all resolve to (or route to) blocked internal addresses but were NOT caught:\n- IPv6 unspecified `::`\n- NAT64 `64:ff9b::a9fe:a9fe` (embeds `169.254.169.254`)\n- 6to4 `2002:a9fe:a9fe::` (embeds `169.254.169.254`)\n- IPv4-mapped `::ffff:169.254.169.254`\n- IPv4-compatible `::a9fe:a9fe`\n\nThe error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak.\n\n### Impact\n\nServer-Side Request Forgery: an unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints, potentially exposing internal services and cloud credentials.\n\n### Fix\n\nThe blocklist is replaced by a single rule: reject any resolved IP where `not ip.is_global`, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, v4-compat `::/96`). Error messages are now opaque and no longer echo the resolved IP.\n\n### Workarounds\n\n- Upgrade to the patched version.\n- Enable authentication (`CRAWL4AI_API_TOKEN`).\n- Restrict the container\u0027s outbound network access (egress firewall / no metadata route).\n\n### Credits\n\nInternal security audit (Crawl4AI maintainers).",
"id": "GHSA-4qqr-vv2q-cmr5",
"modified": "2026-07-20T21:12:00Z",
"published": "2026-06-16T21:00:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-4qqr-vv2q-cmr5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53754"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/crawl4ai/PYSEC-2026-587.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/unclecode/crawl4ai"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)"
}
GHSA-4R5R-P2HF-QWWW
Vulnerability from github – Published: 2026-01-22 18:30 – Updated: 2026-01-27 00:31Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft Pool Services pool-services allows Server Side Request Forgery.This issue affects Pool Services: from n/a through <= 3.3.
{
"affected": [],
"aliases": [
"CVE-2025-62741"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-22T17:15:59Z",
"severity": "CRITICAL"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in SmartDataSoft Pool Services pool-services allows Server Side Request Forgery.This issue affects Pool Services: from n/a through \u003c= 3.3.",
"id": "GHSA-4r5r-p2hf-qwww",
"modified": "2026-01-27T00:31:10Z",
"published": "2026-01-22T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62741"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Theme/pool-services/vulnerability/wordpress-pool-services-theme-3-3-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-4R8V-7F5Q-9MR7
Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-15 21:31Vulnerabilities in the API of EdgeConnect SD-WAN Orchestrator could allow a remote attacker authenticated with low privileges to conduct server-side request forgery (SSRF) attacks. A successful exploit allows an attacker to enumerate information about the internal structure of the EdgeConnect SD-WAN Orchestrator host leading to potential disclosure of sensitive information beyond what is authorized by the user's existing privilege level.
{
"affected": [],
"aliases": [
"CVE-2026-76680"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T20:17:49Z",
"severity": "HIGH"
},
"details": "Vulnerabilities in the API of EdgeConnect SD-WAN Orchestrator could allow a remote attacker authenticated with low privileges to conduct server-side request forgery (SSRF) attacks. A successful exploit allows an attacker to enumerate information about the internal structure of the EdgeConnect SD-WAN Orchestrator host leading to potential disclosure of sensitive information beyond what is authorized by the user\u0027s existing privilege level.",
"id": "GHSA-4r8v-7f5q-9mr7",
"modified": "2026-09-15T21:31:35Z",
"published": "2026-09-15T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76680"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw05135en_us\u0026docLocale=en_US"
}
],
"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-4R9J-P4GW-X3HM
Vulnerability from github – Published: 2026-10-28 06:30 – Updated: 2026-10-28 18:31The Customer Engagement System WordPress plugin before 2.0.2 does not restrict access to its MailChimp interest-group lookup or validate the API key supplied to it, allowing unauthenticated users to make the server open connections to arbitrary internal hosts and ports and infer from response timing which ones are reachable.
{
"affected": [],
"aliases": [
"CVE-2026-115225"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-28T06:16:35Z",
"severity": "MODERATE"
},
"details": "The Customer Engagement System WordPress plugin before 2.0.2 does not restrict access to its MailChimp interest-group lookup or validate the API key supplied to it, allowing unauthenticated users to make the server open connections to arbitrary internal hosts and ports and infer from response timing which ones are reachable.",
"id": "GHSA-4r9j-p4gw-x3hm",
"modified": "2026-10-28T18:31:56Z",
"published": "2026-10-28T06:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115225"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/b91dc5fc-8b7b-4874-9e71-e3d07b41812a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4RHC-Q92G-RM98
Vulnerability from github – Published: 2025-01-15 18:30 – Updated: 2025-01-15 18:30A vulnerability classified as problematic has been found in wuzhicms 4.1.0. This affects the function test of the file coreframe/app/search/admin/config.php. The manipulation of the argument sphinxhost/sphinxport leads to server-side request forgery. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-0480"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-15T18:15:24Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as problematic has been found in wuzhicms 4.1.0. This affects the function test of the file coreframe/app/search/admin/config.php. The manipulation of the argument sphinxhost/sphinxport leads to server-side request forgery. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-4rhc-q92g-rm98",
"modified": "2025-01-15T18:30:58Z",
"published": "2025-01-15T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0480"
},
{
"type": "WEB",
"url": "https://github.com/wuzhicms/wuzhicms/issues/212"
},
{
"type": "WEB",
"url": "https://github.com/wuzhicms/wuzhicms/issues/212#issue-2769226216"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.291915"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.291915"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.474965"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4RJ6-VRWV-WR8M
Vulnerability from github – Published: 2026-07-24 16:11 – Updated: 2026-08-17 14:54Summary
Microsoft Kiota honors a poisoned .kiota/workspace.json — the workspace configuration that Kiota's
documented team workflow has developers commit to their repository — unvalidated on
kiota client generate / kiota plugin generate. A repository (or pull request) containing a malicious
per-client / per-plugin outputPath causes Kiota, when a developer or CI runs the documented regenerate
command, to (CWE-22) write the entire generated client to an arbitrary path outside the workspace — the
outputPath was not confined to the workspace root and absolute paths were accepted.
Confirmed on Kiota 1.32.4 (KIOTA_CONFIG_PREVIEW=true, the self-contained linux-x64 release binary).
Details
// .kiota/workspace.json (committed to the repo)
"clients": { "MyClient": {
"outputPath": "/abs/path/outside/repo/pwned_client" // -> generated client written here (CWE-22)
}}
Running kiota client generate --client-name MyClient in the repo writes MyClient.cs,
P/PRequestBuilder.cs, … to the attacker-chosen outputPath (verified outside the working tree).
Note on descriptionLocation
The per-consumer descriptionLocation is intentionally fetched at generation time — this is how Kiota knows
where to pull an updated description from when refreshing a client, the same way any other value in a
committed lock/config file is honored. It is not treated as a vulnerability and is unchanged; only
outputPath is now confined.
Impact
A malicious or compromised repository — or a malicious PR that edits .kiota/workspace.json — leads to
arbitrary file write on the developer's or CI host's filesystem (overwrite source/build files, drop files in
auto-loaded locations) whenever a teammate clones/pulls and runs the documented kiota client generate /
kiota plugin generate to refresh the client. CWE-22.
This is a different trust boundary from the OpenAPI-description-based findings: the malicious input is the Kiota config, not the spec.
Patches
Fixed in 1.29.1 and 1.32.5 (https://github.com/microsoft/kiota/pull/7885). On loading a workspace configuration,
each client/plugin outputPath is validated to be a relative subdirectory of the workspace: null/empty,
rooted paths (POSIX /, UNC \\ / //, Windows drive X:\), and any .. traversal segment are rejected,
and the resolved full path must stay under the workspace root. Generation aborts with an error if any
consumer's outputPath escapes the workspace.
Remediation
Upgrade to Kiota 1.29.1, 1.32.5 or later. Review any committed workspace configs for outputPath values that
point outside the workspace.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota"
},
"ranges": [
{
"events": [
{
"introduced": "1.30.0"
},
{
"fixed": "1.32.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota.Builder"
},
"ranges": [
{
"events": [
{
"introduced": "1.30.0"
},
{
"fixed": "1.32.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.29.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.OpenApi.Kiota.Builder"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.29.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59863"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-829",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:11:24Z",
"nvd_published_at": "2026-07-16T15:16:35Z",
"severity": "HIGH"
},
"details": "### Summary\n\nMicrosoft Kiota honors a poisoned `.kiota/workspace.json` \u2014 the workspace configuration that Kiota\u0027s\ndocumented team workflow has developers commit to their repository \u2014 **unvalidated** on\n`kiota client generate` / `kiota plugin generate`. A repository (or pull request) containing a malicious\nper-client / per-plugin `outputPath` causes Kiota, when a developer or CI runs the documented regenerate\ncommand, to **(CWE-22) write the entire generated client to an arbitrary path outside the workspace** \u2014 the\n`outputPath` was not confined to the workspace root and absolute paths were accepted.\n\nConfirmed on Kiota **1.32.4** (`KIOTA_CONFIG_PREVIEW=true`, the self-contained `linux-x64` release binary).\n\n### Details\n\n```jsonc\n// .kiota/workspace.json (committed to the repo)\n\"clients\": { \"MyClient\": {\n \"outputPath\": \"/abs/path/outside/repo/pwned_client\" // -\u003e generated client written here (CWE-22)\n}}\n```\n\nRunning `kiota client generate --client-name MyClient` in the repo writes `MyClient.cs`,\n`P/PRequestBuilder.cs`, \u2026 to the attacker-chosen `outputPath` (verified outside the working tree).\n\n#### Note on `descriptionLocation`\n\nThe per-consumer `descriptionLocation` is intentionally fetched at generation time \u2014 this is how Kiota knows\nwhere to pull an updated description from when refreshing a client, the same way any other value in a\ncommitted lock/config file is honored. It is **not** treated as a vulnerability and is unchanged; only\n`outputPath` is now confined.\n\n### Impact\n\nA malicious or compromised repository \u2014 or a malicious PR that edits `.kiota/workspace.json` \u2014 leads to\narbitrary file write on the developer\u0027s or CI host\u0027s filesystem (overwrite source/build files, drop files in\nauto-loaded locations) whenever a teammate clones/pulls and runs the documented `kiota client generate` /\n`kiota plugin generate` to refresh the client. CWE-22.\n\nThis is a different trust boundary from the OpenAPI-description-based findings: the malicious input is the\nKiota **config**, not the spec.\n\n### Patches\n\nFixed in **1.29.1 and 1.32.5** (https://github.com/microsoft/kiota/pull/7885). On loading a workspace configuration,\neach client/plugin `outputPath` is validated to be a relative subdirectory of the workspace: null/empty,\nrooted paths (POSIX `/`, UNC `\\\\` / `//`, Windows drive `X:\\`), and any `..` traversal segment are rejected,\nand the resolved full path must stay under the workspace root. Generation aborts with an error if any\nconsumer\u0027s `outputPath` escapes the workspace.\n\n### Remediation\n\nUpgrade to Kiota **1.29.1, 1.32.5** or later. Review any committed workspace configs for `outputPath` values that\npoint outside the workspace.",
"id": "GHSA-4rj6-vrwv-wr8m",
"modified": "2026-08-17T14:54:18Z",
"published": "2026-07-24T16:11:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/security/advisories/GHSA-4rj6-vrwv-wr8m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59863"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/pull/7885"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/commit/4049327872db7846ace35c9003774d3e3878e4e9"
},
{
"type": "PACKAGE",
"url": "https://github.com/microsoft/kiota"
},
{
"type": "WEB",
"url": "https://github.com/microsoft/kiota/releases/tag/v1.32.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Microsoft Kiota Workspace-config poisoning: out-of-repo file write + generation-time SSRF"
}
GHSA-4RMJ-W58M-FVCH
Vulnerability from github – Published: 2023-03-06 21:30 – Updated: 2025-03-05 19:05In Moodle, insufficient redirect handling made it possible to blindly bypass cURL blocked hosts/allowed ports restrictions, resulting in a blind SSRF risk.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.11.0-beta"
},
{
"fixed": "3.11.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.10.0-beta"
},
{
"fixed": "3.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.9.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-36396"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-07T20:56:50Z",
"nvd_published_at": "2023-03-06T21:15:00Z",
"severity": "HIGH"
},
"details": "In Moodle, insufficient redirect handling made it possible to blindly bypass cURL blocked hosts/allowed ports restrictions, resulting in a blind SSRF risk.",
"id": "GHSA-4rmj-w58m-fvch",
"modified": "2025-03-05T19:05:46Z",
"published": "2023-03-06T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36396"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=424802"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle vulnerable to Server-Side Request Forgery"
}
GHSA-4RQQ-W8V4-7P47
Vulnerability from github – Published: 2026-03-04 19:03 – Updated: 2026-04-24 20:59Summary
isPrivateIpv4() in bundled SSRF guard code missed several IPv4 special-use/non-global ranges, so web_fetch could allow targets that should be blocked by SSRF policy.
Affected Packages / Versions
- Package:
openclaw(npm) - Latest published affected version:
2026.2.21-2(published 2026-02-21) - Structured vulnerable range:
<= 2026.2.21-2 - Planned patched version (pre-set):
>= 2026.2.22
Impact
Low severity. Exploitation requires network reachability to the relevant special-use ranges and a request path that reaches web_fetch URL fetching.
Technical Details
Affected releases used narrow IPv4 private-range checks that omitted multiple RFC special-use/non-global ranges. This allowed requests such as http://198.18.0.1/... through SSRF validation in affected releases. Follow-up hardening consolidates local-host/tailnet range checks so gateway/browser/tailnet paths share one canonical IP classification flow.
Fix Commit(s)
71bd15bb4294d3d1b54386064d69cd0f5f731bd844dfbd23df453e51b71ef79a148c28c53e89168c333fbb86347998526dd514290adfd5f727caa6d9f14ebd743cfc73f667fae80af70043d0ab1f88bd
OpenClaw thanks @princeeismond-dot for reporting.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32019"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T19:03:45Z",
"nvd_published_at": "2026-03-19T22:16:35Z",
"severity": "MODERATE"
},
"details": "### Summary\n`isPrivateIpv4()` in bundled SSRF guard code missed several IPv4 special-use/non-global ranges, so `web_fetch` could allow targets that should be blocked by SSRF policy.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published affected version: `2026.2.21-2` (published 2026-02-21)\n- Structured vulnerable range: `\u003c= 2026.2.21-2`\n- Planned patched version (pre-set): `\u003e= 2026.2.22`\n\n### Impact\nLow severity. Exploitation requires network reachability to the relevant special-use ranges and a request path that reaches `web_fetch` URL fetching.\n\n### Technical Details\nAffected releases used narrow IPv4 private-range checks that omitted multiple RFC special-use/non-global ranges. This allowed requests such as `http://198.18.0.1/...` through SSRF validation in affected releases. Follow-up hardening consolidates local-host/tailnet range checks so gateway/browser/tailnet paths share one canonical IP classification flow.\n\n### Fix Commit(s)\n- `71bd15bb4294d3d1b54386064d69cd0f5f731bd8`\n- `44dfbd23df453e51b71ef79a148c28c53e89168c`\n- `333fbb86347998526dd514290adfd5f727caa6d9`\n- `f14ebd743cfc73f667fae80af70043d0ab1f88bd`\n\nOpenClaw thanks @princeeismond-dot for reporting.",
"id": "GHSA-4rqq-w8v4-7p47",
"modified": "2026-04-24T20:59:05Z",
"published": "2026-03-04T19:03:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4rqq-w8v4-7p47"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32019"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/333fbb86347998526dd514290adfd5f727caa6d9"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/44dfbd23df453e51b71ef79a148c28c53e89168c"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/71bd15bb4294d3d1b54386064d69cd0f5f731bd8"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/f14ebd743cfc73f667fae80af70043d0ab1f88bd"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-incomplete-ipv4-special-use-range-blocking-in-ssrf-guard"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw has incomplete IPv4 special-use SSRF blocking in web fetch guard"
}
GHSA-4V28-J6Q3-5M4R
Vulnerability from github – Published: 2026-09-10 15:10 – Updated: 2026-09-10 15:10Summary
With the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.
Preconditions
WEB_LOADER_ENGINE=playwright. This is not the default, and deployments on the default web loader are unaffected.- A reachable Playwright browser, either local or via
PLAYWRIGHT_WS_URL. - Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.
- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.
Impact
An authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.
Because the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.
Fix
Fixed in 0.11.1 by commit 27402ff21 (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.
Root cause
Affected component: SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.
The address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright's request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.
Proof of concept
Reproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.
Credits
- @baeseungwon1010 — identified that the address check and the browser's own resolution are two separate lookups, so the check cannot constrain where the browser connects.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.6"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87996"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:10:12Z",
"nvd_published_at": "2026-09-09T22:18:47Z",
"severity": "HIGH"
},
"details": "## Summary\nWith the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.\n\n## Preconditions\n- `WEB_LOADER_ENGINE=playwright`. This is not the default, and deployments on the default web loader are unaffected.\n- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.\n- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.\n- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.\n- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.\n\n## Impact\nAn authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.\n\nBecause the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.\n\n## Fix\nFixed in 0.11.1 by commit `27402ff21` (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.\n\n## Root cause\nAffected component: `SafePlaywrightURLLoader` in `backend/open_webui/retrieval/web/utils.py`, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.\n\nThe address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright\u0027s request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.\n\n## Proof of concept\nReproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.\n\n## Credits\n- **@baeseungwon1010** \u2014 identified that the address check and the browser\u0027s own resolution are two separate lookups, so the check cannot constrain where the browser connects.",
"id": "GHSA-4v28-j6q3-5m4r",
"modified": "2026-09-10T15:10:12Z",
"published": "2026-09-10T15:10:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4v28-j6q3-5m4r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87996"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/28634"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/27402ff210bfa253445720920dfb86b15a00327b"
},
{
"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:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: SSRF into internal services via DNS rebinding in the Playwright web loader"
}
GHSA-4V64-W7V7-CH7F
Vulnerability from github – Published: 2023-07-10 18:30 – Updated: 2024-10-16 12:30An authenticated administrator is able to prepare an alert that is able to execute an SSRF attack. This is exclusively with POST requests.
{
"affected": [],
"aliases": [
"CVE-2021-42079"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-10T16:15:47Z",
"severity": "MODERATE"
},
"details": "An authenticated administrator is able to prepare an alert that is able to execute an SSRF attack. This is exclusively with POST requests.",
"id": "GHSA-4v64-w7v7-ch7f",
"modified": "2024-10-16T12:30:47Z",
"published": "2023-07-10T18:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42079"
},
{
"type": "WEB",
"url": "https://cisrt.divd.nl/DIVD-2021-00020"
},
{
"type": "WEB",
"url": "https://csirt.divd.nl/CVE-2021-42079"
},
{
"type": "WEB",
"url": "https://www.divd.nl/DIVD-2021-00020"
},
{
"type": "WEB",
"url": "https://www.osnexus.com/products/software-defined-storage"
},
{
"type": "WEB",
"url": "https://www.wbsec.nl/osnexus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N",
"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.