DEV Community: Emil Alander

Next.js Middleware Auth Bypass: CVE-2025-29927

Emil Alander — Sun, 19 Jul 2026 18:44:06 +0000

A spoofable x-middleware-subrequest header let requests skip Next.js middleware, bypassing auth. Upgrade to the patched version; don't trust middleware alone.

TL;DR — CVE-2025-29927 is a critical (CVSS 9.1) authorization bypass in Next.js. The framework used an internal header, x-middleware-subrequest, to stop middleware from recursing — and it trusted that header even on requests coming from the outside. So an attacker could add x-middleware-subrequest to any request and Next.js would skip middleware entirely, sailing straight past any auth or redirect logic that lived there. The fix: upgrade Next.js to the patched release for your major (15.2.3, 14.2.25, 13.5.9, or 12.3.5). The deeper fix: never make middleware the sole authorization gate — re-check auth in the route handler, server action, and data layer too.

Is my Next.js app vulnerable to CVE-2025-29927?

If you run a self-hosted Next.js app (using next start or output: 'standalone') on an affected version, and you gate access to protected routes in middleware.ts, then yes — you were exposed.

The affected and patched ranges, straight from the GitHub advisory (GHSA-f82v-jwr5-mffw) and NVD:

Release line	Affected range	Fixed in
15.x	≥ 15.0.0, < 15.2.3	15.2.3
14.x	≥ 14.0.0, < 14.2.25	14.2.25
13.x	≥ 13.0.0, < 13.5.9	13.5.9
12.x / 11.x	≥ 11.1.4, < 12.3.5	12.3.5

The bug was introduced at 11.1.4. There is no separate 11.x patch — if you're on 11.x, you must move to 12.3.5 (or apply the header workaround and move auth out of middleware).

Check the resolved version, not the range in package.json — a caret range like "next": "^14.1.0" tells you what's allowed, not what's installed:

npx next --version   # the actually-resolved binary
npm ls next          # the lockfile-resolved version in the tree
npm audit            # flags GHSA-f82v-jwr5-mffw until you're patched

Who was NOT exposed: apps on Vercel and Netlify. Vercel's routing runs decoupled from the Next.js server, so the client-supplied header never reached the middleware evaluation the way it did in self-hosted setups. Static exports and Cloudflare Workers deployments were likewise not impacted.

How does the middleware bypass work?

Next.js middleware runs before a request reaches a route — perfect for auth gating, redirects, and header rewriting. Internally, Next.js can re-invoke middleware as part of its own request handling, so it needs a way to stop that from recursing forever. It used an internal request header, x-middleware-subrequest, to flag a request as an internal subrequest and tell the framework to skip running middleware.

The flaw: that header was trusted unconditionally. Nothing verified it originated internally rather than from the client. Add the header to an inbound request and Next.js skips middleware — while still serving the underlying route. Any authorization decision in middleware was silently bypassed.

The expected value tracked how Next.js evolved its recursion guard (per source-level analyses from Datadog Security Labs and ProjectDiscovery):

Pre-12.2: the middleware file path, e.g. x-middleware-subrequest: pages/_middleware.
~12.2–13.1.x: a single value like middleware (or src/middleware for a src/ layout).
13.2.0+ / 14.x / 15.x: a recursion-depth guard that counts occurrences and skips once the count exceeds MAX_RECURSION_DEPTH (default 5), so the payload became the identifier repeated five times, colon-separated: middleware:middleware:middleware:middleware:middleware.

Remediation: upgrade first

The real remedy is upgrading Next.js to the patched release for your major line. Pin to at least the patched version so you get the fix without an unwanted major jump:

npm install next@14.2.25    # or next@^14.2.25 to take later patches on your major

A static dependency scanner flags exactly this — an outdated, vulnerable Next.js version sitting in package.json:

{
  "dependencies": {
    "next": "14.1.0",
    "react": "18.2.0",
    "react-dom": "18.2.0"
  }
}

(See GuardLayer's live scan flag that version as vulnerable on the original post.) Be precise about what that catches: the tool flags the outdated version — it does not detect the x-middleware-subrequest header spoof at the code level; nothing static in your handlers reveals that a header was trusted at the framework layer. The version flag is the actionable signal, and upgrading is the fix. For the broader picture, see auditing vulnerable npm dependencies.

If you can't upgrade immediately: strip the header at the edge

The advisory's documented workaround is to prevent external requests carrying x-middleware-subrequest from reaching your app. Because the header is what causes middleware to be skipped, the stripping must happen at a layer in front of the app.

nginx reverse proxy — clear any client-supplied value before forwarding upstream:

location / {
    proxy_set_header x-middleware-subrequest "";
    proxy_pass http://nextjs_upstream;
}

Cloudflare / generic WAF — block the request outright:

(any(http.request.headers.names[*] == "x-middleware-subrequest"))
# Action: Block

Caveats: this only protects paths that actually pass through that proxy — if your origin is reachable directly, the header sails through, so strip it at every ingress. HTTP header names are case-insensitive, so match regardless of casing. And it's a stopgap, not a repair of the underlying trust bug. (Cloudflare shipped a managed WAF rule on March 22, 2025 that blocks this header — but it's opt-in, not on by default, because auto-blocking broke sites whose third-party auth middleware legitimately relied on the header.)

The durable lesson: middleware is not your only authorization layer

Vercel's postmortem says it directly: "We do not recommend Middleware to be the sole method of protecting routes." Middleware is best for cheap, coarse redirects — bouncing an unauthenticated visitor toward a login page for nicer UX — not the last line of defense. Re-check authorization at the layer that actually returns the data:

// app/api/admin/users/route.ts
import { NextResponse } from "next/server";
import { getSession } from "@/lib/auth";

export async function GET() {
  const session = await getSession();               // re-check HERE, not just in middleware
  if (!session) return NextResponse.json({ error: "Unauthenticated" }, { status: 401 });
  if (session.user.role !== "admin") return NextResponse.json({ error: "Forbidden" }, { status: 403 });
  return NextResponse.json({ users: await db.user.findMany() });
}

Do the same in server components (redirect("/login") at render time) and in server actions, where auth must be verified inside the action itself. The strongest backstop is pushing authorization into a data-access layer and enabling database Row-Level Security, so a request that skips every application-layer check still can't read rows it doesn't own. That layered posture — covered in the Next.js app-layer security guide — is what turns a single-layer bug like CVE-2025-29927 into a non-event.

Confirm you're patched

Send the exploit header at a protected route and compare it to the same request without the header. On a patched build they must be identical — both denied:

curl -i https://your-app.example.com/admin -H "x-middleware-subrequest: middleware"
# Patched: same 302/401/403 as a request WITHOUT the header
# Vulnerable: returns the protected page (bypass succeeded)

If adding the header changes the outcome, you're still vulnerable.

I write these while building GuardLayer, a static scanner for Next.js + Supabase apps. Originally published on the GuardLayer blog.

Does Prisma respect Supabase RLS? No — here's why

Emil Alander — Sun, 19 Jul 2026 18:39:22 +0000

Prisma and Drizzle connect as the postgres role and bypass Supabase RLS entirely, so your policies never protect ORM queries. Here's the fix.

TL;DR: No. Prisma and Drizzle open their own direct Postgres connection and log in as the postgres role, which owns your tables and carries BYPASSRLS — so Row Level Security is skipped on every ORM query. Point your app's connection at a dedicated, non-owner NOBYPASSRLS role (and keep the auth check in your code), not at postgres.

If you built your Supabase project assuming RLS is a safety net on the data itself, adding an ORM quietly punches a hole straight through it. Your policies are still there. They just never run for the ORM's connection. Here's the mechanism, the myth to unlearn, and three fixes in order of how much you should reach for them.

Does Prisma respect Supabase RLS?

No. RLS is not a global property of the database — Postgres enforces it per role, per statement. A policy only bites for a role that is (a) not the table's owner, (b) has no BYPASSRLS attribute, and (c) is not a superuser. The Supabase JS client satisfies all three because it reaches Postgres through PostgREST, which runs your query as the unprivileged anon or authenticated role. Prisma and Drizzle satisfy none of them: they read DATABASE_URL and open a raw SQL connection as postgres, which owns virtually every table you migrated and holds BYPASSRLS. Either fact alone is enough for Postgres to skip your policies.

So the same query that returns one tenant's rows through supabase-js returns every tenant's rows through Prisma. That is not a bug in your policy — it's the connection role.

Two doors into the same database

There are two completely different paths to your data, and they authenticate as different roles.

The supabase-js path (RLS enforced). supabase-js talks HTTP to PostgREST, not to Postgres directly. PostgREST connects as authenticator, validates the request JWT, and does a SET ROLE into anon or authenticated for the statement. Those are deliberately unprivileged, non-owning roles, so policies get evaluated.

The ORM path (RLS not enforced). Prisma and Drizzle are ordinary Postgres clients. They bypass PostgREST entirely and log in as postgres, whether you connect direct on port 5432, through the session pooler on 5432, or through the transaction pooler on 6543. The port and the pooler are irrelevant — the pooler is just a proxy in front of Postgres. What determines RLS enforcement is the login role, and by default that's postgres for all three connection styles.

If you want the ground-up model of how policies and roles interact, the complete guide to Supabase Row Level Security walks through it from scratch.

Why the postgres role skips RLS (it's not superuser)

The common explanation — "because postgres is a superuser" — is false on the Supabase managed platform, and it's worth correcting because it points people at the wrong fix. Supabase withholds superuser from postgres; the only true superuser is the internal supabase_admin role. Operations that require superuser, like COPY … FROM PROGRAM, are blocked for postgres.

The bypass comes from two other Postgres rules, either of which is independently sufficient:

Table ownership. When Supabase runs your migrations, the resulting tables in public are owned by the postgres role. Per the Postgres manual, a table's owner bypasses that table's RLS by default. Since the ORM connects as postgres, it's the owner of nearly every app table.

The BYPASSRLS attribute. Supabase's role config also gives postgres the BYPASSRLS attribute. From the PostgreSQL manual's Row Security Policies section:

"Superusers and roles with the BYPASSRLS attribute always bypass the row security system when accessing a table."

Note the word "always" for BYPASSRLS — no table-level setting overrides it. Table owners bypass too, though the manual notes an owner can opt back in with ALTER TABLE ... FORCE ROW LEVEL SECURITY. This is the same reason the service_role key bypasses RLS: Supabase creates it as create role service_role nologin noinherit bypassrls;.

The consequence developers get wrong

RLS policies protect the PostgREST path only — the anon/authenticated roles that supabase-js, the Data API, and the auto-generated REST endpoints run as. They do nothing for a direct SQL connection as postgres.

The dangerous mental model is "RLS is a global safety net on the data." It isn't. The moment you add Prisma or Drizzle with the default DATABASE_URL, you've opened a second door that walks past every policy: every SELECT/INSERT/UPDATE/DELETE the ORM issues sees and mutates all rows for all tenants. Teams routinely ship an ORM-backed API next to a "secured by RLS" project and assume tenant isolation still holds. On the ORM path, it does not.

Fix 1: Use supabase-js for user-reachable data, ORM for trusted server work

The simplest and most honest architecture is a hybrid, and it's what most production Supabase apps actually run:

supabase-js for auth, realtime, storage, and user-facing CRUD → RLS enforced for free.
Prisma/Drizzle for complex relational queries, transactions, and admin/migration work → treated as trusted server-side access where you enforce authorization in your application code.

Be clear with yourself about what fix 1 is: it is not RLS. It's "we checked auth in the handler." An ORM connected as postgres with RLS merely ENABLEd on the table gives you zero database-level protection, because the owner bypasses it. Which means the app-layer check is now the only thing standing between a request and a write — more on that below.

Fix 2: Enforce RLS through the ORM with set_config + SET LOCAL ROLE

If you genuinely want your existing policies to run on the ORM path, you have to reproduce what PostgREST does: per request, inside one transaction, set the role to a non-owner role and set the JWT claims, run the query, then reset.

import { Prisma, PrismaClient } from "@prisma/client";

async function withUserRls<T>(
  prisma: PrismaClient,
  jwt: { sub: string; role: string },
  fn: (tx: Prisma.TransactionClient) => Promise<T>,
) {
  return prisma.$transaction(async (tx) => {
    const role = jwt.role === "authenticated" ? "authenticated" : "anon";
    await tx.$executeRawUnsafe(`SET LOCAL ROLE ${role}`);
    await tx.$executeRaw`SELECT set_config('request.jwt.claims', ${JSON.stringify(jwt)}, true)`;
    return fn(tx);
  });
}

Three non-negotiables: the connection role must not be the table owner and must not have BYPASSRLS (see fix 3); everything must be transaction-scoped (a session-level SET persists on a pooled connection and leaks into the next user's request); and you must set the role and the claims — the popular Prisma RLS extension sets the claims but not the role, so TO authenticated policies silently won't match.

Fix 3: A dedicated least-privileged role (and why FORCE alone isn't enough)

The robust fix underneath fixes 1 and 2 is the same: stop connecting your app as postgres. Create a login role that owns nothing and has no BYPASSRLS, grant it the Supabase request roles, then point the runtime DATABASE_URL at it:

create role app_user with login password 'REPLACE_WITH_STRONG_SECRET'
  noinherit nobypassrls;

grant anon, authenticated to app_user;
grant usage on schema public to app_user;
grant select, insert, update, delete on all tables in schema public to app_user;
grant usage, select on all sequences in schema public to app_user;
alter default privileges in schema public
  grant select, insert, update, delete on tables to app_user;

Because app_user is neither owner nor BYPASSRLS, plain ENABLE ROW LEVEL SECURITY is now genuinely enforced for it. Keep a separate postgres string for migrations only.

ALTER TABLE … FORCE ROW LEVEL SECURITY subjects the table owner to policies — but does nothing to BYPASSRLS roles. So if your ORM still connects as postgres, FORCE alone will not save you. The primary control is the connection role.

Where this actually bites: the app-layer auth check

Once you accept fix 1 — the ORM is trusted, RLS is not your backstop on that path — the application-layer auth check becomes the only thing protecting a write. Here's the kind of Server Action that quietly becomes a hole:

"use server";
import { prisma } from "@/lib/prisma";

export async function deleteDocument(id: string) {
  // No auth check. RLS won't save you here — Prisma
  // connects as `postgres` and bypasses every policy.
  return prisma.document.delete({ where: { id } });
}

When the database has stopped being your safety net, a missing guard in the handler is a real, exploitable hole. Verify the user at the top of every action that mutates data — see the auth check every Server Action needs. And keep the direct connection string server-only and out of git (keeping secrets out of your Next.js bundle).

Write these while building GuardLayer, a static scanner for Next.js + Supabase apps. It can't see your DB connection role — but it does flag a Server Action doing a Prisma/Drizzle write with no auth check, exactly the gap this bypass creates. Originally published on the GuardLayer blog.