New data shows that organizations aren’t moving to patch PHP2Shell as fast as attackers are moving to exploit it. It’s understandable, cybersecurity experts say, because updating in this case is especially complicated.
The data began trickling in on Oct. 21, painting a picture of the world’s initial response to the new PHP vulnerabilities. The picture wasn’t pretty.
Some well-positioned experts picked up on a remarkable volume of threat activity. Cloudflare CEO Matthew Prince stated that in the 10 hours before the vulnerabilities were publicly disclosed on Wednesday, his company observed thousands of exploitation attempts. “That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now,” he wrote on X, late on Oct. 21.
The next day, Check Point Research claimed that attempts at exploitation had already reached 10% of organizations worldwide. On the flip side, only a small percentage of vulnerable organizations have been visibly updating to new PHP releases.
Using discoverable deployments on Shodan as a sample, Ox Security researchers found that more than 99% of instances were not yet advertising a newly patched version 24 hours after fixed versions were made available. Researchers at Flare piled on, noting that 73% of those instances advertised PHP branches that no longer receive updates from the PHP Foundation. (It also qualified these figures, noting that basic Internet scanning misses some crucial nuances.)
Meanwhile, Cisco Talos estimated, based on open source intelligence (OSINT), that around half of all PHP systems won’t receive patches.
On the morning of Oct. 23, Eastern time, Ox informed Dark Reading that its 99% figure had dropped to 97.5%. And Flare told Dark Reading that of the 27% of public records reflecting upstream-supported branches, about 5% have been updated.
Addressing PHP2Shell is often not as simple as clicking “Update,” practitioners acknowledge. Still, there are steps that most organizations can take to protect themselves immediately, like diligently looking for PHP deployments across an organization’s entire fleet of systems, hunting for signs of compromise, and restricting access to or otherwise taking offline any systems that can’t be patched immediately.
Step 1: Find PHP, Everywhere
In principle, protecting against PHP2Shell should be simple. There are new versions one can update to, which cover the vulnerabilities in question, CVE-2026-109618 and CVE-2026-109619. In practice, addressing PHP2Shell will look very different from one organization to the next, and require more or less effort, depending on how, where, and in what ways they use PHP.
The unanimous first step all cybersecurity experts point to is that organizations should discover and inventory all of the assets they have running PHP. It’s easier said than done. As the Cybersecurity and Infrastructure Security Agency (CISA) noted in an Oct. 21 security alert, PHP isn’t just something that runs websites, it’s “often a component of other software and prevalence may not be directly observable.”
Flare researchers saw that firsthand when examing the attack surface. “What stood out to me during the research was how much PHP we found outside conventional web hosting,” says Adrian Cheek, senior cybercrime researcher at Flare. “We identified it in storage devices, physical access-control systems, cameras and remote-access interfaces. If you’re only looking at your main websites or limiting an external assessment to ports 80 and 443, you’re going to miss some of that.”
For organizations with this sort of exposure, he continues, “You generally can’t log into a storage appliance or physical access-control unit and independently upgrade its PHP installation. You need the manufacturer to provide updated firmware. If the manufacturer has stopped supporting that product, the organization may have no patch available.”
Not So Simple as Clicking “Update”
Putting edge cases aside, let’s assume that an organization has managed to find and list out all of its PHP deployments. From there, remarkably, things only get more complicated.
Publicly available data seems to suggest that most PHP out in the world is running on old branches. “If you’re running an application built around PHP 5 or PHP 7, moving to a current PHP release could mean rewriting parts of the application, replacing dependencies, and testing everything that might break. There’s a good reason why organizations avoid doing that casually, particularly when the application supports something operationally important,” Cheek explains.
In these cases, remediation will be a slow process, if organizations choose to pursue it at all. Luckily, and confusingly, old PHP versions aren’t always unsavable.
The most common version in public records, 7.4.3, is what shipped with Ubuntu 20.04. As Cheek points out, “Linux distributions frequently retain an older PHP version number while backporting security fixes. So an old version number doesn’t automatically mean the software hasn’t been patched.” Besides operating systems, applications can also backport fixes for the PHP they come packaged with.
Thus, organizations running outdated PHP actually fall into very distinct buckets: Some organizations will need to do the heavy lifting necessary to migrate or replace their applications or products. In the meantime, experts say, they should consider taking their vulnerable systems offline entirely. Cheek also offers one pro tip to mitigate CVE-2026-109619, for those that can reach the PHP configuration.
“The reported attacks run through PHP session upload progress, a feature that is on by default and needs no session_start call in the application. Disabling session.upload_progress.enabled and restarting the PHP workers blocks the confirmed session-upload-progress attack paths without requiring a PHP version upgrade,” he explains, with the qualification that it doesn’t address the other PHP2Shell flaw, CVE-2026-109618, so it’s a temporary measure at best.
Some organizations will be privileged enough to install backported fixes through their vendors. On Oct. 21, Ubuntu developer Canonical published fixes for PHP2Shell for all versions since 14.04. Even these relieved parties will have more accounting work to do, since an OS or application update doesn’t necessarily carry a full PHP version upgrade. If one takes advantage of Ubuntu’s updates, future scans could continue to show it ostensibly running PHP 7.4.3.
And don’t forget, Cheek says: “The restart matters. Installing a corrected PHP package doesn’t necessarily replace the interpreter already loaded into running worker processes.”
Each PHP2Shell Case Will Be Different
Besides all of the technical details, size will determine a lot about how organizations can respond to PHP2Shell.
As with any urgent cybersecurity vulnerability, small businesses may start off with disadvantages in awareness as well as the resources needed to get themselves cleaned up. Yet after 48 hours of working nonstop to help more than 1,000 organizations with PHP2Shell, OX Security CEO Neatsun Ziv is quicker to point out the advantages in being small. “
At small organizations, you can do whatever you want. You just go in and patch. You wait five hours. Nobody complains about breaking anything,” he says.
But larger organizations are different, he says. “They’ve got a golden image — one server baseline they update,” Ziv says. “It’s always a downstream model: you deploy a new golden image, this golden image is then being built with new software, this new software goes to production, and nobody can change production. This is the norm in deployments today. Nobody goes to servers and actually patches them. It just becomes unmaintainable in the long term.”
And that’s to say nothing of just how many people from different teams need to be involved in major updates within a large organization; or of how major organizations run disproportionately significant systems that can’t afford to break; or of how prevalent and varied PHP can be even within organizations. As Ziv notes, “Most of the organizations that we work with found hundreds of servers that are running PHP.”
Check Point chief security and trust officer Alex Spokoiny adds that even beyond one’s own house, organizations also face risk from how all of their suppliers handle PHP2Shell.
“The first step is to engage the relevant suppliers and understand how they are responding. Are they affected? What protections have they put in place? When do they expect remediation to be completed? If you cannot get clear or reasonable answers to those questions, that is itself something you need to factor into your risk assessment and potentially consider alternative options,” he advises.
Organizations can also team up, to everyone’s benefit. “For example, where technically possible, they may be able to extend their own Web application firewall (WAF) protection to applications operated by third parties, helping reduce exposure while the provider works toward a permanent fix,” Spokoiny says.
