Two Next.js security updates in one week: what it means for maintaining your website

On 22 September, Vercel, the company behind Next.js, shipped an out-of-band update for a critical vulnerability in the framework. Eight days later, on 30 September, a second, previously announced security release followed, fixing nine vulnerabilities at once, one of them again rated critical. Two updates in just over a week, for a framework that sits behind a large share of modern business websites, webshops and customer portals, including Zarioh's own.

For anyone who does not write code themselves, this sounds like background noise from the developer world. It is not. What happened in September shows precisely why a website is not a finished project once it goes live, but a piece of software that keeps needing maintenance, just like accounting software or an operating system.

What actually happened

The 22 September update fixed an issue in the part of Next.js that generates images, next/og, via an external library called Satori. Under specific conditions, an attacker could use that path to run their own code on the server, known as remote code execution. The issue affected versions from 16.2.0 up to and including 16.3.5, and Vercel shipped version 16.3.6 with the fix within a few hours.

The second update, scheduled for 30 September, was not an emergency fix but a release announced in advance. Vercel let teams know more than a week ahead that it would address nine vulnerabilities: one critical, two high, five medium and one low. That advance notice gave development teams time to prepare, something that was not possible with the out-of-band update on the 22nd.

Why remote code execution is more than a buzzword

Remote code execution means an attacker does not just get to see data, but can take over the server itself. In practice that can lead to stolen customer data, a website that quietly serves malicious code to visitors, or a full hijack of the environment. The difference with an ordinary bug is the difference between a broken doorbell and a front door that no longer locks.

The assumption that a website is done once it is live

Many organisations treat a website as a one-off project: an agency builds it, there is a handover, and after that little changes beyond some text and photos. Under the hood, however, a stack of software keeps running, the framework itself plus dozens or hundreds of separate packages, which keep developing vulnerabilities like any other software. Next.js shipped security updates several times this year already, including in May and August, and now twice in September. That is not an exception, it is the normal rhythm of an actively maintained framework.

The problem is not the framework, but the assumption that a website needs no attention once delivered. A vulnerability published today shows up tomorrow in scanning tools that sweep the entire internet for outdated versions. The longer a patch is delayed, the wider the window in which an automated attack can land a hit, often without any attacker specifically targeting your organisation.

The same rule applies beyond Next.js

Not using Next.js does not make you safe by default. WordPress, which powers a large share of the web, has a similar rhythm of security updates for its core and for thousands of plugins. The underlying problem is always the same: software that keeps running unattended after delivery eventually becomes the easiest target. Not because an attacker is specifically looking for that one organisation, but because automated scans are constantly searching for outdated versions, on any platform.

Who actually patches your website

This is the question most management teams and marketing departments cannot answer. Is there a hosting party actively tracking and updating versions? Is it the freelancer who built the site three years ago and has since moved on? Or does the site simply keep running until something visibly breaks? For many websites, the honest answer is: no one, structurally. Updates only happen when a new feature happens to be added, and security patches with no visible effect are left untouched.

What you can do this week

Ask your hosting party or developer concretely which Next.js or WordPress version is currently running, and whether the 22 and 30 September updates have already been applied. No concrete answer, or one that takes days to arrive, is itself a signal. Also ask how patching generally works: automatically with every release, periodically scheduled, or only after an incident. For a customer portal, webshop or any system holding login details and personal data, a structural patch process is not excessive caution, it is a basic requirement.

Building a website is the start of the responsibility for its security, not the end. Want to have your website and its underlying software checked for currency and security, or want its maintenance placed structurally with a party that keeps track of it continuously? Zarioh is happy to help with managed hosting and ongoing website maintenance.