Responding to AI's Black October

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.