- Nuxt 4.6.0 to 4.6.3 can render a page for a path like //x/admin while server-side checks on /admin are skipped, according to the GitHub advisory.
- The flaw matters because access rules written as path checks can simply not apply. It is tracked as CVE-2026-128077 and fixed in nuxt 4.6.4.
- Upgrade to 4.6.4, or reject paths starting with // in middleware, and ask teams where access rules depend on path matching.
Two parts of a system read one address two ways
A security check is only as good as its agreement with the code it protects. This week's Nuxt advisory shows what happens when they disagree. The server's gatekeeper looked at one path. The page renderer served another.
Nuxt is a framework for building websites on top of Vue. Its advisory, published on the GitHub Advisory Database on November 13, describes an incomplete fix for an earlier flaw, GHSA-9v7c-q64q-vv33. The new flaw is tracked as CVE-2026-128077.
What the advisory says happened
Starting with version 4.6.0, Nuxt treats a request path that begins with // as a URL with a host name. So a request for //x/admin is rendered as the page at /admin.
Nitro, the server engine under Nuxt, reads the same request differently. For routing, route rules and server middleware, Nitro keeps the extra slashes and sees //x/admin. A check keyed on /admin does not match.
The advisory gives a concrete case. A handler scoped to one route makes /admin return 401. Yet requests for //x/admin and ///x/admin still get the admin page, plus the data it loads while the server builds the page.
Other controls fail the same way. Server middleware that tests whether the path starts with /admin is skipped. A redirect rule such as '/admin/**' to /login does not fire for //x/admin/secret. Per-route security headers, including Content-Security-Policy, are not sent.
The advisory says an unauthenticated attacker can exploit this. Because browsers transmit the path as typed, an ordinary link is all it takes to reach the page. The advisory does not report any exploitation in the wild.
Why the first fix missed it
The earlier fix, in version 4.6.3, covered dot segments. Those are path pieces like /../ that point to a different location. The // form was a second way to make the same mismatch, and it was not covered.
This is a common shape of failure. When a bug comes from two components disagreeing about what a request means, closing one disguise leaves the others. The durable fix removes the disagreement. Nuxt's patch does that: the renderer now uses the path exactly as Nitro matched it.
Think of two clerks who read the same address differently. One checks the guest list. The other shows the visitor to the room. Patching a single odd address helps only until the next odd address.
Who is affected, and who is not
The advisory limits the problem to page routes in Nuxt 4.6.x before 4.6.4. Handlers under server/api and server/routes are outside the problem, since Nitro does not match them for these paths. Middleware set through definePageMeta, and appMiddleware route rules, are also not affected. Those are matched against the resolved route.
Older releases behave differently. In Nuxt 3.x and in 4.0.0 through 4.5.x, the path goes to the page router as received. The advisory says these requests return a 404 there.
For context, WebPulse's September 2026 scan of the Tranco top 10,000 domains detected Nuxt on 111 of the 2,491 sites where a platform was identified, or 4.5%. That figure counts sites running Nuxt, not sites running an affected release.
What to do
The patch ships in @nuxt/nitro-server 4.6.4, a package that nuxt 4.6.4 pulls in. Upgrading is the first step.
The advisory also offers two stopgaps. A server middleware can reject request paths that start with //. Or a reverse proxy or CDN can merge repeated slashes before forwarding requests, which removes the mismatch. Either works only if it runs in front of the affected checks.
Leaders can put four questions to their teams:
Do we run Nuxt 4.6.0 to 4.6.3, and when will 4.6.4 ship? Which pages rely on server middleware or route rules to keep people out? Does anything sit in front of the application that normalises repeated slashes? And can we test protected pages with odd paths, rather than only the paths we expect?
The lesson is broader than one framework. An access rule that matches on text is a promise about how every layer reads that text. Test the promise with the strange inputs, not only the normal ones.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
