GHSA-c9cv-mq2m-ppp3: Nuxt: URL-handling weaknesses in `navigateTo` and `reloadNuxtApp`: SSR open redirect, client-side script execution via the `open` option, and protocol-relative bypass in `reloadNuxtApp`

Three weaknesses in Nuxt’s client-navigation URL handling, all reachable from documented public APIs (navigateTo and reloadNuxtApp):

1. SSR open redirect in navigateTo via path-normalisation bypass. navigateTo decided whether a target was external by inspecting the raw input with hasProtocol(..., { acceptRelative: true }). Inputs such as /..//evil.com, /.//evil.com, /%2e%2e//evil.com, or /app/..//evil.com slipped past that check because they start with /, but WHATWG URL parsing then normalised them to the protocol-relative pathname //evil.com. The normalised value was written to the Location response header and into the <meta http-equiv="refresh"> body of the SSR redirect page, so a victim’s browser would resolve the redirect cross-origin to the attacker’s host.

2. Client-side script execution via navigateTo({ open: ... }). The client-side early-open handler called window.open(toPath, ...) without applying the isScriptProtocol check that gates the normal navigateTo path. A target of javascript:... (or another script-capable scheme) passed to navigateTo(url, { open: { ... } }) therefore executed in the application’s origin instead of being rejected.

3. Open redirect in reloadNuxtApp via protocol-relative bypass. reloadNuxtApp({ path }) rejects script-capable protocols by parsing the path with new URL(path, window.location.href) and checking the resolved protocol against isScriptProtocol. Protocol-relative paths such as //evil.com resolve to the current page’s protocol (https:), which passes that check; the value is then assigned to window.location.href, which the browser treats as a cross-origin redirect. This is the same protocol-relative bypass family as (1), in a different sink.