Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-5w89-w975-hf9q

MEDIUMFix: nitrojs/nitro#4222

GHSA-5w89-w975-hf9q is a medium-severity (CVSS 5.3) vulnerability in nitro. O3 Security confirms whether GHSA-5w89-w975-hf9q is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Nitro has a proxy scope bypass via percent-encoded path traversal in `routeRules`

Also known asCVE-2026-44373
Published
May 6, 2026
Updated
May 14, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed

Real-World Exposure

2 pkgs affected
📦nitro📦nitropack

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.

Description

A proxy route rule like:

routeRules: {
  "/api/orders/**": { proxy: { to: "http://upstream/orders/**" } }
}

is intended to limit the proxy to URLs under /api/orders/. Before the patch, an attacker could bypass that scope by sending percent-encoded path traversal (..%2f) in the URL, causing Nitro to forward a request that the upstream resolved outside the configured scope. Example exploit:

GET /api/orders/..%2fadmin%2fconfig.json

Nitro sees ..%2f as opaque characters at match time, the /api/orders/** rule matched, and the raw path was forwarded to the upstream as /orders/..%2fadmin/config.json. An upstream that decodes %2F to / then resolved .. and can serve /admin/config.json outside the intended scope.

Are you affected?

Users may be affected if ALL of the following are true:

  1. Their project uses Nitro's routeRules with a proxy entry ({ proxy: { to: "..." } }).
  2. The proxy to value uses a /** wildcard suffix to forward sub-paths.
  3. The upstream behind the proxy decodes %2F as / before routing or filesystem lookup.
  4. Proxy route rules are not handled natively at CDN (nitro v3 and vercel)

Whether the bypass actually leaks data depends on the upstream. Modern JS frameworks keep %2F opaque per RFC 3986 and are safe by construction.

  • Safe examples: H3 v2, Express v5, Hono v4 — modern JS frameworks keep %2F opaque per RFC 3986.
  • Vulnerable examples: naive imlementations that decodes the URL, static file servers, CGI dispatchers, Python os.path-based routing, anything sitting behind another layer that decodes %2F (common in microservice meshes).

Impact

Any HTTP path reachable from the Nitro server to the upstream could be requested, regardless of the configured /** scope. In typical deployments (API gateway, BFF, microservice proxy) this could expose internal admin endpoints, secrets endpoints, or other services the developer believed the scope rule fenced off.

Patched versions

Upgrade to one of:

The fix canonicalizes the incoming pathname before building the upstream URL and rejects requests with 400 Bad Request if the resolved path would escape the rule's base. The bytes forwarded upstream are unchanged when the request is allowed.

Note: the fix assumes the upstream does not double-decode percent-encoding. If your upstream decodes twice (%252F → %2F → /), it remains your responsibility to harden it. Single-decode is standard.

Credits

Reported by @mHe4am (@he4am on HackerOne) via the Vercel Open Source program.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npmnitroall versions3.0.260429-beta
📦npmnitropackall versions2.13.4

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nitro. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update nitro to 3.0.260429-beta or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5w89-w975-hf9q is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-5w89-w975-hf9q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-5w89-w975-hf9q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

A proxy route rule like: ```ts routeRules: { "/api/orders/**": { proxy: { to: "http://upstream/orders/**" } } } ``` is intended to limit the proxy to URLs under `/api/orders/`. Before the patch, an attacker could bypass that scope by sending percent-encoded path traversal (`..%2f`) in the URL, causing Nitro to forward a request that the upstream resolved outside the configured scope. Example exploit: ``` GET /api/orders/..%2fadmin%2fconfig.json ``` Nitro sees `..%2f` as opaque characters at match time, the `/api/orders/**` rule matched, and the raw path was forwarded to the upstream as `
O3 Security · Impact-Aware SCA

Is GHSA-5w89-w975-hf9q in your dependencies?

O3 detects GHSA-5w89-w975-hf9q across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works