Security news
Nuxt route-rule bug: check the protection behind your login redirect
Vibe App Scanner ·
If your AI-built app uses Nuxt, review the code behind its login redirect before calling a security update complete. Start with the installed framework version, identify where access is enforced, and keep a short record of the deployed checks. A redirect working in your usual browser session is only one observation.
What Nuxt reports
Nuxt's advisory for CVE-2026-114132 describes a mismatch: case-insensitive page routing could serve a page while case-sensitive server route rules failed to match. Redirects and per-route security headers were among the affected controls. The advisory identifies Nuxt versions below 4.6.2, including Nuxt 3, as affected; 4.6.2 contains the fix. It says Nuxt 3 will not receive a fix. Separate access checks in server middleware, page data fetching, or route middleware attached with definePageMeta are not affected by this particular issue. Nuxt's advisory.
The 4.6.2 release notes also list the server route-rule matching fix. These are two records from the same project, rather than independent confirmation of exploitation.
Ask your coding assistant for a protection inventory
Before requesting a patch, ask for an explanation of the existing implementation. Keep the task scoped to your own repository:
Find the Nuxt configuration, installed framework version, login redirects, protected page data loaders, and API authorization checks. For each protected resource, identify the code that checks the current user's permission. List anything you cannot verify. Propose changes for review without deploying them.
Review the answer against the files it names. A useful inventory is small enough to inspect:
| Resource | Evidence to record |
|---|---|
| A private page | Route, expected audience, and the permission-check location |
| Its data request | Endpoint or loader, test-account role, and access-check location |
| A route-specific response header | Configuration entry and observed response |
| The deployed app | Framework version, source revision, build ID, and environment |
Use masked identifiers and test data. Do not paste private records, session cookies, or credentials into an assistant prompt. If a claimed protection cannot be located, record the gap rather than accepting the assistant's summary as proof.
Make the upgrade a deployment task
Prefer an upgrade plan that reaches a supported Nuxt release containing the fix, with compatibility review and a fresh build. Keep the lockfile change, test results, and resulting deployment ID together.
If an upgrade is blocked, the vendor describes case-sensitive routing in nuxt.config as a workaround. Have the maintainer review it against your routes and links before rollout. Treat it as a tracked workaround with an owner and follow-up date. Vendor workaround guidance.
Check the result with harmless staging fixtures
The following is a suggested review procedure, not a report of testing VAS performed. Use an environment you own, synthetic records, and accounts created for the check. Avoid actions that write or delete data.
For a private staging page with a harmless name such as /team-demo, compare the ordinary spelling with a case variant such as /Team-demo. Check the direct request, rather than only navigating from the app menu. Repeat with a signed-out session, a permitted test account, and a test account that should lack access.
Record the outcome separately for the page and its data request:
| Check | What to record |
|---|---|
| Page access | Whether the result matches the intended permission rule for each test identity |
| Data access | Whether the underlying read request withholds the synthetic private record from unauthorized identities |
| Response policy | Whether each response carries the headers your configuration requires |
| Intended use | Whether the permitted account can still complete the ordinary read-only flow |
Agree the expected behavior before testing. A redirect, a denial, and a missing route are different observations; record which occurred and why it satisfies the intended policy. Reconcile unexpected results with the actual deployment configuration before treating the item as closed.
Keep the conclusion narrow
Retain the inventory and results with the deployment record. Add untested routes and environments to a follow-up list, so the evidence describes a bounded review rather than a claim about the whole application.
This advisory does not establish that your app was accessed or that AI introduced the flaw. These proposed checks cannot reconstruct past activity or prove every authorization path is correct. For a broader review, use our vibe coding security checklist. You can start a VAS scan as one part of that work; this article makes no claim that VAS detects this CVE or certifies its remediation.