SchwachstellendatenbankGHSA-rhhp-7488-3qwf

GHSA-rhhp-7488-3qwf: 
JavaScript Schwachstellenanalyse und -minderung

Summary

The fix for CVE-2026-44373 (GHSA-5w89-w975-hf9q) added isPathInScope() so a proxy route rule with a /** target rejects requests whose canonical path leaves the rule's base. The check validates a canonicalized form of the incoming request path. Nitro then forwards a different value: the raw path with the base stripped by withoutBase() and joined under the target base. Two payload shapes pass the check while the forwarded path still contains a ..%2F that an upstream resolves outside the configured target prefix:

  1. Empty // segment: GET /api//..%2fadmin. The check resolves .. against the empty segment (/api//../admin → /api/admin, in scope). withoutBase then removes the empty segment and forwards /safe/..%2fadmin, which the upstream resolves to /admin. Chaining (//..%2f//..%2f…) climbs several levels, up to the upstream root.
  2. Leave and re-enter the prefix: GET /proxy/..%2fproxy%2fadmin. The canonical path /proxy/admin is in scope for /proxy. Nitro forwards /safe/..%2Fproxy%2Fadmin, which the upstream resolves to /proxy/admin, outside /safe. This works whenever the public prefix and the target prefix differ.

Details

Affected code (nitropack v2):

  • src/runtime/internal/route-rules-utils.ts, isPathInScope(): pre-decodes %2f/%5c, then lets new URL() resolve dot segments. Empty segments are kept and consumed by ...
  • src/runtime/internal/route-rules.ts, proxy branch: after the check passes it forwards joinURL(target.slice(0, -3), withoutBase(event.path, strpBase)). That is the raw request path, not the value that was validated.
  • src/runtime/internal/route-rules.ts, redirect branch: same check-then-forward pattern. The check validates the request path against the rule base, but nothing validates the final upstream URL against the target base. Any difference between the two readings can be exploited.

Proof of concept

Config:

export default defineNitroConfig({
  routeRules: {
    "/api/**": { proxy: { to: "http://127.0.0.1:8080/safe/**" } },
    "/proxy/**": { proxy: { to: "http://127.0.0.1:8080/safe/**" } },
  },
});

The upstream is any server that decodes %2F once and then normalizes, for example Python's http.server.

Request (curl --path-as-is)Forwarded upstreamUpstream resolvesResult
/api/hello/safe/hello/safe/hello200 (normal)
/api/..%2fadmin——400 (original CVE, blocked)
/api//..%2fadmin/safe/..%2fadmin/admin200, bypass
/api//%2e%2e%2fadmin/safe/%2e%2e%2fadmin/admin200, bypass
/api/orders//..%2f//..%2f//..%2froot-secret.json (rule /api/orders/** → /orders/**)/orders/..%2f//..%2f//..%2froot-secret.json/root-secret.json200, bypass
/proxy/..%2fproxy%2fadmin/safe/..%2fproxy%2fadmin/proxy/admin200, bypass

Impact

An unauthenticated remote attacker can make Nitro forward requests to upstream paths outside the path prefix that a /** proxy rule is meant to confine forwarding to, such as internal or admin endpoints on the same upstream. The HTTP method and body are forwarded, so both reads and state-changing requests are possible. Wildcard redirect rules have the same scope gap, but there the result is only a redirect to another same-origin path outside the rule's target prefix. You are affected only if all of these are true:

  • you use nitropack v2 (including Nuxt 3 and 4 on nitropack 2) with a proxy route rule whose target ends in /** and has a non-root path prefix;
  • the upstream decodes %2F and resolves dot segments (many do, including Python http.server and some static servers and frameworks);
  • the upstream relies on that prefix to restrict what is publicly reachable.

Patches

Fixed in nitropack 2.13.6. Nitro now validates the final upstream (or redirect) URL against the rule's target base, after the forwarded path has been built.

Workarounds

If you cannot upgrade:

  • configure the upstream to reject encoded slashes (%2F) and dot segments in paths;
  • enforce authorization in the upstream itself instead of relying on the proxied path prefix.

Quelle: NVD

Verwandte Themen JavaScript Schwachstellen:

CVE-ID

Schwere

Punktzahl

Technologieen

Bauteilname

CISA KEV-Exploit

Hat Lösung

Veröffentlichungsdatum

GHSA-rhhp-7488-3qwfMEDIUM6.5
  • JavaScript logoJavaScript
  • nitropack
NeinJaNov 02, 2026
GHSA-pqxc-r4h5-jc95MEDIUM6.1
  • JavaScript logoJavaScript
  • nitropack
NeinJaNov 02, 2026
GHSA-39r7-wfcx-99xgMEDIUM4.8
  • JavaScript logoJavaScript
  • nitropack
NeinJaNov 02, 2026
GHSA-xrjv-fc7j-8f77HIGHN/A
  • JavaScript logoJavaScript
  • @graphql-tools/batch-execute
NeinNeinNov 02, 2026
GHSA-7p5p-67m9-5c8jHIGHN/A
  • JavaScript logoJavaScript
  • @graphql-tools/executor-http
NeinNeinNov 02, 2026

Kostenlose Verwundbarkeitsbewertung

Benchmark für Ihre Cloud-Sicherheitslage

Bewerten Sie Ihre Cloudsicherheitspraktiken in 9 Sicherheitsbereichen, um Ihr Risikoniveau zu bewerten und Schwachstellen in Ihren Verteidigungen zu identifizieren.

Anforderungsbewertung

Zusätzliche Wiz-Ressourcen

Eine personalisierte Demo anfordern

Sind Sie bereit, Wiz in Aktion zu sehen?

"Die beste Benutzererfahrung, die ich je gesehen habe, bietet vollständige Transparenz für Cloud-Workloads."
David EstlickCISO
"„Wiz bietet eine zentrale Oberfläche, um zu sehen, was in unseren Cloud-Umgebungen vor sich geht.“ "
Adam FletcherSicherheitsbeauftragter
"„Wir wissen, dass, wenn Wiz etwas als kritisch identifiziert, es auch wirklich kritisch ist.“"
Greg PoniatowskiLeiter Bedrohungs- und Schwachstellenmanagement