4 NextAuth Bugs, 1 Budibase Leak: This Week's Real Risk

Three new frontier coding models shipped this week and Reddit is busy arguing about Grok 4.6 versus GPT Sol. None of that changes your risk. What does: four disclosed flaws in NextAuth.js, the auth library that ships by default in a huge share of AI-built Next.js apps, plus a credential-handling bug in Budibase that shows exactly what a real secrets leak looks like — as opposed to the public-by-design keys people panic about for no reason.

TL;DR

• Four CVEs hit NextAuth.js / Auth.js before @auth/core 0.41.3 and next-auth 4.24.15 / 5.0.0-beta.32 — covering a denial-of-service, a cross-provider CSRF confusion, an email-normalization bug, and a fail-open auth check.
• CVE-2026-72857: Budibase before 3.40.0 stored MongoDB connection strings and Firebase service-account keys in plaintext STRING fields — any authenticated user with table read access could pull them via the read API.
• That Budibase bug is a real leak of private credentials. A Supabase anon key or a Firebase web config sitting in your frontend JS is not — those are public by design, and the only thing that matters there is your RLS rules or Firestore/Storage rules.
• Vibe Coding Weekly notes three frontier models launched inside 48 hours this week. More code shipped faster means the gap between "it works" and "someone checked it" keeps widening.

The NextAuth.js bugs your AI builder may have wired in

If an AI tool scaffolded auth for your app with NextAuth.js or Auth.js, four bugs patched this cycle are worth checking against your version.

The most serious is CVE-2026-73421. In next-auth 5.0.0-beta.0 through beta.32, code that gates access by simply checking whether the auth() object exists — patterns like if (req.auth) or !!auth — can fail open. When Auth.js hits a server configuration error, it returns a truthy error object instead of null, so an unauthenticated request can read as authenticated. This is exactly the kind of check an AI coding assistant writes without a second thought, because it looks correct.

CVE-2026-73419 affects multi-provider sign-in. The anti-CSRF state, nonce, and PKCE verifier are stored in cookies that aren't bound to the specific provider that created them. A check value minted for one OAuth provider can satisfy the callback for a different provider in apps that allow account linking, because the callback never verifies provider identity, client ID, or redirect URI.

CVE-2026-73420 is subtler: the email/magic-link normalizer checks for a single at-sign before applying Unicode normalization. An address using a fullwidth Unicode at-sign (U+FF20) passes that check, but a downstream mail library that normalizes the same string can then see a different address entirely — opening the door to verification-request confusion.

CVE-2026-73418 is a denial-of-service: getToken() URL-decodes a Bearer header before validating it, and a malformed percent-encoded value throws an uncaught exception instead of failing gracefully. Since getToken() runs in middleware and API routes, a single malformed request can crash a request handler.

All four are fixed in @auth/core 0.41.3+ and next-auth 4.24.15+ / 5.0.0-beta.32+. If you didn't pick your auth library yourself — an AI builder did — check your package.json now.

Budibase shows what a real credential leak looks like

Separately, CVE-2026-72857 is a good reference point for what actually counts as a leaked secret. Budibase before 3.40.0 stored datasource credentials — MongoDB connection strings, Firebase private keys — in plaintext inside STRING-typed fields and failed to redact them. Any authenticated user with read access to the relevant table could pull the full datasource configuration through the read API and walk away with live database credentials and service account keys.

Compare that to a Supabase anon key or a Firebase web config object sitting in your app's client-side bundle. Those are meant to be public. They identify your project to the backend, nothing more. The thing that decides whether your data is safe is your Row Level Security policies or your Firestore/Storage rules — not whether the key itself is visible. Calling a visible anon key a "leak" misses where the actual risk lives. The Budibase bug, by contrast, exposed credentials that were never supposed to be readable by ordinary users at all. That distinction matters, and it's the one to keep straight when you're auditing your own app.

Model churn isn't the story — patch discipline is

Vibe Coding Weekly #39 points out that three frontier coding models launched within 48 hours of each other this week, and that manual code review is collapsing as token spend becomes the real cost lever. That's the backdrop worth remembering: the models writing your auth code, your database queries, and your API routes are shipping faster than most teams can review the output. A library CVE like the NextAuth.js batch above doesn't care which model wrote the code that calls it — it just needs to still be on the vulnerable version.

FAQ

Does my app use a vulnerable version of NextAuth?

Check your package.json for next-auth or @auth/core. If you're below next-auth 4.24.15 or 5.0.0-beta.32, or below @auth/core 0.41.3, you're exposed to one or more of the four CVEs above. Upgrade and redeploy.

Is a Supabase anon key or Firebase web config a security leak?

No. Both are meant to be public and are safe to ship in client-side code. The real question is whether your Supabase Row Level Security policies or Firebase/Firestore rules actually restrict who can read and write your data. A visible key with broken rules behind it is the risk — not the key itself.

Should AI agents rewrite code without a human review?

Not for anything touching auth, data access rules, or credential storage. The Budibase and NextAuth.js issues above are the kind of logic bugs that pass a quick glance and a working demo but fail under a security review. Treat auth code and permission checks as the one place where an AI agent's output always gets a second look.

The bottom line

The interesting number this week isn't a benchmark score. It's four. Four NextAuth.js CVEs, one of which can let an unauthenticated request pass as authenticated when your server misconfigures itself. Pair that with a Budibase bug that shows what a genuine credential leak looks like — plaintext database and service-account secrets pulled through a read API — and you get a clear priority list: check your NextAuth version, check who can actually read your stored datasource credentials, and stop worrying about public keys that were never the problem.