Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN799 _____________________________________________________________________ DATE : 29/07/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Nuxt versions prior to 4.5.1, 3.21.10, @nuxt/devtools versions prior to 3.3.1. ===================================================================== https://nuxt.com/blog/v4-5-security _____________________________________________________________________ Nuxt 4.5.1 and 3.21.10 are out now, fixing several security issues, alongside a critical fix in @nuxt/devtools 3.3.1. We recommend upgrading as soon as possible. Daniel Roe @danielroe.dev We've released Nuxt 4.5.1 and Nuxt 3.21.10, security patch releases for the 4.x and 3.x release lines. We recommend upgrading now: npx nuxt upgrade --dedupe Refreshing your lockfile also pulls in @nuxt/devtools@3.3.1, which fixes a separate critical development-only issue, so make sure it updates too. If you can't upgrade to the patched releases for some reason (for example, you're pinned to an older release line), Socket has provided Certified Patches for Nuxt which can be applied across release lines as an interim measure. Upgrading remains the recommended fix. If you already upgraded for the earlier route rule advisory (CVE-2026-53721), you still need this release. One of the issues below is a regression introduced by that very fix, so being on 4.4.7+ or 3.21.7+ does not make you safe. 🔍 What's fixed The advisories linked below have the full details. In brief, with a note on whether you're likely to be affected: Server-side remote code execution via server island props (High) GHSA-9473-5f9j-94wq You're affected only if you have enabled vue.runtimeCompiler (which is off by default) and use server components or islands whose props can reach Vue's dynamic component resolution: , resolveDynamicComponent, h(), or a polymorphic as / asChild prop, such as the one @nuxt/ui exposes through reka-ui. In that setup, an attacker could inject a template key into island props and have Vue's runtime compiler execute arbitrary code in the server (Nitro) process. Because vue.runtimeCompiler is off by default, most applications are not affected, but where the preconditions are met the impact is full server-side remote code execution. Unauthorized component instantiation via server island props (Medium) GHSA-48hr-524c-v5w3 This is closely related, but does not require vue.runtimeCompiler, so it reaches more configurations. If a server island forwards an undeclared prop onto a polymorphic as root (the same @nuxt/ui / reka-ui pattern, including implicitly through Vue's attribute fallthrough), an attacker could pass a plain string such as { "as": "iframe" }, or the name of a globally-registered component, to instantiate an arbitrary HTML element or component. It does not allow code execution. Declaring the props your island accepts, or setting inheritAttrs: false on it, also prevents this. Route rule authorization bypass (High) GHSA-hxvh-4h3w-prp9 You're affected if you rely on routeRules with appMiddleware as an authorization gate and any rule key contains an uppercase character, whether derived from a page file like pages/Admin.vue or written explicitly as routeRules: { '/Admin': ... }. Case-insensitive routing (the default) served the page while the rule and its middleware were silently skipped. This is the regression mentioned above. Route rules now match case-insensitively, as vue-router does by default. If you intentionally relied on case-sensitive route-rule matching, set router.options.sensitive: true. Server component denial of service (High) GHSA-hxcr-hm88-mpq6 and GHSA-9pgf-384g-p7mv You're affected if your app uses server components or islands (the /__nuxt_island endpoint). An unauthenticated request could crash the server by expanding a v-for over a prop, or waste CPU parsing and hashing an oversized request body before it was rejected. Cross-user payload disclosure on cached pages (High) GHSA-wm8w-6qjm-cv43, 4.x only (>= 4.4.0; the 3.x line is not affected) You're affected if you use the cache, swr or isr route rules on authenticated pages that render user-specific data. The cached _payload.json could be served to a different user or an unauthenticated visitor, even though the HTML was correctly varied. After upgrading, purge any CDN or edge cache that may already hold a leaked _payload.json. The bad response can already be cached upstream, and upgrading alone won't evict it. Dev server path disclosure (Low) GHSA-7c4v-fwgw-9rf7 You're affected only if you run the dev server bound to a network interface (nuxi dev --host) on an untrusted network. The Chrome DevTools workspace endpoint disclosed the project's absolute path and a workspace UUID to a LAN client. Nuxt DevTools remote code execution (Critical, dev only) GHSA-279x-mwfv-vcqv, fixed in @nuxt/devtools@3.3.1 You're affected if you run nuxt dev with DevTools enabled. An unauthenticated RPC method exposed over the Vite HMR socket could run an arbitrary command on your machine, reachable from another process on your host, a LAN peer when using --host, or a malicious site you visit while the dev server is running. This never affects production, but please make sure your lockfile picks up the new version. 💚 Thanks Huge thanks to the researchers who reported these issues responsibly: Pig-Tail, sec-reex, DavidCarliez, manop55555, dinhvaren, quantumshiro, Saku0512 and TazmiDev. These reports came in through GitHub's private advisory process, with one reaching us through the Vercel OSS Bug Bounty program on HackerOne. For the server-side remote code execution, we also worked with teams at Vercel, Netlify and Cloudflare to provide early notice, so they could put protections in place ahead of this disclosure. If you believe you've found a vulnerability in Nuxt, please report it privately via the Security tab on the relevant repository, or email security@nuxtjs.org if that's not possible. We really appreciate responsible disclosure. ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================