NUXT · GHSA-w7gw-66vg-99gq · Package
FIX → 4.6.2
The getRouterParam and getRouterParams helpers in nuxt/server can return a different path segment than the one h3 matched when a request path contains an encoded question mark (%3F). An application that checks authorization with one param source and looks up a resource with another can pass the check for one resource and act on a different one.
first public Oct 16, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Exposure requires a Nuxt 4 application (4.6.0 to 4.6.2) that reads the same route parameter from two different sources and relies on them agreeing, such as an authorization check via getRouterParam and a resource lookup via event.context.params. Applications that read params only through one source are not affected, and the helpers did not exist before 4.6.0.
Not affected if below-4.6.0, no-route-param-auth-check, nuxt-3, single-param-source
Who cares h3, nitro, nuxt, server-routes
npm ls nuxt @nuxt/nitro-server; affected if they are >=4.6.0 <4.6.2.getRouterParam or getRouterParams used alongside event.context.params or another source for the same param, especially in authorization checks.getRouterParam and getRouterParams from nuxt/server return the route params that h3 matched, with their original percent-encoding preserved. To do so, they line up the raw request URL with the decoded path h3 routed on.
When a path segment contained an encoded question mark (%3F), h3 routed on the decoded path only up to that ?, but the raw URL was not cut at the same point. The helpers then read params from the wrong segments, so they could return a different value from the one h3 matched in event.context.params. Named ([id]), unnamed and catch-all ([...slug]) params are affected.
For example, with server/api/auth/[...slug].get.ts, a request to /api/auth/private%3Fignored/public is matched by h3 with slug set to private, while returned .
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
4.6.0 are not affected.Upgrade to 4.6.2
4.6.24.6.2getRouterParam(event, 'slug', { decode: true })publicAn application is affected if it uses the Nuxt helper for one decision (such as an authorization check) and h3's matched params, or another source, for another (such as selecting the resource). In that case a request can pass the check for one resource and act on another.
getRouterParam(s) from nuxt/server, or only through event.context.params / h3's helpers, are not affected.4.6.0. Earlier releases and Nuxt 3 are not affected.nuxt and @nuxt/nitro-server >=4.6.0 <4.6.2.
Fixed in nuxt@4.6.2. The helpers now rebuild params from exactly the path h3 routed on, and check that each value decodes to the param h3 matched. If any value does not, they return h3's params unchanged, so they can only return a different encoding of h3's match, never a different value.
Upgrade to nuxt@4.6.2. If you cannot upgrade:
%3F in a server middleware.