Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The redirectBack() utility in h3 validates that the Referer header shares the same origin as the request before using its pathname as the redirect Location. However, the pathname is not sanitized for protocol-relative paths (starting with //). An attacker can craft a same-origin URL with a double-slash path segment that passes the origin check but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain. Details The vulnerable code is in src/utils/response.ts:89-97: The root cause is a discrepancy between how the WHATWG URL parser and browsers handle double-slash paths: 1. new URL("http://target.com//evil.com/path").origin → "http://target.com" — origin check passes 2. new URL("http://target.com//evil.com/path").pathname → "//evil.com/path" — extracted as redirect location 3. Browser receives Location: //evil.com/path → interprets as protocol-relative URL → redirects to evil.com Attack scenario: The attacker shares a link like…
Recommended action: Upgrade to 2.0.1-rc.18 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The setChunkedCookie() and deleteChunkedCookie() functions in h3 trust the chunk count parsed from a user-controlled cookie value (chunkedN) without any upper bound validation. An unauthenticated attacker can send a single request with a crafted cookie header (e.g., Cookie: h3=chunked999999) to any endpoint using sessions, causing the server to enter an O(n²) loop that hangs the process. Details The chunked cookie system stores large cookie values by splitting them into numbered chunks. The main cookie stores a sentinel value chunkedN indicating how many chunks exist. When setting a new chunked cookie, the code cleans up any previous chunks that are no longer needed. The vulnerability is in getChunkedCookieCount() at src/utils/cookie.ts:244-249: This value is consumed without validation in the cleanup loop of setChunkedCookie() at src/utils/cookie.ts:182-190: The same issue exists in deleteChunkedCookie() at src/utils/cookie.ts:227-232: The exploit chain through sessions: 1.…
Recommended action: Upgrade to 2.0.1-rc.18 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The EventStream class in h3 fails to sanitize carriage return (\r) characters in data and comment fields. Per the SSE specification, \r is a valid line terminator, so browsers interpret injected \r as line breaks. This allows an attacker to inject arbitrary SSE events, spoof event types, and split a single push() call into multiple distinct browser-parsed events. This is an incomplete fix bypass of commit 7791538 which addressed \n injection but missed \r-only injection. Details The prior fix in commit 7791538 added sanitizeSingleLine() to strip \n and \r from id and event fields, and changed data formatting to split on \n. However, two code paths remain vulnerable: 1. data field — formatEventStreamMessage() (src/utils/internal/event-stream.ts:190-193) String.prototype.split("\n") does not split on \r. A string like "legit\revent: evil" remains as a single "line" and is emitted as: Per the SSE specification §9.2.6, \r alone is a valid line terminator. The browser parses this…
Recommended action: Upgrade to 2.0.1-rc.17 (pre-release) or 1.15.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mount() method in h3 uses a simple startsWith() check to determine whether incoming requests fall under a mounted sub-application's path prefix. Because this check does not verify a path segment boundary (i.e., that the next character after the base is / or end-of-string), middleware registered on a mount like /admin will also execute for unrelated routes such as /admin-public, /administrator, or /adminstuff. This allows an attacker to trigger context-setting middleware on paths it was never intended to cover, potentially polluting request context with unintended privilege flags. Details The root cause is in src/h3.ts:127 within the mount() method: When a sub-app is mounted at /admin, the check originalPathname.startsWith("/admin") returns true for /admin, /admin/, /admin/dashboard, but also for /admin-public, /administrator, /adminFoo, etc. The mounted sub-app's entire middleware chain then executes for these unrelated paths. A secondary instance of the same flaw exists…
Recommended action: Upgrade to 2.0.1-rc.17 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The serveStatic utility in h3 applies a redundant decodeURI() call to the request pathname after H3Event has already performed percent-decoding with %25 preservation. This double decoding converts %252e%252e into %2e%2e, which bypasses resolveDotSegments() (since it checks for literal . characters, not percent-encoded equivalents). When the resulting asset ID is resolved by URL-based backends (CDN, S3, object storage), %2e%2e is interpreted as .. per the URL Standard, enabling path traversal to read arbitrary files from the backend. Details The vulnerability is a conflict between two decoding stages: Stage 1 — H3Event constructor (src/event.ts:65-69): This correctly preserves %25 sequences by escaping them before decoding. A request for /%252e%252e/etc/passwd produces event.url.pathname = /%2e%2e/etc/passwd — the %25 was preserved so %252e became %2e (not .). Stage 2 — serveStatic (src/utils/static.ts:86-88): This applies a second decodeURI(), which decodes %2e → ., producing…
Recommended action: Upgrade to 1.15.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
serveStatic() in h3 is vulnerable to path traversal via percent-encoded dot segments (%2e%2e), allowing an unauthenticated attacker to read arbitrary files outside the intended static directory on Node.js deployments. Details The vulnerability exists in src/utils/static.ts at line 86: On Node.js, h3 uses srvx's FastURL class to parse request URLs. Unlike the standard WHATWG URL parser, FastURL extracts the pathname via raw string slicing for performance — it does not normalize dot segments (. / ..) or resolve percent-encoded equivalents (%2e). This means a request to /%2e%2e/ will have event.url.pathname return /%2e%2e/ verbatim, whereas the standard URL parser would normalize it to / (resolving .. upward). The serveStatic() function then calls decodeURI() on this raw pathname, which decodes %2e to ., producing /../. The resulting path containing ../ traversal sequences is passed directly to the user-provided getMeta() and getContents() callbacks with no sanitization or…
Recommended action: Upgrade to 2.0.1-rc.15 (pre-release) or 1.15.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
H3 NodeRequestUrl bugs Vulnerable pieces of code : The middleware is super safe now with just a logger and a middleware to block internal access. But there's one problems here at the logger . When it log out the or or It will lead to trigger one specials method The NodeRequestUrl is extends from FastURL so when we just access or trying to dump all data of this class . This function will be triggered !! And as debugging , the this.#url is null and will reach to this code : Where is the this.href comes from ? Because the this.#url is still null so this.#href is built up by : Yeah and this is untrusted data go . An attacker can pollute the Host header from requests lead overwrite the event.url . Middleware bypass What can be done with overwriting the event.url? Audit the code we can easily realize that the routeHanlder is found before running any middlewares So the handleRoute is fixed but when checking with middleware it check with the spoofed one lead to MIDDLEWARE BYPASS We have this…
Recommended action: Upgrade to 2.0.1-rc.15 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Timing Side-Channel vulnerability exists in the requireBasicAuth function due to the use of unsafe string comparison (!==). This allows an attacker to deduce the valid password character-by-character by measuring the server's response time, effectively bypassing password complexity protections. Details The vulnerability is located in the requireBasicAuth function. The code performs a standard string comparison between the user-provided password and the expected password: ~~~typescript if (opts.password && password !== opts.password) { throw autheFailed(event, opts?.realm); } ~~~ In V8 (and most runtime environments), the !== operator is optimized to "fail fast." It stops execution and returns false as soon as it encounters the first mismatched byte. If the first character is wrong, it returns immediately. If the first character is correct but the second is wrong, it takes slightly longer. By statistically analyzing these minute timing differences over many requests, an…
Recommended action: Upgrade to 2.0.1-rc.9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
createEventStream in h3 is vulnerable to Server-Sent Events (SSE) injection due to missing newline sanitization in formatEventStreamMessage() and formatEventStreamComment(). An attacker who controls any part of an SSE message field (id, event, data, or comment) can inject arbitrary SSE events to connected clients. Details The vulnerability exists in src/utils/internal/event-stream.ts, lines 170-187: The SSE protocol (defined in the WHATWG HTML spec) uses newline characters (\n) as field delimiters and double newlines (\n\n) as event separators. None of the fields (id, event, data, comment) are sanitized for newline characters before being interpolated into the SSE wire format. If any field value contains \n, the SSE framing is broken, allowing an attacker to: 1. Inject arbitrary SSE fields — break out of one field and add event:, data:, id:, or retry: directives 2. Inject entirely new SSE events — using \n\n to terminate the current event and start a new one 3. Manipulate…
Recommended action: Upgrade to 2.0.1-rc.15 (pre-release) or 1.15.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
I was digging into h3 v1 (specifically v1.15.4) and found a critical HTTP Request Smuggling vulnerability. Basically, readRawBody is doing a strict case-sensitive check for the Transfer-Encoding header. It explicitly looks for "chunked", but per the RFC, this header should be case-insensitive. The Bug: If I send a request with Transfer-Encoding: ChuNked (mixed case), h3 misses it. Since it doesn't see "chunked" and there's no Content-Length, it assumes the body is empty and processes the request immediately. This leaves the actual body sitting on the socket, which triggers a classic TE.TE Desync (Request Smuggling) if the app is running behind a Layer 4 proxy or anything that doesn't normalize headers (like AWS NLB or Node proxies). Vulnerable Code (src/utils/body.ts): I verified this locally: - Sent a Transfer-Encoding: ChunKed request without a closing 0 chunk. - Express hangs (correctly waiting for data). - h3 responds immediately (vulnerable, thinks body is length 0). Impact:…
Recommended action: Upgrade to 1.15.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.