Responding to AI's Black October, a cyber action plan, and how to track vulnerabilities

Over the past week, a run of serious security incidents has led governments to take public services offline and left organisations around the world rushing to patch the software behind most websites. Critical flaws in PHP and GitLab, a poisoned release of the LiteLLM AI library, broken certificate keys that undermine Python package installs, and breaches at the hosting platforms Railway and Zeabur have all landed within days of each other, and some commentators have started calling it "Black October".

The incident at the centre of this new wave is PHP2Shell. Two flaws let a crafted web request run an attacker's commands on a server without logging in. They have been in PHP's engine for more than a decade, affecting every version back to 5.4. They were found this summer with the help of GPT-5.6, and news of the flaws leaked the day before the fix shipped on 21 October. Public bodies in the Netherlands, Finland, France and the UK have taken services offline as a precaution, including the Dutch DigiD login service. In Japan, SoftBank has suspended earthquake, tsunami and evacuation alerts to its mobile customers until 26 October while it fixes the flaw, and the government plans to set up an AI-assisted team to test systems for weaknesses.

PHP is not a technology most people think about. Few new projects start with it, and it rarely comes up in conversations about modern software. Yet according to W3Techs it runs 69.3% of the websites whose server-side language can be identified, including every WordPress site. About a third of those PHP sites still run version 7 or older, which the PHP project no longer supports. PHP does not run power grids or military systems, so this is not a direct threat to critical national infrastructure. It does show how much of everyday digital life rests on old, widely shared components that few people have been thinking about.

In April, writing about Anthropic's Mythos model, we set out scenarios in which AI-driven vulnerability discovery outpaces patching, leaving smaller organisations and neglected open-source projects to live with periods of outages and fraud. Black October looks like an early example. Unlike a bridge or a power station, though, software can be fixed quickly once a flaw is known. PHP shipped its fix the day after news of the flaws leaked, Cloudflare had protective rules running before disclosure, and maintainers, security firms, AI labs and government agencies worked on the release together.

Some of the people closest to the problem expect it to get worse first. Jason Clinton, Anthropic's deputy chief information security officer, has warned of a coming "vulnerability tsunami" that could leave the operators of power and water systems without enough time to fix flaws, and has urged organisations to cut sensitive networks off from outside access. On 22 October he asked security leaders to go to their boards for help with the basics, and said they would need to hold on for about 18 months.

“As bad as things have gotten in the past 4 days, they are going to get a lot worse before they get better.”

How an AI-found flaw reaches the public

The PHP2Shell timeline shows what happens when AI finds a flaw in one of the internet's basic building blocks. Researchers had spotted the underlying weakness in 2020 and again in a 2024 audit, but nobody turned it into a working attack. Wiz describes the chain of steps as being at the edge of what human researchers could practically achieve. On 1 August, two days after joining OpenAI's Patch the Planet programme, Ryan Austin of the security firm Calif found remote code execution paths using GPT-5.6 Sol. OpenAI reported the core flaw separately on 11 August, and Wiz found the same family of bugs on 19 August using Gemini 4 Argon and GPT-5.6 Sol. Three groups reached the same flaws within weeks of each other.

The human part took longer. PHP confirmed Calif's proof of concept on 15 August, and OpenAI then spent about two months coordinating maintainers, researchers, security vendors and agencies including CISA. Technical details were due on 22 October. On 20 October a Hacker News user posted that the flaws were about to be disclosed, watchTowr confirmed the leak was real, and a video of a working exploit was published early by mistake. PHP shipped the fix at 14:00 UTC on 21 October.

Timing matters this much because in open-source software a published fix shows exactly where the bug is. Anyone can compare the new code with the old. That comparison used to take skilled researchers days. Frontier models do it far faster, and Sansec expected mass exploitation within 15 minutes of the patch. From that moment, defenders have to push the fix through hosting companies, Linux distributions, container images and vendor products to millions of servers, while attackers only have to scan for the servers still waiting. Even PHP's advance notice helped attackers, because it confirmed two critical flaws in PHP, their severity and the release time.

As AI makes discovery cheaper, more independent groups will find the same bugs at around the same time. Each extra finder is another possible leak, and another chance that an attacker already has the knowledge and is keeping quiet. With PHP2Shell, discovery took days, coordination took two months and exploiting the published fix may take minutes. The slowest step is now getting patches onto servers, and that step depends on people.

What's happening in the wild

Two days after the fix, attackers are trying PHP2Shell at very large scale. Cloudflare's chief executive, Matthew Prince, reported thousands of attempts in the ten hours before disclosure, tens of thousands in the 45 minutes after it, and millions since. Amazon recorded an attempt against its honeypot servers on 17 October, four days before the fix, and a run of attempts from different sources with different payloads from about 02:00 UTC on 21 October, which it reads as several separate attackers. It advises organisations to look for suspicious activity back to at least 17 October. The threat intelligence firm KELA reports scanners that try to install botnet software, and existing attack bots adding PHP2Shell to their toolkits.

The attacks are also getting more capable. Many early exploits shared on criminal forums were unreliable and depended on particular settings. Calif has since published working attacks against 11 widely used PHP applications, and VulnCheck said late on 22 October that its exploit works unchanged against PHP 8.4 with a standard memory protection switched on. With this volume of attempts and working exploits in circulation, we would treat any unpatched PHP server on the internet as at risk of compromise.

Patching is moving. The internet scanning firm Censys has seen about 7.9 million internet services move to fixed PHP versions since 21 October, most of them in the past day, while about 33.5 million still show affected versions. These are counts of services, each an address and port, not of websites. PHP has also published minimal fixes for the unsupported 7.4, 8.0 and 8.1 versions. The harder cases are products with PHP built in. The Dutch National Cyber Security Centre is tracking appliances, network devices and management consoles whose owners cannot update PHP themselves and have to wait for the vendor.

The wider wave

Not every incident this month is connected, and several have nothing obvious to do with AI. Most follow a similar pattern, though: an attacker reaches a shared layer that many organisations trust, and the damage spreads from there.

The first layer is trust in software itself. Websites prove who they are with digital certificates, which work like ID cards vouched for by a small number of trusted issuers called certificate authorities. One of those issuers, India's eMudhra, had eight signing keys so weak they could be worked out almost instantly; one of them was simply the number 4. With those keys, anyone can make convincing fake ID cards. Someone who controls your network connection, such as the operator of a rogue Wi-Fi hotspot, could then pose as a trusted site, including the servers developers download Python software from, and slip in malicious code. Updating your computer's operating system does not close this gap for developer tools such as pip and uv, because they keep their own lists of trusted issuers and need updating separately. eMudhra said on 22 October that it will leave the global website-certificate business. A hijacked release of LiteLLM, a widely used AI gateway library, carried a credential stealer for about two hours on 21 October. Attackers also swapped OVHcloud's command-line tool downloads for a stealer for up to 94 minutes, and briefly altered the update settings of AOMEI's backup software to deliver malware.

The second is hosting platforms. Railway said an intruder may have accessed the encrypted secrets customers stored with it and decrypted some of them. It restored deployments for all customers late on 22 October, but the secrets it held still need replacing. Zeabur, breached through leaked internal credentials, exposed 321,810 accounts and about 3.2 million stored configuration values. It will start shutting services down on 1 December and close completely by 31 December. PingCAP confirmed that attackers used stolen credentials to reach its internal systems and copy TiDB Cloud customer records, though not customer databases. These platforms hold the keys that connect customers to their databases, cloud accounts and AI providers, so one breach becomes many. Shared services in healthcare carry the same risk: Quest Diagnostics disclosed on 22 October that an intruder had accessed patient records through Quanum, a system some clinics use to order tests and get results.

The third is the internet's front door. GitLab patched a flaw that lets an attacker run code on self-managed servers without an account, affecting releases back to 2014. NGINX and several HTTP/3 libraries needed fixes, attackers are taking over Plex media servers that missed an August update, and ransomware groups are still getting into companies through a Palo Alto Networks VPN flaw that was patched in May.

AI also appeared in the attacks themselves. Reuters reported that one attacker used AI agents, coordinated through an open-source tool called Cairn, to try more than 1,200 websites and break into those of more than 100 companies, for a few thousand dollars in model costs. A researcher could watch because the attackers left their Cairn control panels open on the internet. The break-ins he verified used long-known weaknesses, and the agents made finding and using them faster and cheaper. Japan's national computer emergency team, JPCERT/CC, has seen Cairn and two similar tools, CyberStrikeAI and ARTEX, in attack attempts of its own. Microsoft says a group it calls Storm-0940 used ARTEX in the campaign that stole ConnectWise's application credentials and reached customers' Microsoft 365 accounts, sometimes gaining privileged cloud access in under three hours.

We read the wave as AI changing both sides at once. Defenders and AI labs are finding long-hidden bugs in bulk, which produces bursts of urgent patches. Attackers use the same models to read those patches, automate break-ins and go after the AI libraries and keys that developers now depend on.

We've assessed the key incidents in this wave (so far). Choose the view closest to your role to see which matter most to you, how each one is fixed and what to do next.

What this means for the cloud

The largest cloud providers' core services are intact as we write. The damage thus far sits in the layers built on top of them: hosting platforms, database services and developer tools that hold customers' long-lived keys. Zeabur's attackers signed in to 101 servers running on Google Cloud using credentials Zeabur itself had leaked; no flaw in Google's systems has been reported. The risk to AWS, Azure and Google Cloud is indirect. Keys and service accounts harvested from these smaller platforms give attackers a way into cloud accounts that looks like legitimate use.

In our Mythos piece we described a possible future in which the hyperscalers retreat into hardened cores while smaller organisations and neglected projects absorb the disruption. This month fits that picture. We expect customers and regulators to push sensitive work towards the providers with the strongest security, and platforms that store static secrets to come under pressure to replace them with short-lived credentials tied to each workload. That would improve security, at the cost of concentrating more of the internet in a few companies.

Takeaways: Most of this week's incidents can be fixed, and the fixes are known. These are the steps we would take now:

1. Update PHP on every server you run to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your operating-system vendor's patched package, then restart PHP workers and rebuild container images. PHP has published minimal fixes for 7.4, 8.0 and 8.1, and anything older needs upgrading. Updating WordPress and its plugins does not fix PHP2Shell, because PHP sits underneath WordPress. If a hosting provider or supplier runs your site, ask them to confirm they have installed the fixed PHP version.
2. Treat any PHP server that was open to the internet before you patched it as possibly compromised. Look for unexpected files, processes and outbound connections back to at least 17 October, and replace the database passwords and API keys it held.
3. Find the PHP you don't manage directly. Appliances, network devices and management consoles often have it built in, so check your vendors' advisories and the Dutch NCSC's product list. OpenAI's PHP2Shell checker shows which of your PHP versions are still unpatched. Keep Cloudflare's managed rules, or an equivalent web application firewall rule, switched on while you patch, as a stopgap rather than a fix.
4. Update pip, uv and certifi in every environment, build runner and container image, starting with pip itself from the hash-checked link in the Python security guidance. Python 3.15.1, 3.14.9 and 3.13.17 ship the fixed pip for new environments.
5. Rotate every secret ever stored on Railway or Zeabur at the service that issued it. Redeploy on Railway, and move off Zeabur before it closes. Replace TiDB Cloud management API keys, as PingCAP advises.
6. Scan developer laptops for known-bad packages, editor extensions and AI tool settings with Perplexity's open-source Bumblebee, which reads what's installed without running any of it, on macOS and Linux. If LiteLLM 1.107.0 or a tampered OVHcloud tool ran anywhere, rebuild that machine and rotate every credential it could reach.
7. If you use ConnectWise Cloud Backup or older SkyKick integrations, keep them disconnected until ConnectWise issues restoration instructions. Check Microsoft 365 for unfamiliar app sign-ins, added credentials and role changes, because disabling the integration does not remove access an attacker has already set up.
8. Upgrade self-managed GitLab, NGINX, Node.js, Next.js and Palo Alto firewalls running GlobalProtect, then end all active GlobalProtect VPN sessions so that anyone already connected has to sign in again.
9. Take Jason Clinton's advice and ask your board this week for help with the basics. For most firms that means an up-to-date list of the software they run, people who can patch it within a day, and a record of which keys each system holds.
10. On public or shared Wi-Fi, such as in hotels, cafés and airports, use a trusted VPN that covers the whole device. It makes it much harder for someone on the same network to intercept your connection and pose as a trusted site, the kind of attack the eMudhra keys allow. It adds protection but does not replace updating your software.

These steps deal with this week's incidents. Our AI Cyber Action Plan covers the longer job: ten controls for a business that has to assume attacks will now move in hours.

A question many boards and business owners are asking themselves during Black October is which security standard they should now be working to. Attackers are moving from a newly disclosed flaw to millions of attempts within hours, and firms want to know whether the certificates they hold, or are working towards, prepare them for that.

Any answer has to start with how few UK businesses work to a recognised standard at all. According to the government's Cyber Security Breaches Survey, published in April, 5% of businesses hold Cyber Essentials, the government-backed baseline, while 24% say they have its technical controls in place. Many firms believe they're covered without ever having had that belief tested. Only a quarter have a formal incident response plan, and of the 31% using or considering AI, only about a quarter have any security practices for it. The fieldwork ran from August to December 2025, before the current generation of frontier models and well before Black October.

The standards on offer were also designed for slower attacks. Cyber Essentials is the natural starting point for most UK firms: it's cheap, and insurers and government buyers ask for it. Its patching rule gives firms 14 days to install critical and high-risk updates. PHP2Shell was being exploited before there was anything to install, so a firm that patched on day 13 would have met the standard while being exposed for the whole period that mattered.

The current requirements, version 3.3, also leave out two things this year's attacks have depended on. They describe backing up data as "not a technical requirement". And they never mention API keys, access tokens, service accounts or any other credential that machines use to authenticate to each other; the access control section is about people logging in.

Machine credentials are leaking faster than ever. GitGuardian's annual count of secrets exposed on public GitHub, which recorded its largest yearly rise in 2025, found that leaked credentials for AI services rose 81% in 2025, and that 64% of secrets confirmed as valid in 2022 were still valid in January 2026, so most leaked keys are never replaced. Flaws like PHP2Shell can expose the keys held on a server, and patching does nothing about keys that have already been copied.

The other frameworks UK firms turn to cover more ground than Cyber Essentials, but none of them deals with how quickly attacks now move. The table below is our assessment of the main options.

Meanwhile the threat has changed. Verizon's 2026 Data Breach Investigations Report found that exploiting a software flaw has overtaken stolen credentials as the most common way into an organisation for the first time in the report's 19 years, and that the median time to fix a flaw known to be under active exploitation was 43 days. For most firms a breach is likely, and the speed of their response will largely decide what it costs.

Firms that don't yet hold Cyber Essentials should still get it, as a minimum. ISO 27001 takes the best part of a year and won't help with anything that happens this quarter. Firms also need a short set of controls built for the attacks happening now, which is why we've written the AI Cyber Action Plan.

The AI Cyber Action Plan

The plan has ten steps. The first five make a breach less likely. The second five assume one will happen anyway, and focus on finding it within the hour, limiting the damage, cutting off the attacker's access and keeping the business running. Recovery gets equal weight because some attacks can't be reliably prevented, including flaws exploited before a patch exists and malicious updates delivered through a trusted supplier. We'll tighten its time limits as attacks speed up.

Most organisations won't have considered step five, because the risk it addresses barely existed two years ago. People tend to think of an agent as a fixed thing with a name and a set of permissions. In practice, what an agent does depends on everything that has entered its session: the instructions, documents, emails and web pages it has read along the way. A single hostile email can turn a well-behaved agent into one working for someone else, without its identity or permissions changing at all.

This week's announcements show how much of the problem is still open. Axios reports that banks are struggling to tell whether an agent acting in a customer's account is doing what the customer asked. Anthropic's new Claude Duet asks a person to approve sending, paying, signing and deleting, Walmart is giving shopping agents their own profiles with purchase approvals and spending limits, and 1Password now lets agents sign in without ever seeing the password. Each of these deals with who the agent is, what it holds or which actions need a person. None checks what the agent has read before it acts. Tying an agent's permissions to the contents of its session is technically demanding with today's tools, and it's a problem we're keen to help clients work through.

Step ten covers a risk most supplier questionnaires miss: the failure of a provider that large parts of the business depend on. The faulty CrowdStrike update of July 2024 crashed about 8.5 million Windows devices, and Black October has shown the hostile version of the same risk, with attacks arriving through trusted software and platforms.

Takeaways: Most UK businesses don't work to any recognised cyber standard, and the most widely used one, Cyber Essentials, was written for attacks that unfold over weeks rather than hours. Firms should still get it as a baseline, but it isn't a plan. The AI Cyber Action Plan sets out ten steps, split evenly between preventing a breach and recovering from one, with time limits measured in hours rather than weeks.

Our chart this week counts the software security flaws given a CVE (Common Vulnerabilities and Exposures) number each year since the system began in 1999. A CVE is the public record that suppliers and security teams use to track a flaw and its fix. From 2005 to 2016 the count stayed between about 4,000 and 8,000 a year, then climbed steadily to just under 48,000 in 2025.

2026 has broken that pattern. 85,333 records have been published so far, more than double the same point last year. The weekly rate rose from about 1,400 in the first half of the year to about 3,000 from July, and the week of 12 October set a record of 5,460. At that rate the year will end close to 120,000.

Google's threat intelligence group found monthly disclosures doubled between January and July, and IBM X-Force counted an almost sevenfold rise for Microsoft, Oracle, Google Chrome and Apache. Neither can prove the cause, but both point to AI tools finding flaws at a scale human researchers cannot match. Google found the flaws it could trace to AI were also more serious: half let an attacker run their own code, against about a quarter of all CVEs.

Only a small share are used in attacks. CISA has added 270 flaws to its list of those known to be exploited this year, against 85,000 new records. And in April NIST said it could not clear its backlog of records awaiting analysis, so many now arrive without a severity score. Keeping up is a matter of filtering:

• Know what you run. Keep a current list of your software and versions, including open-source packages, so a new advisory can be matched in minutes.
• Act on what attackers are using. New entries on CISA's exploited list come first, and deserve a fix within days.
• Rank the rest by likelihood. A severity score says how bad a flaw could be; EPSS estimates how likely it is to be exploited in the next month.
• Don't wait for NIST. Where its analysis has not arrived, use the supplier's own rating or the score CISA adds to many records.
• Follow your suppliers. Subscribe to security notices for internet-facing systems such as firewalls, VPNs and email servers, which are frequent targets.
• Automate the matching. A scheduled script or scanner can compare these feeds with your software list each day and alert only on matches.