A little over a week ago, on 21 March, the Next.js project disclosed an authorization-bypass flaw in its middleware, tracked as CVE-2025-29927. The short version: if your app did its auth checks in middleware, a request carrying a particular internal header could skip straight past them. It is the kind of bug that makes your stomach drop, because middleware is precisely where a lot of people put exactly that check, on the reasonable assumption that nothing gets past it.
What struck me was not the bug. Auth bypasses happen; that is why we patch. What struck me was watching the internet decide, within hours, how scared to be, and how completely that decision was shaped by presentation rather than facts. This one didn't, as it happens, arrive with a logo and a custom domain. But plenty have, and the reflex the genre has trained into us was on full display anyway.
How we got here
The branded vulnerability started, more or less, with Heartbleed in 2014. A serious OpenSSL bug, a memorable name, a clean logo, a website explaining it in plain language, and a CVE number that nobody outside security would ever remember. The name did real work. It got the bug patched faster than a string of digits ever would have, because a CFO can say "the Heartbleed thing" to an engineer and be understood, and because journalists could write a headline that wasn't gibberish.
So I want to be fair to the format before I complain about it. Naming a vulnerability, giving it a one-page site that explains who is affected and what to do, is genuinely good communication. CVE-2025-29927 is an unreadable token. "The thing where middleware auth gets bypassed" is something a stressed-out team can actually coordinate around at nine on a Friday evening.
Where the branding starts lying
The trouble is that branding optimises for memorability and attention, and those are not the same axis as severity. A bug with a great logo and a punchy name gets wall-to-wall coverage whether or not it is actually exploitable in your environment. A genuinely catastrophic flaw with a boring advisory and no marketing budget can sail past unnoticed. The presentation layer has become decoupled from the risk, and we have collectively learned to read the presentation as if it were the risk.
You can watch this happen in real time. Within a day of a named vulnerability, the cycle runs:
- A breathless first wave declaring everything on fire.
- A correcting second wave of "actually it only affects you if you do X".
- A third wave of vendors announcing they were never affected, often before they could possibly have checked.
- Eventually, quietly, the actual guidance, by which point half the audience has moved on.
The Next.js issue followed roughly that shape. The first reactions treated every Next.js deployment as compromised. The reality was more bounded and more interesting: it mattered enormously if you relied on middleware as your only line of defence, and rather less if you also enforced authorization closer to the data, where it arguably belonged in the first place. That nuance is exactly what gets flattened when a bug becomes A Thing.
There is a second-order problem, too, which is that the attention is a finite resource and the branding spends it unevenly. Every hour an engineering team pours into a high-profile bug that doesn't actually affect them is an hour not spent on the quieter, uglier exposure that nobody named. I have watched a team drop everything for a vulnerability with a memorable handle, confirm over an afternoon that they weren't running the affected configuration, and go home pleased with themselves, while a misconfigured storage bucket they'd been meaning to lock down for a month sat exactly as open as it had been that morning. Branding is a spotlight, and spotlights leave everything outside the beam darker than before.
I am also a little wary of the incentives the format creates for the people who find these bugs. A logo and a domain are now, in some corners, part of the deliverable. Disclosure has acquired a performative layer, and the temptation to dress up a middling finding in catastrophe-grade packaging is real, because attention is the currency and a good name buys a lot of it. Most researchers resist that, and the serious ones are scrupulous about severity. But the format itself rewards the opposite, and over enough cycles the format tends to win.
The lesson the branding obscures
The genuinely useful takeaway from this one has nothing to do with the CVE and everything to do with defence in depth, the least glamorous idea in security. Middleware is a fine place to do auth. It is a terrible place to do auth and nowhere else. If a single bypassable layer is the only thing standing between an attacker and your data, then sooner or later a bug in that layer is going to ruin your week, and it doesn't matter whether that bug has a logo.
I find the branded-vulnerability era genuinely double-edged, and I don't want to be the person sneering at it from the sidelines. The names help. The sites help. The marketing pulls in attention that gets things patched, and patched faster, and that has prevented real harm. But the format has trained a generation of us, myself included, to gauge severity by production values, to feel safe when the advisory looks boring and panic when it looks slick. That instinct is exactly backwards.
So here is my modest proposal, which I will fail to follow the next time a logo lands in my feed. When the next branded bug arrives, ignore the website for a moment. Read the advisory. Ask the two questions that actually matter: am I running the affected thing in the affected configuration, and if this layer fell over completely, what is the next thing that stops the attacker? If the honest answer to the second question is "nothing", then the logo is the least of your problems, and no amount of clever naming is going to save you. Patch, by all means. Then go and find your missing second layer, because the next vulnerability is already being written, and it may not be considerate enough to come with a website.