A few days ago, two security researchers — zhero and inzo_ — dropped a vulnerability that might make you rethink how you use Next.js.
It’s has been assigned the CVE-2025-29927, and it’s about as serious as it sounds.
This flaw allows an attacker to bypass authorization entirely if your app relies on Next.js middleware to protect routes.
Yes — completely bypass it. No credentials. No session. No problem (for the attacker, anyway).
This vulnerability has been silently sitting in the Next.js codebase for years — since version 11.1.4, to be exact.
And if you're using any version since 11.1.4, chances are… you're vulnerable.
Let’s take a moment to let that sink in.
So What’s This All About?
At a high level, this vulnerability lets an attacker slip past middleware-based auth checks by crafting a specific kind of request.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N Score: 9.1 / 10 — Critical
A high-impact bug with a low barrier to exploitation — the kind that keeps security engineers up at night.
Why I Wrote This Post
When I first read the original disclosure, I was fascinated by how such a simple flaw could go unnoticed for so long in a framework used by millions. I wanted to understand it deeply, so I did what many of us do: I built a lab.
In this post, I'm sharing that lab with you.
I've created a deliberately vulnerable Next.js app that demonstrates this vulnerability in a safe, controlled environment. It’s meant to help developers, bug bounty hunters, and security pros learn by doing — because sometimes reading about a bug just isn’t enough.
You can clone it, run it locally, and see this middleware authorization bypass in action. No guessing, no assumptions — just raw, hands-on experience.
👉🏻 Check out the Deliberately Vulnerable Next.js App
But before you dive in, let’s walk through the high-level mechanics of how this exploit actually works — and why this isn’t just a bug, but a design oversight that teaches us something important about web app security.
How the exploit works
Imagine you’ve built a typical Next.js application with middleware-based authorization. You assume that this middleware runs on every request, guarding your private routes from unauthorized access.
export function middleware(request: NextRequest) {
const token = request.headers.get("x-super-secret-auth");
if (!token) {
return NextResponse.redirect(new URL('/wrong', request.url))
}
return NextResponse.next();
}Looks solid, right? You check for a custom header and redirect unauthorized users. Seems like a solid first layer of defense.
Now here’s the catch: Under certain conditions — due to how Next.js internally resolves routes and static assets — the middleware doesn't run at all.
The attacker doesn’t need to break your logic. They just need to sidestep it.
Yes, you read that right.
By sending a request with this header:
x-middleware-subrequest: middleware:middleware:middleware:middleware:middlewarea malicious actor can completely skip your middleware and access protected routes unauthenticated.
This is the heart of CVE-2025-29927.
Are You Affected?
If you're using Next.js version 11.1.4 or later, there's a strong chance you're vulnerable. Unless you've already updated to the latest patched release, your middleware-based authorization is not safe.
I highly recommend updating immediately. This is not a low-severity bug you can schedule for "some time next sprint" — this is a drop-everything-and-patch moment.
💬 Let’s Connect
If you found this post helpful, or if you want to chat more about this vulnerability, secure architecture, or anything at the intersection of development and security — I’d love to hear from you.
Feel free to reach out on LinkedIn
Always happy to connect with fellow developers, researchers, and security-minded folks.
Stay curious. Stay secure. 🔒🚀