GHSA-3g8h-86w9-wvmq
LOWGHSA-3g8h-86w9-wvmq is a low-severity (CVSS 3.7) vulnerability in next. O3 Security confirms whether GHSA-3g8h-86w9-wvmq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Next.js's Middleware / Proxy redirects can be cache-poisoned
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
nextnpmDescription
Impact
Next.js uses the x-nextjs-data request header for internal data requests. On affected versions, an external client could send this header on a normal request to a path handled by middleware that returns a redirect.
When that happened, the middleware/proxy could treat the request as a data request and replace the standard Location redirect header with the internal x-nextjs-redirect header. Browsers do not follow x-nextjs-redirect, so the response became an unusable redirect for normal clients.
If the application was deployed behind a CDN or reverse proxy that caches 3xx responses without varying on this header, a single attacker request could poison the cached redirect response for the affected path. Subsequent visitors could then receive a cached redirect response without a Location header, causing a denial of service for that redirect path until the cache entry expired or was purged.
Affected scenarios
This affects applications that:
- use middleware or proxy redirects
- are deployed behind a caching CDN or reverse proxy
- allow 3xx responses on those paths to be cached without differentiating internal data requests from normal requests
Fix
The fix stops trusting x-nextjs-data by itself for middleware redirect handling. A request is now treated as an internal data request only when it is validated as such by internal routing state, preserving legitimate data-request redirect behavior while preventing external header injection from changing normal redirect responses.
Workarounds
Before upgrading, users can reduce risk by:
- configuring the CDN or reverse proxy to vary its cache key on
x-nextjs-datafor affected responses
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | next | ≥ 12.2.0&&< 15.5.16 | 15.5.16 |
| 📦npm | next | ≥ 16.0.0&&< 16.2.5 | 16.2.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for next. 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.
Fix
Update next to 15.5.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3g8h-86w9-wvmq is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-3g8h-86w9-wvmq 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-3g8h-86w9-wvmq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3g8h-86w9-wvmq in your dependencies?
O3 detects GHSA-3g8h-86w9-wvmq across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.