The Problem
It's Not About Vue vs React
Let me be upfront: I'm not choosing Nuxt because I dislike React. And not because Next.js is "full of holes." The reason is more mundane than that.
I currently have around 10 client projects in various stages of life. Some are in active development, others were shipped long ago and just run — budget closed, context long gone. When a critical security advisory drops in that situation, it's not one pnpm update. It's a task that multiplies: figure out which projects are affected, check the versions, update, verify nothing broke, coordinate the deploy with the client.
One project — manageable. Ten — noticeable.
That's exactly why I keep starting new client projects on Nuxt.
What I Mean by Security-Maintenance Cost
It's not a standard term, but I use it for myself. Not "how secure is the framework in the abstract," but how much time it actually takes to keep it secure across several live projects.
That depends on a few things: how often security patches come out, how urgent they are, whether they break project behavior, whether you can update a minor version without a migration, how many parallel projects are in the crossfire, and whether the client has a maintenance budget.
For me this turns into a concrete question: can I, a year after launch, quickly and without panic update a project that's been sitting idle for months?
Nuxt vs Next.js
Why Next.js Has Started Feeling Heavier
Next.js hasn't just been a framework with SSR for a long time. It's a server platform: App Router, React Server Components, middleware, Server Actions, cache and revalidation, image optimization, edge and node runtimes. Each of those layers has its own security responsibilities. And the more layers there are, the more often patches touch production behavior rather than just dependencies.
In late 2025, React disclosed a critical vulnerability in React Server Components (CVE-2025-55182, CVSS 10.0) — an unauthenticated RCE. Next.js was listed among the affected frameworks, with an immediate upgrade recommended. Then it turned out the first patch was incomplete: additional advisories followed covering DoS and source-code exposure, again with an urgent upgrade recommendation.
Alongside that, Next.js had its own: an authorization bypass in middleware with CVSS 9.1, and a middleware/proxy bypass via segment-prefetch routes — the latter as recently as May 2026.
I have no complaint about vulnerabilities being found in popular projects — that's normal for any living codebase. The issue is different: when a framework grows a complex model of caching, routing, and server/client boundaries, security patches start touching not abstract corner cases, but how authorization actually works or what gets included in a prefetch response. You can't skip those.
Why This Hurts Especially in Client Projects
Advisories say "upgrade immediately." In practice, that means:
- Find which projects are affected and on what versions
- Check the lockfile, understand what exactly needs updating
- Update the dependencies
- Deal with breaking changes or behavior differences
- Run the test suite — if one exists
- Manually check auth, forms, SSR, middleware, cache
- Coordinate a deployment window with the client
- After deploying, make sure nothing fell apart
If it's my own product, I can budget time for this. If it's a client project that was shipped and closed six months ago, it's harder. You have to rebuild context. The client doesn't always understand why they're paying for "technical updates." And the urgency doesn't wait.
Security advisories say "upgrade immediately." In practice, that means an evening with someone else's project you haven't opened in six months.
Why Nuxt Feels Calmer for My Needs
To be clear upfront: not because Nuxt is "secure by default." It's just that its mental model is easier for me to hold in my head.
In Nuxt, you can see where everything lives. There are pages, server routes, middleware, Nitro. It's a full full-stack setup, but with more explicit boundaries. After an update, I can quickly figure out which part to look at. Less RSC-specific logic. Fewer questions like "is this running on the client or the server, and does it affect the cache."
For client projects this matters for another reason too — other developers will read the code later. Explaining "here's a server route, here's middleware, here's the Nitro config" is simpler than walking someone through the difference between RSC, Server Actions, client component boundaries, and why this particular request goes through edge instead of node.
When operational complexity is lower, patches tend to touch more predictable layers. Not a guarantee, but in my experience — a noticeable difference.
But Nuxt Isn't Clean Either
Worth saying plainly, otherwise this reads like a promo piece.
The nuxt/nuxt security advisories have real stories: cache poisoning DoS, source-code exposure via the dev server, XSS in navigateTo, path traversal in Nuxt DevTools. In April 2026, Nitro picked up moderate advisories — open redirect and proxy scope bypass via routeRules.
If your project has SSR, server routes, a CDN, user-generated content, preview mode, or custom routeRules — the attack surface is real. The difference for me isn't that Nuxt is "secure." It's that its operational complexity in typical projects is lower. Updates are less likely to touch something unexpected.
When to Choose What
When I'd Still Pick Next.js
If the team writes React — there's no point bringing Vue in without a specific reason. If the project is heavily tied to the React ecosystem — shadcn/ui, Radix, TanStack — Next.js fits more naturally. Vercel-first infrastructure changes the calculation too.
The main thing: if the project has a real maintenance process — Renovate or Dependabot, staging, tests, a specific person responsible for keeping things updated — Next.js is a perfectly fine choice. In that case an advisory becomes a scheduled task, not an emergency evening.
My issue isn't with Next.js as a tool. It's with the situation where that tool gets used in projects that nobody ends up maintaining systematically.
My Current Choice by Project Type
Personal site or blog — Astro or Nuxt: less runtime, fewer future patches. Small client site — Nuxt or Astro: easier to keep in your head and update. Dashboard or SaaS MVP — Nuxt: good balance of full-stack and DX. React-heavy product with a team — Next.js: the stack and ecosystem matter more. Vercel-first project — Next.js: less friction with the platform. Project with no maintenance budget — minimal runtime: fewer urgent patches down the road.
Not Fear — Cost of Ownership
Vulnerabilities will show up everywhere: in Next.js, in Nuxt, in Nitro, in whatever framework ships two years from now. That's not an argument against any tool — it's just how it works.
I'm not choosing Nuxt out of fear of CVEs. I choose it more often because for most of my work it gives a more predictable cost of ownership. The clearer the server model and the fewer layers between request and response, the easier it is to maintain a project a year after launch.
The best framework isn't the one that looks most powerful on day one. It's the one you can still calmly update a year later.