Sign In

CVE-2026-44373

ADVISORY - github

Summary

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.

Common Weakness Enumeration (CWE)

ADVISORY - github

CWE-22⁠

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Impacted images

Advisories

GitHub

CREATED

UPDATED

ADVISORY IDGHSA-5w89-w975-hf9q⁠
EXPLOITABILITY SCORE

3.9

EXPLOITS FOUND
-
COMMON WEAKNESS ENUMERATION (CWE)
CWE-22⁠

CVSS SCORE

5.3medium
PackageTypeOS NameOS VersionAffected RangesFix Versions
nitropacknpm--<2.13.42.13.4
nitronpm--<3.0.260429-beta3.0.260429-beta

CVSS:3 Severity and metrics

The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification⁠.

The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.

The vulnerable system can be exploited without interaction from any user.

An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.

There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the impacted component.

There is no loss of trust or accuracy within the impacted component.

There is no impact to availability within the impacted component.