Nuxt's `navigateTo` and `reloadNuxtApp` functions had three distinct URL-handling weaknesses. First, `navigateTo` did not properly detect external URLs due to path-normalisation bypasses, allowing SSR open redirects by normalizing inputs like `/..//evil.com` to protocol-relative URLs that redirect cross-origin. Second, `navigateTo({ open: ... })` failed to block script protocols, enabling client-side script execution (reflected XSS) when user input with `javascript:` URLs was passed. Third, `reloadNuxtApp` incorrectly allowed protocol-relative URLs (e.g., `//evil.com`) to bypass script protocol checks, causing open redirects. These vulnerabilities impact apps forwarding user-controlled URLs to these APIs, risking phishing and OAuth token theft. Fixes were released in Nuxt 4.4.7 and 3.21.7 addressing all three issues.

The SSR open redirect in `navigateTo` can be exploited for phishing or OAuth code theft if user input is forwarded to it on the server side. The client-side script execution via `navigateTo({ open: ... })` enables reflected XSS in the application's origin when user-controlled URLs with script protocols are passed. The open redirect in `reloadNuxtApp` allows cross-origin redirects even with existing script protocol guards, posing similar phishing and token theft risks. These impacts depend on unsafe handling of user-controlled URLs in affected Nuxt applications.

A patch is available and should be applied by upgrading to Nuxt versions 4.4.7 or later, or 3.21.7 or later. Until patched, applications should validate redirect targets before passing them to `navigateTo` or `reloadNuxtApp`. For `navigateTo`, reject inputs where the normalized pathname starts with `//` or use an allow-list of known safe paths. For `navigateTo({ open: ... })`, reject URLs with protocols outside an allow-list (typically only `http:` and `https:`). For `reloadNuxtApp`, reject paths starting with `//` or where the resolved host differs from the current host. These mitigations reduce risk until official fixes are applied.