A Critical Next.js RCE Sat Invisible to Dependabot for Nine Days. Here's Why That Should Worry You.

By Swayam Swarup Panda

Next.js patched a critical unauthenticated RCE on August 25th. Nine days later, the advisory still hadn't reached the database every dependency scanner relies on. The vulnerability existed. Your tools just couldn't see it.

The patch that shipped fine. The visibility that didn't.

On August 25th, Vercel published a security release for Next.js addressing two unrelated, critical-severity vulnerabilities, each capable of unauthenticated remote code execution. One was a Windows-specific path traversal bug affecting deployments using both the Pages Router and App Router without Cache Components. The other, more severe of the two, traced back to a heap buffer overflow in libheif — a low-level image-decoding library pulled in transitively through sharp, which Next.js uses for image optimization. Neither bug lived in code Vercel wrote directly. Both were serious enough that the patched releases disabled AVIF optimization entirely rather than ship a partial fix.

The patch itself worked as intended. Versions 15.5.24 and 16.3.3 closed both holes, and teams that upgraded that week were protected. The problem showed up somewhere else entirely.

The database that everything quietly depends on

On September 3rd — nine days after the advisory was published directly on the vercel/next.js GitHub repository — a developer noticed something uncomfortable: the advisory still hadn't propagated to the global GitHub Advisory Database. That database is the thing almost nobody thinks about directly, because almost every automated vulnerability tool is quietly built on top of it. Dependabot reads from it. npm audit and yarn audit read from it. Third-party scanners built on the OSV mirror read from it. If an advisory hasn't landed there, all of those tools report a clean bill of health for a package that has a critical, actively-documented, unauthenticated RCE sitting in it.

For nine days, that was the actual state of the ecosystem. The vulnerability was real, public, and patchable. The tooling most teams rely on to tell them "you have a problem" simply hadn't heard about it yet.

Why this is worse than it sounds

It's tempting to read this as a one-off clerical delay — an advisory stuck in a queue somewhere, eventually sorted out. That's true, and it likely was resolved without incident for most teams. But the underlying assumption it exposes is the real issue: a huge number of organizations' entire vulnerability management process starts and ends with "did Dependabot open a PR." No PR, no action, no awareness a problem exists.

That's a reasonable default when the pipeline from disclosure to database to automated alert works quickly and reliably. It becomes a real gap the moment that pipeline has any lag — and a nine-day gap on a critical, unauthenticated, no-workaround RCE is more than enough time for the vulnerability to circulate among people actively looking for exactly this kind of opportunity, while defenders' automated tooling stays silent.

What actually closes the gap

A few habits are worth adopting if this story made you slightly uneasy about how much you're trusting a single database to tell you when something's wrong:

  • Follow security advisories directly from the source, not just through your dependency scanner. Vercel, like most major frameworks now, publishes security releases on their own blog and GitHub repository before — sometimes well before — that information reaches downstream databases.

  • Treat "no known workaround" advisories as urgent regardless of your scanner's status. If a critical, unauthenticated vulnerability is disclosed anywhere in your stack, don't wait for an automated PR to confirm it's real before you check your own exposure.

  • Know your platform-specific exposure. The Windows-only path traversal bug in this release meant plenty of Linux-hosted teams had zero exposure to one of the two CVEs — worth knowing before you burn a Friday afternoon patching urgently for a bug that couldn't have affected your infrastructure in the first place.

  • Don't assume transitive dependencies are someone else's problem. The more severe vulnerability here lived three layers deep — Next.js pulls in sharp, sharp pulls in libheif — and none of those layers are typically on a frontend team's radar until something like this happens.

The actual lesson

This isn't really a story about Next.js, or about GitHub's advisory pipeline having a bad week. It's a reminder that automated dependency scanning is a genuinely useful floor, not a ceiling. The tools tell you about vulnerabilities they know about, the moment they know about them — and there's always a gap, however small, between a patch existing and every tool in the ecosystem being aware it exists. For nine days this month, that gap was the only thing standing between "patched" and "invisible."

Follow me to keep in touch

Where I share my creative journey, design experiments, and industry thoughts.