The patch wave has arrived: what the NCSC told you to do in May

In May the NCSC told organisations to prepare for a “patch wave” as AI-assisted research works through decades of technical debt. October suggests the wave is no longer a forecast. Here is what that means for your change calendar.

The forecast

On 1 May 2026 Ollie Whitehouse, the NCSC’s chief technology officer, published Preparing for a ‘vulnerability patch wave’ (opens in a new tab). The argument is simple. Every organisation carries technical debt, and AI in skilled hands “is showing the ability to exploit this technical debt at scale and at pace across the technology ecosystem.” As a result, “the NCSC expects there will be a ‘forced correction’ to address this technical debt across all types of software, including open source, commercial, proprietary and software as a service.”

It did not come out of nowhere. On 15 April the NCSC’s chief executive, Richard Horne, wrote, in a letter first published in the Financial Times and reposted as Retaining defensive advantage in the age of frontier AI cyber capabilities (opens in a new tab), that “the pressure on organisations to patch systems quickly will only grow more acute.” On 20 October the NCSC added an AI chapter (opens in a new tab) to its research problem book, noting that “Concepts such as vulnerability management, incident response and risk management will need to evolve”. The direction of travel is not subtle.

The evidence so far

October has been a busy month for anyone who reads advisories for a living, and the pattern fits the forecast:

PHP2Shell. We covered it earlier this month: two critical flaws in a codebase that runs a large slice of the web, and a lot of servers to patch.
Plex2Shell. The researcher’s write-up (opens in a new tab) includes a section titled “How I found it with LLMs”. The flaws are now being exploited, as our Plex2Shell report sets out.
ConnectWise Cloud Backup. On the attacking side, Microsoft (opens in a new tab) says Storm-0940 used ARTEX, an agentic penetration testing framework, to work through stolen app identities. Our ConnectWise piece has the detail.

None of this proves that AI found every bug or wrote every exploit. It does show cheaper discovery on one side, faster tooling on the other, and defenders’ patch windows squeezed in the middle. Whatever you call that, your change advisory board will notice it first.

What the NCSC actually advises

The advice is more useful than the headline, and most of it is unglamorous.

Start at the edge. “Where organisations cannot apply updates across their entire environment, they should prioritise applying updates to their external attack surfaces.” After that, critical security systems.

Patch faster, more often, at scale. Enable automatic hot patching where it exists, automatic updates wherever they are available (including on embedded devices), and otherwise make sure processes and risk appetite can cope with frequent updates. The NCSC points to the Stakeholder Specific Vulnerability Categorisation (SSVC) system for prioritising. It also recommends an “update by default” policy, with exceptions for safety-critical systems and operational technology.

Accelerate for active exploitation. If a critical bug is being exploited, especially on something internet-facing, the normal cycle no longer applies.

Replace what can’t be patched. The post is clear that some debt sits in end-of-life kit: “patching alone will not always suffice”. Out-of-support technology on the perimeter needs replacing or bringing back into support.

Don’t stop at patching. Fundamentals still matter: Cyber Essentials, or the Cyber Assessment Framework for essential services, and for producers, memory safety and containment technologies such as CHERI.

The uncomfortable bits

Three things tend to break when update volume rises sharply.

The first is the change process. A monthly window with a two-week approval cycle was designed for a world of predictable Tuesdays. It will not survive several out-of-band critical fixes a week. Pre-approve standard changes for internet-facing systems now, while nobody is shouting.

The second is the asset list. You can’t patch what you don’t know you own, and the perimeter is where shadow IT likes to live: forgotten VPN appliances, test instances, media servers someone set up in 2019. Plex2Shell is a reminder that “consumer” software turns up on corporate networks.

The third is suppliers. A lot of your exposure is SaaS and managed services you don’t patch yourself. The NCSC asks larger organisations to seek assurance from their supply chains, commercial and open source, that they can respond too. ConnectWise is a fair example of why.

What to do

Map your external attack surface this quarter, and give every internet-facing system an owner and a patch route.
Turn on automatic updates wherever the operational risk allows, starting at the perimeter.
Pre-approve emergency changes for edge devices so that an actively exploited critical bug can be fixed in hours, not weeks.
List your end-of-life kit and budget to replace whatever faces the internet.
Ask key suppliers how fast they can ship and deploy fixes, and get the answer in writing.
Read the NCSC’s updated vulnerability management guidance (opens in a new tab), which the post recommends as the starting point.

For a live example, see PAN-OS CVE-2026-0257; for the next deadline on the horizon, post-quantum TLS. More is in Horizon Scanning.

Sources

Follow Cyber-Threat.net RSS Feedly (opens in a new tab)X (opens in a new tab)Bluesky (opens in a new tab)LinkedIn (opens in a new tab)