If you run PHP anywhere in your stack and did not upgrade, stop reading this and go upgrade to a patched version. More information on this is on our advisory blog, and check out php2shell.aikido.io to see if your service is potentially vulnerable.
Last week saw the biggest few days in cybersecurity potentially of all time, and I don’t think I’m being hyperbolic. The floodgates opened with vulnerabilities, but the biggest headline was PHP2shell.
Many sites went offline to update, surprising many of us at just how much of the web still runs on PHP (70% by some accounts!). The issue went mainstream.
PHP2Shell hid in PHP’s runtime for about twenty years, but then multiple groups found the same vulnerability in a short period of time this year. This month, attackers were trying to exploit it days before PHP had even announced a fix was coming. AI has changed the game, and any leaks about a vulnerability or its patches are more dangerous than before. This means the next big vulnerability could come with less notice, and the teams responding need to be ready to respond and patch quickly.
How the PHP2Shell disclosures unfolded
A recap of the timeline for the PHP2Shell disclosures, to set the stage.
The out-of-memory issue behind the first of the two PHP2Shell vulnerabilities had already turned up in a 2024 audit by OSTIF and Quarkslab, but it stayed unfixed because nobody had shown it could be exploited. It was found again in 2026, when Calif and Wiz found the flaws independently with proof of exploitation (Calif reported as part of OpenAI's Patch the Planet initiative). PHP’s security team confirmed the reports and spent the following weeks building fixes for every supported branch. The details were kept under embargo ahead of a coordinated release.
PHP originally planned to release the fixes on October 22. When the CVE IDs, CVE-2026-109618 and CVE-2026-109619, leaked on October 20, PHP published its pre-announcement at 19:30 UTC that evening and moved the release up a day, to 14:00 UTC on October 21.
Aikido was part of a group of organizations given early information, and the run-up to the patch was chaotic. Each new leak raised the odds that attackers would move before the patches were released, and members of the group debated whether to share mitigations early or adjust their own timelines. We believe coordinated disclosure deserves support, so our patched images went out after PHP's announcement on October 21.
Leading up to the release and hours after, a large share of the internet went into maintenance mode while they hurried to apply patches. Censys has tracked PHP2Shell exposure since October 21. As of October 27, about 11.2 million PHP services had moved to a fixed version, roughly a quarter of those reporting a version, while 32.5 million still ran an affected one. More than 60 million PHP services don’t report a version at all, so the true exposure is likely higher. Track the live numbers on the Censys PHP2Shell page.
Exploitation attempts are now widespread, and a few successful attempts have also appeared. In one public test, security researcher James Pavur set up an unpatched PHP 8.4.26 server with about $2,000 in bitcoin as the prize, and a participant broke in about three hours after the server started serving a page that ran PHP.
The PHP Foundation's post-mortem and Calif's write-up have the full timeline from discovery to patch release.
AI is finding more vulnerabilities faster
PHP has powered a large share of the web for three decades, so those running it assumed they'd already found its serious bugs. "We don't know when the next CVE is going to come from. And it could be in a piece of software that nobody's even thought to have built in the last 20 years," says Benji Kalman, SVP Engineering at Aikido.
The PHP2shell vulnerability had also been around for a couple of decades, but as an undiscovered ghost. The fact that Calif and Wiz found it only a few weeks apart reminds us that the AI is going to be finding these faster.
We tested out how fast we could find these PHP vulnerabilities ourselves. After the disclosure, we pointed Aikido's AI Code Analysis at PHP, and it rediscovered PHP2Shell in a few hours. We've been running it against open source libraries, but hadn't yet tested the languages underneath them.
Researching more of these vulnerabilities to light could be seen as risky, if it’s bringing attention to a vulnerability that no one knew about for decades. But if a defender's tool can find a bug like this in an afternoon, attackers' tools won’t be far behind. So it’s a prisoner’s dilemma of sorts— attackers are going to start looking for vulnerabilities in everything they can find and their tools will keep getting better, so defenders can’t be in the dark. The good hackers will also have to keep looking for vulnerabilities in open-source libraries and languages. Security teams should plan for the next urgent patch to be released overnight.
Coordinated disclosure has to move faster
With AI, attackers can start working from very little information, which is what makes a disclosure of this severity hard to manage. "Even the hint. You just say there is a vulnerability in PHP. I can already hear all of the GPUs spinning up in the data center," says Charlie Eriksen, Aikido's lead malware researcher. "We're in these situations where the time to discovery and time to exploitation are really being compressed, and we have so many different people that can discover these vulnerabilities very quickly."
The speed makes coordinated disclosure more valuable than ever, but harder to get it right. Warnings and pre-announcements, while they help people prepare to patch or take services offline, also tell attackers where to look. "The warning can also cause you damage. That's a really challenging dynamic," Charlie says.
For PHP2Shell, the pre-announcement might have been scheduled too far in advance of the initial release. PHP's team moved the release forward a day once the CVE IDs and POCs started showing up. But Amazon says the first exploitation attempts began on Saturday, October 17, three days before PHP’s pre-announcement on October 20 (we can’t speculate as to the reasons why).
Once a patch is public, attackers have far more to work with than they did before. With the patches as input, Charlie estimates that someone who knows what they're doing could build an exploit with an LLM in a few hours. For PHP2Shell, Trail of Bits built a working exploit in a day with Codex.
For vulnerabilities that need coordinated disclosure, the process has to get faster and tighter. Embargoes should be shorter, and technical details should reach as few people as possible, because every extra day and every extra party adds a chance of a leak.
What shorter embargoes mean for the majority
Shorter, tighter embargoes help teams by shrinking the window for leaks and early attacks, but also leave less time for everyone downstream to get ready.
The official fix and the fix a team can actually install don’t always appear at the same time. On the afternoon PHP released its patch, SUSE and Fedora updates were still in testing, and Debian unstable was still shipping the vulnerable 8.4.26. On shared hosting, site owners can’t patch PHP themselves, so they wait on their provider.
Protective layers depend on early notice as well. CDN and WAF vendors that know in advance can ship blocking rules on day one, as Cloudflare did when it extended its WAF rules to every plan, including the free one, before the patch was out. With fewer vendors briefed, the safety net gets built later. Warnings may also get shorter and vaguer to slow down hackers, which leaves teams less time to plan maintenance.
If the warning times have to get shorter, security teams need to make sure they can receive alerts on time and be prepared to turn around patches quickly, or have security tools that do so automatically.
What teams can do before the next internetbreaks2shell
The basics come first. First, start with knowing what you run. "The first thing you obviously need to know is: what is my potential exposure? Have an inventory of stuff," Charlie says. That inventory needs to cover every runtime and dependency you run, including the ones you didn’t install yourself. PHP2Shell is a good example, since PHP often shows up inside container base images, CI images, hosting panels, and vendor software.
Next, pick your information sources carefully. In the first hours of an incident, the most useful sources keep their information current as things change, and they go past describing the problem to give you mitigations and, above all, fixes you can deploy.
Check with your current or prospective security vendors to see how they help and communicate these types of issues:
- Do they update their guidance as exploitation develops?
- Do they send live incident alerts so the right person hears about it without having to scroll Twitter constantly?
- Do they inform you of only the most important incidents, or do they flood you with AI vulnerability slop noise?
- Do they explain how to reduce exposure while you wait for a patch?
- Do they give you the fixes?
During PHP2Shell, we updated our advisory as the incident developed and sent live incident mailers. We published a free checker at php2shell.aikido.io so website owners could test whether their sites showed had the PHP2Shell memory-exhaustion behavior.
We also shipped backported fixes for PHP2Shell through Aikido Images. The free images on Aikido's public ECR cover PHP 5.5, 5.6, the 7.x series and 8.2 through 8.5, and they went out shortly after PHP's official release. Teams could (and still can!) pick up a fixed image without taking on a major PHP upgrade themselves.
"We want to make sure that we're patching in place, as we call it. So that means we're not asking you to move to an entirely different OS or something unique," Benji says. "It's as simple as pulling the image from the ECR and switching that out inside your Dockerfile."
We don’t recommend Renovate bot-style behavior, where everything is upgraded to the latest versions automatically. That constantly breaks your app, so eventually teams turn it off. Teams need to be protected without introducing vulnerabilities, so lock in place with lock files and only upgrade as CVEs pop up.
"The net is vast and infinite"
While PHP2Shell was stressful and somewhat chaotic, defenders can still come out ahead.
“I think the defenders still have the advantage at the moment. You do have to put in the work, of course,” Willem Debare, CEO of Aikido, said about the vulnerabilities last week.
If you start building resilience now, you will be among the ones still standing when the dust and code buffers settle.
P.S. Some of the web won't make it through this. A lot of it still runs on old PHP installs that aren’t maintained anymore. The Atlantic warns that many will be pulled offline or hacked, and some may never come back. RIP, beautiful early 2000s internet.
