Item — HN Reader

This is a wild vuln in how trivial it is to execute. But maybe even wilder is the timeframe to event _start_ triaging the bug after it was reported. How? Was it incorrectly named? Was the severity not correctly stated? Someone help me understand how this sits for 2+ weeks.

2025-02-27T06:03Z: Disclosure to Next.js team via GitHub private vulnerability reporting

2025-03-14T17:13Z: Next.js team started triaging the report

3 comments

Yeah, "obvious" critical vulnerability that is easy to use against any Nextjs app, spend 2 weeks making a fix and then announce on Friday evening that all Nextjs apps are free game. Lovely. Luckily doens't affect any of the sites I'm responsible for, since I hated middleware and most of the Nextjs "magic" features already.

> spend 2 weeks making a fix

They didn't spend 2 weeks making a fix, that took a few hours. It took them two weeks to look at the report.

It took them a week to respond about the initial report for v12.0.0, the exploit was so trivial and obvious that even that should have been a warning to go check newer versions themselves, even if they hadn't seen the follow up message that had been sent a few days prior showing that the vulnerability was present in later versions.

"Luckily doesn't affect any of the sites I'm responsible for, since I hated middleware and most of the Nextjs "magic" features already."

This is probably the most important comment. You don't have to use Next.js, and if you do have to, you don't have to use everything they have in it.

I don't think that's the takeaway.

What's the takeaway?

The takeaway is that most people don’t think this way. A large portion of online recommendations for auth in Nextjs recommends middlewares for it. Knowing this, you’d expect a faster response time from the people maintaining the framework and stand to lose the most.

The Vercel-like auth company Vercel's CEO invested in default recommends middleware for protecting routes:

https://clerk.com/docs/references/nextjs/clerk-middleware

You wouldn't get a user's info, but you'd get free reign to explore every page of a product

One might suspect the first half of the comment.

Seems indicative of the companies priorities especially as of late.

This has always been an issue with Vercel. I highly recommend people stay way from their stuff.

What's the next best alternative? Astro?

What do you get out of Next.js over vanilla React? I've never understood why that ecosystem is so popular.

Anyway though, Astro is lovely, especially for static site generation.

> What do you get out of Next.js over vanilla React?

The biggest problem is that React itself recommends against using Vanilla React.

https://react.dev/learn/creating-a-react-app

> If you want to build a new app or website with React, we recommend starting with a framework.

This, frankly, is insane. The whole point of React was that it was this relatively lightweight UI library you could drop into pretty much any workflow.

The fact that the React docs themselves recommend against using the React library as a library is just mind boggling but also another instance in the long history of React devs being absolutely hostile to their users.

There’s a great deal of value in the “fullstack meta-frameworks” model of things. For one, using the same language on the backend and frontend is underrated feature.

But Next.js is not the only option on the market, so I partially echo your sentiment, not around React SPA vs React fullstack, but around Next.js vs a half dozen better alternatives for the React ecosystem.

> using the same language on the backend and frontend is underrated feature

I agree, but you can definitely do this without SSR or Next.JS. Common examples are tRPC, Zodios, or even just plain fetch calls with shared type definitions.

- https://trpc.io/

- https://www.zodios.org/

Even SSR is pretty easy to do without a framework. Just render the component with react-dom/server and use hydrate on the client.

> using the same language on the backend and frontend is underrated feature.

You don't need a framework for that.

Not everyone wants to build a website from scratch. Most people hate build systems.

Building a React app "from scratch" with Vite is this complicated:

import { defineConfig } from 'vite'

import react from '@vitejs/plugin-react'

export default defineConfig({

  plugins: [react()],

})

Without a doubt. It’s really good.

Express?

Express is not a next.js alternative. It covers a small part of the server-side parts but none of the templating, client, etc.

Besides the standard parts IIRC next.js has stuff for image & font optimization and more.

I really dislike next.js, but saying express is an alternative for most next.js apps is not true.

SvelteKit hands down.

If there is no evidence of in the wild exploitation and no reason to think the vulnerability is publicly known, then 2 weeks seems like an acceptable turn around time.

If you start looking at big corps, you will very quickly find instances of fairly severe vulns that sit for months before a fix is issue.

(I'm assuming "started triaging" actually means worked on fixed. If they didnt even respond to reporter for 2 weeks, that is kind of bad)

> no evidence of in the wild exploitation

That's how zero day exploits work. People keep it quiet so they can keep exploiting it.

Sure, but its also how vulns not currently being exploited works.

Good security is about risk management. For a vuln not thought to be exploited, an extra week or two is a reasonable cost/benefit to ensure a proper job was done fixing it and making sure nobody has to pull an all nighter.

If they sat on it for a year, that would be a different story.

It's impossible to know how many people knew about it before it was reported. It's also trivial to add a header to bypass middleware. Apparently it was there since v12 released in 2021 so god only knows how much damage this has caused already.

And let's not forget there are still many unpatched Next self hosted apps, right now.

I can't believe how anyone can downplay this in any way.