After Black October: The New Climate

In late October PHP broke, and most of us have already moved on

On 21 October, two bugs in PHP briefly looked like the end of the world. PHP runs roughly 70% of websites whose server-side language is known. Finland, the Netherlands and France pulled government sites offline. Patches shipped in a day, the leaked exploits mostly didn't work, and by that Friday most of us had moved on.

Then on 24 October a honeypot caught the first confirmed compromise in the wild. Most made it through, but not seeing this as an inflection point is survivorship bias. We were spared by how hard the exploit was to pull off, not by how fast we patched. Within a week, though, attackers had chained PHP2Shell with a Linux kernel flaw to take root on 25 internet-facing systems, and Palo Alto Networks confirmed attacks on its firewalls.

People have started calling it Black October. In the same few days, a certificate authority's signing keys turned out to be guessable, a popular AI gateway shipped a release that stole developers' keys, and Node.js and GitLab rushed out critical fixes. As one analysis put it, this was "a disclosure wave, not an attack wave": most of these weaknesses had been sitting there for months or years.

PHP2Shell is not a one-off storm, or some bad weather. It is the new climate. This is the first in a series I'm writing on what AI is doing to the attacker's job and the defender's. It starts with late October: what happened, why it matters, and what I'd do about it if I were a practitioner, a security manager or a CISO.

Three months from AI discovery to rooted firewalls

An AI model found the first bug on 1 August, and it was reported to PHP ten days later. Attackers were probing for it four days before a patch existed, and a working compromise was confirmed three days after the patch shipped. Within another week, attackers were taking root on live systems.

For context, Mandiant puts the average time to exploit at 63 days in 2018–19, 32 days in 2021–22 and 5 days in 2023. Enterprises still take about 55 days on average to fix high and critical vulnerabilities (Edgescan, 2025 data). Exploitation was already outrunning patching. Now AI is speeding up discovery as well.

What broke, and why it matters more than the CVSS score

PHP gives each request memory from its own heap and wipes it when the request ends. PHP2Shell exploits the boundary: after an out-of-memory crash, persistent memory can still point into request memory that has been freed and handed to someone else.

Zend memory manager, simplified · where PHP2Shell strikes

Defenders usually get some breathing room because a new bug is obscure, hard to exploit or needs a particular app setup. PHP2Shell took that breathing room away, and there are five reasons why.

1. It's in PHP itself, before your app even runs. The bug sits in how PHP handles session upload progress, which is on by default. It fires before a single line of your application code runs. So clean code, a decent WAF ruleset and a tidy SDLC don't help you here.
2. Humans found it in 2024 and parked it as too hard, until AI made it practical. When PHP runs out of memory mid-request, it can leave pointers to freed memory in state that survives into the next request on the same worker. That is a use-after-free, in one of the most mature, most picked-over codebases on the internet. The uncomfortable bit is that it wasn't a secret. A PHP core developer spotted the out-of-memory problem in 2024, during the project's first outside audit in over a decade. Someone theorised an exploit, nobody could make it work, and every fix on the table broke something (backward compatibility, a new denial-of-service risk, or thousands of third-party extensions). A small security team that works by consensus did what small teams that work by consensus do, and the fix stalled for months. The PHP Foundation's own words for that are "a structural failure". Then in August at least three teams, all using frontier models, found it independently and had it working within days. That's what should worry us. AI didn't find a bug nobody knew about, it took one everyone had filed under "too hard" and handed it to anyone with a frontier model and a few days to spare.
3. The exploit chain is clever, and it's repeatable. Leak memory back over the wire to defeat ASLR. Forge a fake HashTable whose destructor points at system(). Read /flag.txt, or anything else. None of the individual steps is new. What AI changed is how cheap it is to put them together.
4. "No working PoC" doesn't mean "safe". The public exploit that surfaced on 23 October only worked on a cut-down build: a couple of Apache workers instead of 150, an 8MB memory limit and debugging switched on. Real servers run 150 workers and 128MB, and as late as 27 October Wiz said it still hadn't seen a public exploit that worked end-to-end against an arbitrary target. That gap looked like safety, right up until Hack The Box's Offensive Research team closed it in three days... and if we can, attackers can.
5. Don't trust the version number. Distros backport fixes, end-of-life branches (7.3 and older) get none, and vendor appliances ship their own PHP. Patching depends on knowing the build, not reading the banner. Meanwhile, fake PoCs on GitHub hid payloads, so running untested exploit code was a risk in itself. An advisory tells you a bug exists. Only skilled people testing it safely against your own environment, the way a red team would, can confirm you're exposed and prove the fix works. Threat intelligence is only as useful as the team that can act on it.

Put simply, a critical, default-on, pre-auth bug in software that runs most of the web was found and chained with AI's help, then weaponised by people within days.

The gathering storm broke: we're not even a year in, and it's accelerating

The tools have been on the market for a few years, but mass adoption of AI is a 2026 story. The tools I'm using in October look nothing like June. June looked nothing like March, and March looked nothing like January. The rate of change is itself speeding up.

PHP2Shell is what that curve looks like in security. Wiz says that with frontier models, "a single researcher completed in a week what previously would have taken a world-class team months of work." OpenAI's Greg Brockman put it more plainly: "We expect to find many more such issues over upcoming months."

That cuts both ways. The same models that help defenders find flaws that "survived years of scrutiny" also, in Wiz's words, "significantly lower the barrier to scaling attacks." So expect two things at once:

• More critical bugs in foundational software. Runtimes, libraries and protocols everyone assumed were picked clean.
• Less time between disclosure and exploitation. Days, sometimes negative days, as leaks and AI-assisted exploit work outrun coordinated disclosure.

PHP2Shell isn't alone. The same week, OpenAI's Codex Security team reported a memory-corruption bug in the Brotli compression library, which ships inside Node.js, .NET, Envoy and Python. By 25 October, Microsoft had shipped emergency out-of-band .NET patches for it, and the internet had already nicknamed it Node2Shell and HTTP2Shell. Earlier in October, an AI-assisted team at Tencent found a nine-year-old Linux kernel flaw. In January, AISLE's AI found 12 OpenSSL bugs, some dating back to 1998. And eMudhra, a certificate authority that browsers had trusted for years, turned out to have signing keys so weak that one was the number 4. A researcher cracked all eight on a laptop in under a second, an AI agent repeated it from a single prompt, and eMudhra is now leaving the certificate business. Google says monthly vulnerability disclosures doubled this year, and 141 flaws were exploited in eight months, against 127 in all of 2025.

And the pace hasn't slowed. At the end of October, Anthropic disclosed a Linux kernel TCP flaw rated 9.8 that lets a remote attacker take root on servers running multipath TCP, with no credentials or user interaction. It affects kernels back to version 4.4, Anthropic's AI-built exploit reached full control in under an hour, and as of 1 November Ubuntu and most Red Hat Enterprise Linux versions were still waiting for fixes. Days later, OpenAI said an AI pipeline had produced 948 working Linux root exploits in a single campaign, at about $1,279 each, and warned that a low-privileged account on an unpatched system "should be considered functionally equivalent to root access for a well-resourced threat actor."

But the raw numbers mislead. Only about 1 in 431 of this year's disclosures has been seen exploited, and FIRST says the share needing urgent action has stayed flat. Nobody can patch everything, and nobody should try. The real problem is having people skilled enough to spot the handful of bugs that actually matter, and move on them in days.

One PHP2Shell is a squall blowing through. A steady drumbeat of them is a climate.

The internet may not keep its current shape

If this becomes the cadence, leaving huge amounts of infrastructure directly on the public internet stops being a reasonable default. We saw the first signs in late October:

• Governments unplugged. Three EU states took their own sites offline rather than wait.
• Isolation became official advice. CERT-EU told organisations to consider isolating internet-facing apps from public networks until patched.
• Remote patching was floated. Brockman suggested that authorised defenders, such as governments, could scan for vulnerable servers and, "in extreme cases," patch them remotely.

The exposure is enormous: VirusTotal estimates more than 5.1 million PHP hosts are reachable online.

Patching discipline is critical. For real this time.

Patching has never been a strength for most organisations, and exposure on this scale makes that weakness impossible to ignore. Patching sloppiness has been a guilty secret in the enterprise for many years, bordering on a universal truism: monthly cycles, and exceptions that quietly become permanent. That just about worked when exploits took weeks to arrive. It doesn't when attackers are probing before the patch even exists.

Gartner made the same point in its first analysis of PHP2Shell: "Organizations that rely on slow, volume-driven vulnerability processes risk falling behind an attacker cadence that now scales exceptionally fast in both volume and opportunity."¹

But always ask the doctor about the side effects

But patching on autopilot cannot be the cure. Every remedy has potential side effects, and choosing between them takes judgement and context. PHP2Shell's interim mitigations show why. The interim fix was to change a setting (memory_limit=-1) to remove PHP's memory cap per request, so the out-of-memory error that triggers the bug never fires. But it also lets a single heavy request eat all the server's memory and take the site down. Restarting each PHP worker after every request stops stale memory carrying over to the next request, which breaks the exploit, but it slows everything down. Someone in each organisation has to understand the bug well enough to make that call, quickly, for their own environment. That's why I'm sceptical that the solution is solely (as many AI tools vendors will urge) "implement new AgenticUltraPatch 2000, AI Edition".

What to do this week, by role

Everyone has a part to play, but it's a different part depending on where you sit. Whatever your level, it comes back to understanding the vulnerability, knowing whether it affects you, fixing it, testing the fix, and being ready to do it all again next month.

Practitioners: analysts, engineers, pen testers

• Chase down every last PHP runtime. Most teams have patched the obvious servers by now. The risk sits in the ones nobody remembers, so include containers, vendor images and appliances, especially the management interfaces of firewalls and VPN gateways, which attackers are now targeting, and check the build rather than the version banner.
• If you haven't already, patch or mitigate. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Where you can't, set session.upload_progress.enabled=0 and restart all workers. That also covers the newer CVE-2026-115560.
• Go hunting for evidence. Run CISA's SIGMA rule. Look for multipart uploads carrying PHP_SESSION_UPLOAD_PROGRESS, out-of-memory fatal errors, worker crashes and oversized session cookies.
• Learn the chain before you need it. Exploit it in a safe lab so you recognise it in your own logs. Never run unverified GitHub PoCs on company kit.

Directors and security managers

• Operationalise the link between threat intelligence and a skilled human response. When an advisory lands, your team has to answer three questions fast. Do we know what this is? What is the impact on our organisation? What are the implications of any proposed fix? No AI can automate that judgement today.
• Measure your time-to-patch. For critical, internet-facing flaws, count it in hours rather than days.
• Agree the emergency path in advance. Decide now who can take a service offline or apply an interim mitigation without waiting for a change board. Then manage upwards and get your leadership to sign it off before you need it.
• Test what your people can actually do. Find out, hands-on, who on your team can read an advisory like this, reproduce the exploit and make the trade-off call. Then close the gaps with programmatic, rigorous skills development and preparedness drills built on real-world scenarios, before the next one lands.

CISOs and deputies

• Reset the board's expectations. Treat PHP2Shell as the baseline rather than the exception, and budget and staff for a steady run of critical events.
• Shrink what's on the public internet. Challenge every internet-facing service to justify its exposure.
• Hold suppliers to the same bar. Ask vendors how long their PHP2Shell response took, and what they shipped. Then go beyond asking for a software bill of materials (SBOM). Is it machine-readable? Does it cover the libraries their libraries depend on? Is it updated with every release, and published somewhere you can check, such as a trust centre? Just as important, is anyone on your side actually ingesting and monitoring it? Without that, "are we exposed?" falls back on your own deep software inventory, which anyone who has run endpoint management knows is far harder than it sounds.
• Rehearse the business decisions too. The hardest calls in an incident aren't technical: whether to pay a ransom, when to go public, what to tell customers. Run regular, threat-informed tabletops with leadership, legal, finance, comms and customer teams in the room. Then your CFO and General Counsel aren't debating a ransomware payment for the first time mid-incident, and Customer Success and PR already agree on when to make a statement. Have the conversations before the stakes are high.

Our standard: if it doesn't reflect a real-world production deployment, it doesn't ship

When a major vulnerability drops, the industry races to publish toy proofs of concept under artificial conditions. I don't think we always explain the philosophy behind our cybersecurity content at Hack The Box: There's a lot of noise and cyber professionals aren't generally complaining about excess tumbleweed in the office, so if it doesn't reflect a real-world production deployment, it doesn't ship.

One of our content leads made the point while it was all kicking off: when everyone is in panic mode and wants information now, fast and wrong does more damage than a day late and right. People read a toy exploit, decide it doesn't apply to them (or that it does) and act on that, when the test it was run against looks nothing like their estate. Knowing when something is good enough to ship, with the whole industry racing you, is a judgement call. It needs the same thing I keep coming back to in this piece: sane, qualified people with the skill and the nerve to make it.

In practice it meant being slower than the people we compete with, which nobody in marketing enjoys. The public exploit that landed on the Friday night ran on a cut-down image. Our first version ran on stock settings but could only squeeze 14 characters into the payload. That's enough to run id and take a screenshot, which is where most of the write-ups stopped. Getting from there to a full reverse shell, reliable over a real network, against an unmodified container with 150 workers, took three days and nights, a session-handling trick Orange Tsai published in 2018, and an approach from 9bie's public exploit work that widened the window to about 200 characters. None of that makes a good demo video. It's the bit a defender actually needs to see.

With PHP2Shell, it played out like this:

What happened, and what Hack The Box shipped

Together, the two labs cover both sides of the same attack. Teams can reproduce a real-world exploit in Dark Embargo, investigate the evidence it leaves in the web logs in dOOMs Day, and see how each offensive step becomes a detection opportunity. It isn't a single shared purple-team exercise, but it gives red and blue teams a common scenario to compare findings and test detections against.

This is what I believe an operational skills platform has to do now. When a new vulnerability lands, your people should be able to understand it, check whether it affects you, exploit it safely, detect it and fix it within days, in realistic environments rather than on slides. For PHP2Shell, Dark Embargo and dOOMs Day covered offence and defence within eight days of the patch.

For most security teams, the risk lives in the gap between "we've read the advisory" and "we've done this before". That's the gap we're trying to close, and PHP2Shell was a decent test of whether we can.

While everyone pushes agentic AI to automate the work, the bottleneck is still people

AI found these bugs and helped chain them into working exploits, but humans were absolutely essential in deciding what to do about them.

The numbers already show where the bottleneck is. Anthropic's scanner flagged more than 29,000 candidate vulnerabilities in six months, but people have manually reviewed only about 6,000 of them. Bank of America brought in 1,000 contractors, working alongside about 3,000 of its own staff, to patch flaws that Anthropic's Mythos found in its software.

Do we take the site offline? Do we accept the denial-of-service risk of an interim fix? Is that PoC real, or a trap? Is the box in the corner running a back-ported build, or an unpatched one? None of those calls were made by a model. Every one came down to human judgement, and what made the difference was whether the people making it had been there before.

As clichéd and marketing as this phrase is, this is our new normal. That doesn't mean panic, and it doesn't mean complacency because we got lucky this time. Most of the coming flood will never be exploited. AI will keep raising the volume, but it can't decide which few bugs matter in your environment.

This is the climate now. I'll keep writing about this as the weather changes, and if the last few weeks are anything to go by, there'll be plenty to write about.

Sources

• BleepingComputer: PHP2Shell security flaws now successfully exploited in the wild
• Wiz: PHP2Shell, AI uncovers critical RCE vulnerabilities
• JFrog: PHP2Shell, all you need to know
• SOCRadar: PHP2Shell affected versions and fixes
• Decrypt: governments unplug websites
• Calif: PHP2Shell discovery and disclosure timeline
• PHP Foundation: Today's PHP security release and how we're strengthening PHP security (21 October 2026)
• Wiz: PHP2Shell exploitation attempts and remediation trends (27 October 2026)
• ¹ Gartner, First Take: Fix PHP Now, but Fix Vulnerability Management Next, Paul Delory, Nitish Tyagi, Marissa Schmidt, Mark Wah, Matt Milone, Mitchell Schneider, Neil MacDonald, 22 October 2026.

About Hack The Box

Hack The Box is the leading cyber readiness platform for the human-AI cyber workforce, helping organizations develop and measure the capabilities of the people and AI agents responsible for modern defense. The platform delivers threat-informed learning paths, real-world labs and live-fire simulations that build and validate offensive, defensive and AI-enabled cyber capabilities. Trusted by the Fortune 500, government agencies, managed security service providers (MSSPs) and Frontier Labs, Hack The Box supports more than 800 enterprise customers and a global community of over 5 million cybersecurity professionals.

For more information, visit hackthebox.com