· 7 min read

Vercel Found 7 Vulnerabilities in Cloudflare's AI-Written Next.js Clone. Two Critical. This Is the Vibe-Coded-Infra Bill Coming Due.

Cloudflare built an experimental Next.js alternative called vinext, written almost entirely by Claude, by a single engineer, over roughly a week, with minimal human code review. Then Vercel, which maintains Next.js and has an obvious axe to grind, went through it and disclosed seven vulnerabilities: two critical, two high, two medium, one low. The framing everyone reached for was "turf war," and sure, the Cloudflare-versus-Vercel needle is real. But the turf war is the sideshow. The signal is the distribution of those seven holes, because it maps almost exactly onto where AI-generated code keeps failing, and you're shipping AI-generated code too.

What got found, and why the shape matters

Two criticals in a week-old framework isn't surprising on its own; new infrastructure has bugs. What's instructive is the kind of bug. This lines up with what security researchers have been documenting all year: AI coding agents are reasonably competent at the well-known vulnerability classes (SQL injection, cross-site scripting, the stuff with a million labeled examples in the training data) and they fall down on authorization and business logic. A January 2026 test of five major AI coding agents found dozens of vulnerabilities across them, with the same pattern: the models patch the textbook holes and miss the ones that require understanding what your application is actually supposed to allow.

That distinction is the entire post, so let me make it concrete. "Should this input be escaped before it hits the page" is a pattern-matching problem, and the model is good at pattern matching. "Should this user be allowed to read this record" is not a pattern-matching problem. It depends on your domain, your roles, your intent: none of which is in the code the way an unescaped string is. The model has no way to know that the getInvoice handler is supposed to check that the invoice belongs to the requesting org, because "supposed to" lives in your head, not in the function signature. So it writes a handler that works, ships clean in every demo, and quietly serves invoice #4012 to whoever asks for it.

Why a solo operator should care more, not less

It would be easy to read this as a story about big companies and dismiss it. It's the opposite. Cloudflare had an actual engineer driving and Vercel's security team doing the review that surfaced these. You have neither. When you let Claude or Cursor scaffold an API route on a Tuesday night and it works in your manual test, there is no Vercel security team coming to audit it. The seven vulnerabilities in vinext got found because two well-resourced companies were motivated to look. The equivalent seven in your side project get found by whoever's probing your endpoints, and they're not going to file a disclosure.

I ship AI-written code every day, so I'm not throwing stones. The velocity is real and I'm not giving it up. But the mental model I had to correct is the one this story illustrates: the model gets you to "works," not to "safe," and those are different finish lines. "Works" means the happy path returns the right answer. "Safe" means the unhappy paths (the malformed input, the wrong user, the request that's authenticated but not authorized) are also handled. The model is genuinely good at the first and unreliable at the second, and it presents both with the exact same confidence. Nothing in the output tells you which parts it actually reasoned about and which parts it pattern-matched.

Where to spend your scarce review hours

If you accept that you can't review every line the model writes (and on a solo operation you can't, that's the whole reason you're using it) then the move is to stop reviewing uniformly and start reviewing by risk. Most of what an AI agent generates is low-stakes: a component, a utility, some glue. Skim it, run it, move on. The review budget you do have should go almost entirely to a short list of places.

Authorization checks are first. Every handler that returns data tied to a user or an org, ask the one question the model can't answer for itself: does this verify the requester is allowed to see exactly this record, or does it just fetch by ID and trust the caller? That's the getInvoice bug, and it's the most common serious flaw in AI-scaffolded backends because it requires knowing your rules. Anything touching auth, sessions, or tokens is second: the model will happily write a password reset flow that's missing a step, and it'll look complete. Anything that takes untrusted input and does something irreversible with it (payments, deletes, mass updates, deploys) is third.

Outside those, lean on tools instead of your eyes. A SAST scanner in CI catches a real chunk of the textbook classes for free. Dependency and secret scanning catches another. The point is to reserve your actual human attention for the authorization and business-logic decisions that no scanner and no model can make for you, because they depend on intent that only you have.

The honest counter-take

The fair pushback on all of this: vinext was a one-week experiment explicitly built to prove a point about AI-assisted development, not a production framework anyone was told to deploy. Holding it to production security standards is a little unfair, and Cloudflare would presumably harden it before it mattered. That's true, and I don't think this reflects badly on Cloudflare or on Claude. A week of AI-assisted work producing a mostly-working Next.js reimplementation is genuinely impressive, vulnerabilities and all.

But "it was just an experiment" is exactly the trap for the rest of us, because our experiments have a way of becoming production. The side project you vibe-coded over a weekend gets a paying user, then ten, and the auth code you never really reviewed is now guarding real data. The discipline isn't "don't use AI to build." It's "decide in advance which parts you'll review like an adult, and actually do it before the experiment quietly becomes the product." The model writes the code. Authorization is still your job.

Author

Sources

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts