AI is changing the tempo of cybersecurity

LOL 🤣 I had originally drafted this post back in August 2026. In terms of the tempo of AI and cybersecurity, that now feels like last century.

Back then, the important distinction was that AI had not “broken encryption”. Anthropic’s research had identified weaknesses in a proposed digital signature scheme and improved an attack on a deliberately weakened research version of AES. Significant work, but not the collapse of the encryption protecting our everyday systems.

Now the story I am watching is the pace of vulnerability discovery.

AI is making it possible to search for software flaws at a speed and scale that changes the workload for everyone downstream. Some of these vulnerabilities have been sitting in code for years, even decades. The software has not suddenly become insecure. We are getting much better at finding where it was insecure all along, as Cisco Talos explains in its analysis of rising vulnerability numbers.

The past couple of Microsoft Patch Tuesdays have been epic. Now we have critical vulnerabilities in PHP and a separate certificate authority incident that is a useful reminder of how digital trust can fail.

These are different problems. Lumping them together as “AI breaking security” misses what is actually happening.

Old code, new scrutiny

There is an important distinction between creating a vulnerability and discovering one.

Cisco Talos describes the current surge as AI working through a backlog of technical debt in old code, including widely used libraries and tools. Its analysis argues that frontier models are becoming more efficient at finding known types of vulnerability, rather than necessarily discovering entirely new classes of flaw.

That matters because old code is not necessarily obscure code. It can be the dependable component that sits underneath a great many other things. The bit nobody wants to touch because it works, the original developers have moved on, and changing it would require testing half the estate.

Now it is getting a different level of scrutiny.

Microsoft’s multi-model agentic security system, codenamed MDASH, provides a practical example. It uses specialised AI agents to find, debate and validate potential vulnerabilities. Microsoft reported that the system helped researchers identify 16 new vulnerabilities across the Windows networking and authentication stack, including four critical remote code execution flaws.

This is more than a chatbot suggesting that a piece of code looks suspicious.

But finding the problem faster does not make the rest of the work disappear.

PHP brings the problem rather close to home

The latest example is PHP2Shell, disclosed by Wiz Research and other researchers this week.

PHP is part of the infrastructure beneath a great many websites, including sites running WordPress, Drupal and Joomla. These vulnerabilities sit in the PHP engine itself, not simply in a badly written plugin or an application somebody forgot to secure.

Wiz demonstrated unauthenticated remote code execution against deployments of all three platforms. In plain English, an attacker could get a vulnerable server to run their code without first logging in. Researchers also demonstrated the disclosure of sensitive information from server memory.

The underlying problems concern how PHP handles memory when a request goes wrong. Cloudflare’s technical explanation of PHP2Shell describes error paths that can leave PHP using data that was not fully initialised or memory that has already been released.

This is precisely the kind of complexity that makes security research difficult. The problem is not necessarily visible in the ordinary, successful execution of a program. It emerges when something fails, cleanup runs, and internal state is not what the next piece of code expects.

AI helped researchers investigate those paths. Wiz’s account describes AI-assisted discovery and exploit development, while also making clear that researchers were doing the validation and coordinating remediation.

The affected code reaches back to PHP 5.4. That does not mean every installation is equally exploitable, or that every PHP website has been compromised. It does mean that an organisation can have carefully secured its own application and still inherit a serious problem from the runtime underneath it.

Emergency patches were released on 21 October 2026. The PHP security team’s advice, reported by BleepingComputer, was to update affected systems urgently.

For a website owner, the practical question is not just “Have I updated WordPress?” It is also “Who manages the PHP runtime, and have they fixed it?”

That might be an internal team, a hosting provider or another supplier. The responsibility needs to be clear before the emergency, not discovered during it.

The CA issue is different, and that distinction matters

At roughly the same time, we have had the eMudhra certificate authority incident, documented in Mozilla’s public investigation.

A certificate authority, or CA, helps establish whether a website is who it claims to be. An intermediate CA holds a signing key that can be used to issue certificates beneath a trusted root. Those keys are therefore rather important.

Eight eMudhra intermediate CA private keys turned out to be trivially recoverable.

According to Mozilla’s investigation, the affected P-384 private keys were integers smaller than 256. Instead of an appropriately random private value, they were effectively all zeroes apart from the final byte. Mozilla independently recovered the keys and confirmed the problem. (eMudhra has provided a handy checker for the issue here.)

This was not an AI system defeating elliptic-curve cryptography.

It was a failure in how the keys were generated and selected.

In its public statement on the incident, eMudhra said a key wrap/unwrap step produced a second, weak set of keys alongside the intended strong keys, and that the weak keys were mistakenly used. The company said it revoked the eight intermediates, that none had issued customer certificates, and that its infrastructure had not been breached.

The potential consequence was nevertheless serious. Someone who recovered an affected signing key could create fraudulent certificates. Cisco Talos’s analysis of the compromised intermediate certificates provides additional security context, while Mozilla’s incident record highlights a broader difficulty: not every device or application has an effective way to receive certificate revocation information.

I would not present this as another AI discovery without evidence that it was one. It belongs in this discussion because it exposes a related operational problem.

When a dependency at the foundation of trust fails, how quickly can the rest of the ecosystem respond?

PHP requires software updates. A CA incident requires revocation and trust-store changes. Different mechanisms, but both depend on organisations knowing what they use and being able to act.

Patch Tuesday has become a capacity question

Meanwhile, CrowdStrike counted 972 vulnerabilities in Microsoft’s September release and 1,413 in October. Other published tallies differ, so I would be careful about treating any one number as the definitive total.

But the broad picture is clear: nearly a thousand vulnerabilities in September, followed by more than 1,400 in October.

That is a lot of assessment, testing and deployment.

A disclosed vulnerability is not the same thing as an attack, and a large patch release does not mean every flaw is equally dangerous. Cisco Talos specifically cautions that disclosure does not equal weaponisation, and that exploitation has not increased in proportion to the volume of discoveries.

Nor should we assume that every fix in those releases came from AI. The totals tell us about the volume organisations must process. They are not, by themselves, a clean measure of AI’s contribution.

Nevertheless, they make the operational question rather hard to avoid.

What happens when the rate at which we identify problems exceeds the rate at which we can safely fix them?

The leisurely approach was always a gamble

I was going to write that we used to have a fairly leisurely approach to bug fixes.

That is probably unfair to the security and infrastructure teams who have spent years trying to get urgent patches approved.

But many organisations have built processes around a slower rhythm: a monthly patch cycle, scheduled change windows, business approval, testing, deployment and then an exception for the system that cannot possibly be interrupted.

There are good reasons for some of that caution. Taking down an important service with a poorly tested patch is not a successful security outcome.

The problem is treating the timetable as fixed while everything around it changes.

My concern is that faster discovery will leave organisations with a growing queue of known problems, all competing for the same people, test environments and maintenance windows.

Buying a faster scanner will not resolve that queue. It may simply make it more visible.

This is a governance problem too

For me, the useful word here is tempo.

Not just speed. The relationship between discovery, assessment, decision-making and action.

If discovery accelerates but every remediation decision still waits for the next committee meeting, we have not modernised vulnerability management. We have modernised the production of its backlog.

The questions I would put to an executive team are fairly straightforward:

• Do we know which systems, runtimes and dependencies we actually use?
• Can we identify which new findings matter to our environment, rather than treating every alert as equally urgent?
• Who can authorise an emergency change, and can they do it quickly?
• Can we test, deploy and roll back changes without improvising every time?
• Do our suppliers have clear responsibilities for patching the things they manage?
• Can our systems receive urgent certificate and trust-store updates?
• When something cannot be fixed immediately, who accepts the risk, what compensating controls are in place, and when does the exception expire?

These are not questions that a model can settle for us. They involve service priorities, operational consequences, ownership and money.

Someone still has to decide whether the organisation will fund the work.

Faster discovery can be good news

I do not think we should mistake better visibility for failure.

Finding a longstanding vulnerability gives us an opportunity to remove it. Leaving it undiscovered does not make the system safer.

But the PHP and eMudhra incidents also show why the response cannot stop at discovery. Someone has to validate the problem, coordinate the fix, communicate with affected organisations and get the changes into the systems that need them.

My view is that the next investment conversation needs to be less about how many vulnerabilities a tool can find and more about how many consequential risks an organisation can actually resolve.

That means looking at the less glamorous things: asset inventories, supported software, test environments, deployment automation, rollback, supplier responsibilities and clear decision rights.

Not quite as exciting as a demonstration of an AI agent finding a bug. Rather more useful when the next emergency lands.

August already feels a long time ago. Our change processes cannot afford to operate as though it we are still in August.