Website security updates: what a business should do

Website security updates are releases that close a known vulnerability in your site's software. A site that does not apply it stays open to anyone who reads the public list of fixes and goes looking. On 3 November 2026 the Next.js team shipped a release that fixes seven vulnerabilities. This guide uses that news as an example of what a small business should ask about website security.

What did Next.js release on 3 November 2026?

The Next.js team published its November 2026 security release on 3 November. The fixes are in versions 16.4.5 (active long-term support) and 15.5.29 (maintenance). The announcement describes one high-severity and six medium-severity issues. We covered the release in advance in Vinci Notebook.

Most of the issues depend on specific setups: applications using cache components, sites running on their own servers, edge routes, or image optimisation. So not every Next.js site is affected by every issue. But only someone who knows your version and configuration can tell you whether you are.

Why does this news concern you?

The news is about one framework, but the message is general: all web software, from a theme to a plugin to a framework to a server package, ships updates, and some of them are for security. When a security update is published, the details of the flaw become public. Delaying the update leaves an attacker a ready-made guide.

The pace at Next.js is also high. According to the announcements, since July 2026 the team has run a formal security release process: scheduled releases came on 20 July, 25 August, 30 September and 3 November, with out-of-band urgent updates on 22 September and 14 October. A site left alone after launch misses several patches within a few months.

Whose job are website security updates?

The answer should be clear in your contract or agreement. In many small businesses the site is delivered and what follows stays vague: the developer says "I delivered it", the business says "nobody told me". The security update gets lost in between.

There are three cases. If an agency manages the site, updating is the agency's job and it should be written into the maintenance scope. If you use a hosted site platform, the platform updates the core, but the plugins you added are your responsibility. If a freelancer built the site and there is no maintenance agreement, updating is most likely nobody's job.

Five questions to ask your web provider

• Which framework and which version does my site run on?
• When security updates arrive, who applies them and how fast?
• Are updates tested before going live?
• If something breaks, can we go back to the previous version?
• Is this included in the price or separate?

If the answers are vague, that is a finding in itself. Security is often less a surprise attack than a pile-up of small jobs nobody owns.

The most common mistakes in updating

The first is never updating: the site works, so nobody touches it. The second is applying an update straight to the live site without testing; a version jump can break redirects, forms or the payment step. The third is updating only the main framework and forgetting the plugins. The fourth is not checking after the update that the form, the WhatsApp link and the sitemap still work.

A good maintenance routine therefore has three parts: tracking updates, trying them in a test environment, and checking the basic flows after release. If you are commissioning a new site, discussing this scope up front is cheaper than discussing it later; we treat the maintenance line separately in our website prices guide.

Is a security update the same as a feature update?

No, and separating them lowers the cost. A feature update brings new capabilities; it can be postponed, planned and budgeted. A security update adds nothing new; it closes an existing hole and is usually small: a version bump, a short test, a release. Because the workload is small, it is cheap when done regularly and expensive when saved up for months, since every skipped version makes the next jump harder.

In its 16.4 announcement the Next.js team introduced an experimental upgrade reminder; its default setting reminds you of versions tied to known vulnerabilities. But if the person maintaining the site does not see it, the reminder does nothing. Technology helps; it does not remove the question of who is responsible.

Which sites carry more risk?

Sites that run on their own servers, have user logins, take forms or payments, or hold data for several customers need more care. Some of the issues in the announcement concern exactly applications where several tenants' data can mix or that run on their own server. For a simple brochure site the risk is lower but not zero, because the site may be linked to email, form records and an admin panel.

If you commissioned custom software or automation, the maintenance question matters even more. For those projects it helps to write the update scope into the delivery of custom projects and automation.

How do you find out whether your site is up to date?

Even if you are not technical, you can do two things. First, ask your provider for version information in writing; ask for the version number rather than accepting "it's up to date". Second, use strong passwords and two-step verification for your admin panel and accounts; even with current software, a stolen password opens the site.

If you would like to review your site's state together, look at the maintenance scope of our web design service or write to us through the quote wizard.

Frequently Asked Questions