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.
5863 vulnerabilities reference this CWE, most recent first.
GHSA-34R3-9M95-VQ73
Vulnerability from github – Published: 2026-09-10 15:09 – Updated: 2026-09-10 15:09Summary
Open WebUI fetches user-supplied URLs on the server for RAG URL ingestion and web search, and screens the resolved addresses so internal destinations cannot be reached. That screen decided whether a destination was external by asking Python's standard library whether the address is globally routable. Several addresses reserved for internal use answer yes to that question, including 168.63.129.16, the Azure platform channel every Azure virtual machine can reach. Any authenticated user could therefore make the server issue requests to those addresses and read the responses back through the API.
Preconditions
- The affected paths are the server-side URL fetches: RAG URL ingestion and web search. Both require an authenticated, verified account. No administrator role and no special workspace permission are needed.
ENABLE_LOCAL_WEB_FETCHmust be at its default offalse. Setting it totruedisables the address screen by design, and internal destinations are reachable on purpose.WEB_FETCH_FILTER_LISTis empty by default in affected versions, so no operator-supplied block entry covered these addresses unless one was added by hand.- For the Azure platform channel specifically, the Open WebUI host must run on Azure (virtual machine, AKS, Container Apps or equivalent). That address is reachable from every Azure virtual machine regardless of network security group rules. On a host that is not on Azure the address routes nowhere and nothing is reachable through it.
Impact
An authenticated user could direct the server to issue GET requests at addresses reserved for internal use and receive the response body back in the API response, which also lands in the RAG context. On Azure that includes the platform channel, an endpoint the operator never intended to expose to application users. The same gap applied to the IPv4-translated range and to deprecated IPv6 site-local space, which on a host that routes them would reach internal services the same way.
What was observed is the reachability and the read-back. No specific credential or secret was retrieved from the Azure platform channel during this investigation, and this advisory does not claim one. Deployments not hosted on Azure are unaffected for the platform-channel address, and deployments running with local web fetch enabled were never protected by this screen in any version.
Fix
Fixed in https://github.com/open-webui/open-webui/pull/27823. Address screening no longer rests on the library's notion of a globally routable address alone: a default block list of reserved and internal-purpose ranges is applied to every resolved address, at URL validation and again at connection time on both HTTP transports, so it also covers redirect hops and DNS rebinding. Operators can extend the list through WEB_FETCH_FILTER_LIST, which is merged with the defaults and cannot remove them.
Root cause
backend/open_webui/retrieval/web/utils.py: the shared address screen used by every server-side fetch.POST /api/v1/retrieval/process/web: RAG URL ingestion, returns the fetched body to the caller.POST /api/v1/retrieval/process/web/search: web search, fetches each result.
The code ships in every build, so no optional component or feature flag limits which installations carry it.
The screen answered one question, whether an address is globally routable, and treated that answer as a proxy for whether the destination is external. Those are two different questions. The library classifies by IANA special-purpose registry membership, and the Azure platform channel is allocated out of ordinary public IPv4 space, so the library correctly reports it as global while in practice it is an internal endpoint of the host's own platform. Earlier hardening (GHSA-8x5v-cpv7-8jjp) extended the screen to unwrap IPv6 addresses that carry an IPv4 address inside them. That closed the encoded-address bypasses and left the underlying test unchanged, so an address that is public by registry and internal by convention still passed.
Proof of concept
As any verified user:
POST /api/v1/retrieval/process/web
{"url": "http://168.63.129.16/?comp=versions"}
On an affected version the address passes validation, the request is issued, and the response body is returned in the content field of the API response.
The screening code of each released version was exercised directly:
- 0.11.0:
168.63.129.16,::ffff:0:169.254.169.254andfec0::1all pass validation. - 0.11.1: all three are rejected, along with every alternative spelling of the same address (IPv4-mapped, IPv4-compatible, IPv4-translated, 6to4 and both NAT64 prefixes) and the obfuscated decimal, octal and hexadecimal forms. Ordinary public addresses continue to pass.
No request was issued to a live Azure platform channel. The read-back property was confirmed from the ingestion endpoint, which returns the fetched body to the caller in its response.
Credits
@NaorYaa reported that the Azure platform channel remained reachable after the previous hardening, and demonstrated the same gap for the IPv4-translated and IPv6 site-local ranges.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87999"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:09:36Z",
"nvd_published_at": "2026-09-09T22:18:48Z",
"severity": "HIGH"
},
"details": "## Summary\n\nOpen WebUI fetches user-supplied URLs on the server for RAG URL ingestion and web search, and screens the resolved addresses so internal destinations cannot be reached. That screen decided whether a destination was external by asking Python\u0027s standard library whether the address is globally routable. Several addresses reserved for internal use answer yes to that question, including 168.63.129.16, the Azure platform channel every Azure virtual machine can reach. Any authenticated user could therefore make the server issue requests to those addresses and read the responses back through the API.\n\n## Preconditions\n\n- The affected paths are the server-side URL fetches: RAG URL ingestion and web search. Both require an authenticated, verified account. No administrator role and no special workspace permission are needed.\n- `ENABLE_LOCAL_WEB_FETCH` must be at its default of `false`. Setting it to `true` disables the address screen by design, and internal destinations are reachable on purpose.\n- `WEB_FETCH_FILTER_LIST` is empty by default in affected versions, so no operator-supplied block entry covered these addresses unless one was added by hand.\n- For the Azure platform channel specifically, the Open WebUI host must run on Azure (virtual machine, AKS, Container Apps or equivalent). That address is reachable from every Azure virtual machine regardless of network security group rules. On a host that is not on Azure the address routes nowhere and nothing is reachable through it.\n\n## Impact\n\nAn authenticated user could direct the server to issue GET requests at addresses reserved for internal use and receive the response body back in the API response, which also lands in the RAG context. On Azure that includes the platform channel, an endpoint the operator never intended to expose to application users. The same gap applied to the IPv4-translated range and to deprecated IPv6 site-local space, which on a host that routes them would reach internal services the same way.\n\nWhat was observed is the reachability and the read-back. No specific credential or secret was retrieved from the Azure platform channel during this investigation, and this advisory does not claim one. Deployments not hosted on Azure are unaffected for the platform-channel address, and deployments running with local web fetch enabled were never protected by this screen in any version.\n\n## Fix\n\nFixed in https://github.com/open-webui/open-webui/pull/27823. Address screening no longer rests on the library\u0027s notion of a globally routable address alone: a default block list of reserved and internal-purpose ranges is applied to every resolved address, at URL validation and again at connection time on both HTTP transports, so it also covers redirect hops and DNS rebinding. Operators can extend the list through `WEB_FETCH_FILTER_LIST`, which is merged with the defaults and cannot remove them.\n\n## Root cause\n\n- `backend/open_webui/retrieval/web/utils.py`: the shared address screen used by every server-side fetch.\n- `POST /api/v1/retrieval/process/web`: RAG URL ingestion, returns the fetched body to the caller.\n- `POST /api/v1/retrieval/process/web/search`: web search, fetches each result.\n\nThe code ships in every build, so no optional component or feature flag limits which installations carry it.\n\nThe screen answered one question, whether an address is globally routable, and treated that answer as a proxy for whether the destination is external. Those are two different questions. The library classifies by IANA special-purpose registry membership, and the Azure platform channel is allocated out of ordinary public IPv4 space, so the library correctly reports it as global while in practice it is an internal endpoint of the host\u0027s own platform. Earlier hardening (GHSA-8x5v-cpv7-8jjp) extended the screen to unwrap IPv6 addresses that carry an IPv4 address inside them. That closed the encoded-address bypasses and left the underlying test unchanged, so an address that is public by registry and internal by convention still passed.\n\n## Proof of concept\n\nAs any verified user:\n\n```\nPOST /api/v1/retrieval/process/web\n{\"url\": \"http://168.63.129.16/?comp=versions\"}\n```\n\nOn an affected version the address passes validation, the request is issued, and the response body is returned in the `content` field of the API response.\n\nThe screening code of each released version was exercised directly:\n\n- 0.11.0: `168.63.129.16`, `::ffff:0:169.254.169.254` and `fec0::1` all pass validation.\n- 0.11.1: all three are rejected, along with every alternative spelling of the same address (IPv4-mapped, IPv4-compatible, IPv4-translated, 6to4 and both NAT64 prefixes) and the obfuscated decimal, octal and hexadecimal forms. Ordinary public addresses continue to pass.\n\nNo request was issued to a live Azure platform channel. The read-back property was confirmed from the ingestion endpoint, which returns the fetched body to the caller in its response.\n\n## Credits\n\n@NaorYaa reported that the Azure platform channel remained reachable after the previous hardening, and demonstrated the same gap for the IPv4-translated and IPv6 site-local ranges.",
"id": "GHSA-34r3-9m95-vq73",
"modified": "2026-09-10T15:09:36Z",
"published": "2026-09-10T15:09:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-34r3-9m95-vq73"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87999"
},
{
"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:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Any authenticated user can reach the Azure platform channel via server-side web fetch"
}
GHSA-34R6-XM35-5VCX
Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2024-04-04 02:45LuquidPixels LiquiFire OS 4.8.0 allows SSRF via the call%3Durl substring followed by a URL in square brackets.
{
"affected": [],
"aliases": [
"CVE-2019-20055"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-29T05:15:00Z",
"severity": "MODERATE"
},
"details": "LuquidPixels LiquiFire OS 4.8.0 allows SSRF via the call%3Durl substring followed by a URL in square brackets.",
"id": "GHSA-34r6-xm35-5vcx",
"modified": "2024-04-04T02:45:49Z",
"published": "2022-05-24T17:05:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20055"
},
{
"type": "WEB",
"url": "https://code610.blogspot.com/2019/12/testing-ssrf-in-liquifireos.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-34W8-JP4P-57MJ
Vulnerability from github – Published: 2022-05-14 02:59 – Updated: 2022-05-14 02:59Adobe Experience Manager versions 6.4 and earlier have a Server-Side Request Forgery vulnerability. Successful exploitation could lead to sensitive information disclosure.
{
"affected": [],
"aliases": [
"CVE-2018-12809"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-20T19:29:00Z",
"severity": "HIGH"
},
"details": "Adobe Experience Manager versions 6.4 and earlier have a Server-Side Request Forgery vulnerability. Successful exploitation could lead to sensitive information disclosure.",
"id": "GHSA-34w8-jp4p-57mj",
"modified": "2022-05-14T02:59:17Z",
"published": "2022-05-14T02:59:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12809"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/experience-manager/apsb18-23.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/104702"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-34XG-WGJX-8XPH
Vulnerability from github – Published: 2026-06-11 13:04 – Updated: 2026-07-15 21:58Impact
guzzlehttp/psr7 improperly interpreted malformed Host header values when constructing request URIs from inbound request data. This issue concerns inbound request parsing and server request construction. It does not require serializing a PSR-7 request, and it is not part of the normal outbound request-sending path used by guzzlehttp/guzzle.
A vulnerable flow is:
- An attacker controls a raw HTTP request or server variable containing a
Hostvalue. - The
Hostvalue contains URI authority delimiters, such astrusted.example@evil.example. guzzlehttp/psr7uses that value to construct a URI.- The URI parser treats the portion before
@as userinfo and the portion after@as the URI host. - The resulting PSR-7 request URI host differs from the original
Hostheader value.
For example, Host: trusted.example@evil.example can result in a PSR-7 URI whose host is evil.example, while the original Host header value remains trusted.example@evil.example.
Applications are affected if they parse attacker-controlled raw HTTP requests with GuzzleHttp\Psr7\Message::parseRequest() or the legacy 1.x GuzzleHttp\Psr7\parse_request() function, or if they build server requests from attacker-controlled server variables with GuzzleHttp\Psr7\ServerRequest::fromGlobals() or GuzzleHttp\Psr7\ServerRequest::getUriFromGlobals(), and then rely on the resulting URI host for routing, allow-list checks, credential selection, or forwarding decisions. Applications using guzzlehttp/psr7 only through Guzzle's standard HTTP client APIs are not expected to be affected. In affected forwarding or gateway scenarios, this may cause requests or credentials to be sent to an unintended host.
Patches
The issue is patched in 2.10.2 and later. 1.x is end-of-life and will not receive a patch.
Workarounds
If you cannot upgrade immediately, validate Host values before passing untrusted request data to Message::parseRequest(), legacy 1.x parse_request(), ServerRequest::fromGlobals(), or ServerRequest::getUriFromGlobals().
Accept only uri-host [ ":" port ]. Reject values containing whitespace, control characters, userinfo (@), path (/ or \), query (?), fragment (#), malformed IP literals or bracket syntax, or invalid port syntax.
Do not validate Host by prefixing it with http:// and passing it to parse_url(), because that can reinterpret malformed values as URI userinfo and host.
References
- https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2
- https://www.rfc-editor.org/rfc/rfc9112.html#section-3.3
- https://www.rfc-editor.org/rfc/rfc9110.html#section-4.2.4
- https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/psr7"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.10.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48998"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-11T13:04:53Z",
"nvd_published_at": "2026-06-11T13:16:33Z",
"severity": "MODERATE"
},
"details": "## Impact\n\n`guzzlehttp/psr7` improperly interpreted malformed `Host` header values when constructing request URIs from inbound request data. This issue concerns inbound request parsing and server request construction. It does not require serializing a PSR-7 request, and it is not part of the normal outbound request-sending path used by `guzzlehttp/guzzle`.\n\nA vulnerable flow is:\n\n1. An attacker controls a raw HTTP request or server variable containing a `Host` value.\n2. The `Host` value contains URI authority delimiters, such as `trusted.example@evil.example`.\n3. `guzzlehttp/psr7` uses that value to construct a URI.\n4. The URI parser treats the portion before `@` as userinfo and the portion after `@` as the URI host.\n5. The resulting PSR-7 request URI host differs from the original `Host` header value.\n\nFor example, `Host: trusted.example@evil.example` can result in a PSR-7 URI whose host is `evil.example`, while the original Host header value remains `trusted.example@evil.example`.\n\nApplications are affected if they parse attacker-controlled raw HTTP requests with `GuzzleHttp\\Psr7\\Message::parseRequest()` or the legacy 1.x `GuzzleHttp\\Psr7\\parse_request()` function, or if they build server requests from attacker-controlled server variables with `GuzzleHttp\\Psr7\\ServerRequest::fromGlobals()` or `GuzzleHttp\\Psr7\\ServerRequest::getUriFromGlobals()`, and then rely on the resulting URI host for routing, allow-list checks, credential selection, or forwarding decisions. Applications using `guzzlehttp/psr7` only through Guzzle\u0027s standard HTTP client APIs are not expected to be affected. In affected forwarding or gateway scenarios, this may cause requests or credentials to be sent to an unintended host.\n\n## Patches\n\nThe issue is patched in `2.10.2` and later. `1.x` is end-of-life and will not receive a patch.\n\n## Workarounds\n\nIf you cannot upgrade immediately, validate Host values before passing untrusted request data to `Message::parseRequest()`, legacy 1.x `parse_request()`, `ServerRequest::fromGlobals()`, or `ServerRequest::getUriFromGlobals()`.\n\nAccept only `uri-host [ \":\" port ]`. Reject values containing whitespace, control characters, userinfo (`@`), path (`/` or `\\`), query (`?`), fragment (`#`), malformed IP literals or bracket syntax, or invalid port syntax.\n\nDo not validate Host by prefixing it with `http://` and passing it to `parse_url()`, because that can reinterpret malformed values as URI userinfo and host.\n\n## References\n\n* https://www.rfc-editor.org/rfc/rfc9112.html#section-3.2\n* https://www.rfc-editor.org/rfc/rfc9112.html#section-3.3\n* https://www.rfc-editor.org/rfc/rfc9110.html#section-4.2.4\n* https://www.rfc-editor.org/rfc/rfc9110.html#section-7.2",
"id": "GHSA-34xg-wgjx-8xph",
"modified": "2026-07-15T21:58:09Z",
"published": "2026-06-11T13:04:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/psr7/security/advisories/GHSA-34xg-wgjx-8xph"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48998"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/guzzlehttp/psr7/CVE-2026-48998.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/psr7"
}
],
"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"
}
],
"summary": "guzzlehttp/psr7 has Host Confusion via Authority Reinterpretation"
}
GHSA-34XP-G284-RGGR
Vulnerability from github – Published: 2026-09-17 15:32 – Updated: 2026-09-17 15:32Dell OpenManage Server Administrator, versions prior to 11.1.0.3, contains a Server-Side Request Forgery (SSRF) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Server-side request forgery.
{
"affected": [],
"aliases": [
"CVE-2026-81446"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T15:16:52Z",
"severity": "HIGH"
},
"details": "Dell OpenManage Server Administrator, versions prior to 11.1.0.3, contains a Server-Side Request Forgery (SSRF) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Server-side request forgery.",
"id": "GHSA-34xp-g284-rggr",
"modified": "2026-09-17T15:32:18Z",
"published": "2026-09-17T15:32:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81446"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000506586/dsa-2026-403-security-update-for-dell-openmanage-server-administrator-omsa-network-access-vulnerabilitiesv"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3537-379X-X582
Vulnerability from github – Published: 2024-03-21 03:36 – Updated: 2024-11-08 00:30Server Side Request Forgery (SSRF) vulnerability in Likeshop before 2.5.7 allows attackers to view sensitive information via the avatar parameter in function UserLogic::updateWechatInfo.
{
"affected": [],
"aliases": [
"CVE-2024-24028"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-21T02:52:09Z",
"severity": "MODERATE"
},
"details": "Server Side Request Forgery (SSRF) vulnerability in Likeshop before 2.5.7 allows attackers to view sensitive information via the avatar parameter in function UserLogic::updateWechatInfo.",
"id": "GHSA-3537-379x-x582",
"modified": "2024-11-08T00:30:45Z",
"published": "2024-03-21T03:36:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24028"
},
{
"type": "WEB",
"url": "https://thanhlo.substack.com/p/khai-thac-lo-hong-cve-2024-24028"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-35C5-67FM-CPCP
Vulnerability from github – Published: 2025-08-19 20:41 – Updated: 2025-08-19 20:41Impact
The WP Crontrol plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in versions 1.17.0 to 1.19.1 via the wp_remote_request() function. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
It is not possible for a user without Administrator level access to exploit this weakness. It is not possible for an Administrator performing an attack to see the HTTP response to the request to their chosen URL, nor is it possible for them to time the response.
Patches
WP Crontrol version 1.19.2 makes the following changes to harden the URL cron event feature:
- URLs are now validated for safety with the
wp_http_validate_url()function upon saving. The user is informed if they save a cron event containing a URL that is not considered safe, and the HTTP request will not trigger when the event runs. - HTTP requests are now performed via the
wp_safe_remote_request()function in place ofwp_remote_request(). This prevents an SSRF being performed.
Workarounds
Update the WP Crontrol plugin for WordPress to version 1.19.2 or later. If you are not able to update immediately, remove any Administrator level users who are not fully trusted.
FAQ
Is my site at risk?
Your site is only at risk if an untrustworthy Administrator on your site decides to exploit this weakness in order to blindly send HTTP requests, either to external URLs or to internal services running on your server. These requests can only be performed asynchronously, which means the HTTP response cannot be seen nor timed, which significantly restricts the practical methods of exploiting this weakness.
Separately, it is not possible for an attacker with database level access on your server to tamper with a URL cron event and perform an SSRF due to the anti-tampering measures built in to WP Crontrol.
Thanks
This issue was identified by Jonas Benjamin Friedli and reported to the Wordfence Intelligence Bug Bounty Program.
Security bugs should be reported through the official WP Crontrol Vulnerability Disclosure Program on Patchstack. The Patchstack team helps validate, triage, and handle any security vulnerabilities.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "johnbillion/wp-crontrol"
},
"ranges": [
{
"events": [
{
"introduced": "1.17.0"
},
{
"fixed": "1.19.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8678"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-19T20:41:10Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe WP Crontrol plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in versions 1.17.0 to 1.19.1 via the `wp_remote_request()` function. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.\n\nIt is not possible for a user without Administrator level access to exploit this weakness. It is not possible for an Administrator performing an attack to see the HTTP response to the request to their chosen URL, nor is it possible for them to time the response.\n\n### Patches\n\nWP Crontrol version 1.19.2 makes the following changes to harden the URL cron event feature:\n\n* URLs are now validated for safety with the `wp_http_validate_url()` function upon saving. The user is informed if they save a cron event containing a URL that is not considered safe, and the HTTP request will not trigger when the event runs.\n* HTTP requests are now performed via the `wp_safe_remote_request()` function in place of `wp_remote_request()`. This prevents an SSRF being performed.\n\n### Workarounds\n\nUpdate the WP Crontrol plugin for WordPress to version 1.19.2 or later. If you are not able to update immediately, remove any Administrator level users who are not fully trusted.\n\n### FAQ\n\n#### Is my site at risk?\n\nYour site is only at risk if an untrustworthy Administrator on your site decides to exploit this weakness in order to blindly send HTTP requests, either to external URLs or to internal services running on your server. These requests can only be performed asynchronously, which means the HTTP response cannot be seen nor timed, which significantly restricts the practical methods of exploiting this weakness.\n\nSeparately, it is not possible for an attacker with database level access on your server to tamper with a URL cron event and perform an SSRF due to [the anti-tampering measures built in to WP Crontrol](https://wp-crontrol.com/docs/url-cron-events/).\n\n### Thanks\n\nThis issue was identified by [Jonas Benjamin Friedli](https://github.com/jFriedli) and reported to the Wordfence Intelligence Bug Bounty Program.\n\n[Security bugs should be reported through the official WP Crontrol Vulnerability Disclosure Program on Patchstack](https://patchstack.com/database/vdp/wp-crontrol). The Patchstack team helps validate, triage, and handle any security vulnerabilities.",
"id": "GHSA-35c5-67fm-cpcp",
"modified": "2025-08-19T20:41:10Z",
"published": "2025-08-19T20:41:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/johnbillion/wp-crontrol/security/advisories/GHSA-35c5-67fm-cpcp"
},
{
"type": "WEB",
"url": "https://github.com/johnbillion/wp-crontrol/commit/b085bd306588d7a9baed82de37f9d1818deafc44"
},
{
"type": "PACKAGE",
"url": "https://github.com/johnbillion/wp-crontrol"
},
{
"type": "WEB",
"url": "https://github.com/johnbillion/wp-crontrol/releases/tag/1.19.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "WP Crontrol Authenticated (Administrator+) plugin vulnerable to Blind Server-Side Request Forgery"
}
GHSA-35CQ-WV6V-88XF
Vulnerability from github – Published: 2026-03-31 15:31 – Updated: 2026-04-06 22:45Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-qxgf-hmcj-3xw3. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.3.28 contains a server-side request forgery vulnerability in the fal provider image-generation-provider.ts component that allows attackers to fetch internal URLs. A malicious or compromised fal relay can exploit unguarded image download fetches to expose internal service metadata and responses through the image pipeline.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.28"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-06T22:45:57Z",
"nvd_published_at": "2026-03-31T15:16:19Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-qxgf-hmcj-3xw3. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.28 contains a server-side request forgery vulnerability in the fal provider image-generation-provider.ts component that allows attackers to fetch internal URLs. A malicious or compromised fal relay can exploit unguarded image download fetches to expose internal service metadata and responses through the image pipeline.",
"id": "GHSA-35cq-wv6v-88xf",
"modified": "2026-04-06T22:45:57Z",
"published": "2026-03-31T15:31:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qxgf-hmcj-3xw3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34504"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/80d1e8a11a2ac118c7f7a70bba9c862b6141d928"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-server-side-request-forgery-via-unguarded-image-download-in-fal-provider"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A: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:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: OpenClaw affected by SSRF via unguarded image download in fal provider",
"withdrawn": "2026-04-06T22:45:57Z"
}
GHSA-35JM-RM2F-HPGJ
Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36Flyto2 Core before 2.28.0 contains a server-side request forgery guard bypass vulnerability that allows attackers to reach internal services by supplying URLs using the unblocked IPv6 address :: which the kernel routes to loopback identically to 0.0.0.0. Attackers can submit requests or trigger 302 redirects to to bypass the private IP range and blocked hostname checks inis_private_ip(), reaching services bound to IPv6 loopback across thehttp.get,http.request, andhttp.batch` modules.
{
"affected": [],
"aliases": [
"CVE-2026-73530"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T20:17:29Z",
"severity": "MODERATE"
},
"details": "Flyto2 Core before 2.28.0 contains a server-side request forgery guard bypass vulnerability that allows attackers to reach internal services by supplying URLs using the unblocked IPv6 address `::` which the kernel routes to loopback identically to `0.0.0.0`. Attackers can submit requests or trigger 302 redirects to ` to bypass the private IP range and blocked hostname checks in `is_private_ip()`, reaching services bound to IPv6 loopback across the `http.get`, `http.request`, and `http.batch` modules.",
"id": "GHSA-35jm-rm2f-hpgj",
"modified": "2026-08-13T21:36:11Z",
"published": "2026-08-13T21:36:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/security/advisories/GHSA-gc4h-hj7x-gp5p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73530"
},
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/releases/tag/v2.28.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/flyto2-core-ssrf-guard-bypass-via-is-private-ip"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/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-35RC-2VCV-R6Q5
Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. A remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.
{
"affected": [],
"aliases": [
"CVE-2026-15409"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T20:16:56Z",
"severity": "CRITICAL"
},
"details": "A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. A remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.",
"id": "GHSA-35rc-2vcv-r6q5",
"modified": "2026-07-14T21:32:16Z",
"published": "2026-07-14T21:32:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15409"
},
{
"type": "WEB",
"url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-15409"
}
],
"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"
}
]
}
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.