5 insights from scoping and discovering PHP2Shell

Executive summary

Rumors started circulating online on Tuesday, October 20 that a major remote code execution (RCE) vulnerability in PHP was about to be disclosed. What followed was a wild 24 hours of broken embargoes, exploit drops, and rapid-fire firefighting. Credit to Calif, OpenAI, and Wiz Research, who found the flaws, and the PHP security team, who developed a fix under extreme pressure.

On Wednesday, October 21, the PHP Foundation shipped fixes for PHP2Shell, the name given to two flaws in PHP: CVE-2026-109618 and CVE-2026-109619. The instructions to organizations are to find every PHP installation, patch it, and restart. But when decades-old technology makes up such a significant portion of the web, it's never as simple as it sounds.

Following our formal guidance to Axonius customers to find and fix vulnerable PHP assets, the Axonius Cyber Research team analyzed a sample of U.S.-based deployments to get a sense of the impact, and of what it takes to fix in practice.

Key findings: 

• 63% of U.S. organizations have at least one PHP install affected by PHP2Shell. 

• 47% of U.S. organizations run a vulnerable install in web-facing infrastructure.

• 52% of U.S. organizations run at least one install that requires more than a package update.

Below are five notable takeaways from the incident and the data behind it.

Takeaway 1: The timeline began before it started

The formal disclosure wasn't the first signal. PHP2Shell's CVE IDs leaked around 15:00 UTC on October 20, and fixes followed at 14:00 UTC on October 21. That left close to a day between "something critical is coming in PHP" and the list of fixed versions.

As response timelines compress, there's no sense in waiting around. Start scoping and discovery processes so you have a rough sense of what the impact might be. In this case, the early chatter was enough to take a moment to find where PHP runs, which versions, and which serve web requests. When the advisory lands, what's left is matching versions and fixing.

This incident is another reminder that a CVSS score is only one measure of risk. Asset and business context tell you more, sooner. Does the install serve web requests? Is it internet-facing? What does the system do for the business, and who owns it? Those answers let you rank exposure before the advisory lands, and they don't change when the score does. 

Net-net: don't wait for a scanner signature to match the CVE. Exploit attempts are already under way. This will likely be the new normal.

Takeaway 2: PHP's past, present, and future show up all at once

PHP has been around for a long time. We found that the typical affected U.S. organization runs six or seven different versions, spanning v5.4 to the current v8.5. 

The past stays broken. RHEL 7's 5.4.16 and RHEL 8's 7.2.24 are among the most common versions we saw in our sample, and neither has a fix today. In fact, 10% of U.S. organizations have no fix available at all.

The present is fixable, but rarely in one step. PHP fixed 8.2 to 8.5, and Linux vendors backported the fix to many of the builds they ship. Only 11% of U.S. organizations can close everything with package updates. Another 42% of U.S. organizations can fix some installs but not others, so they're patching and planning upgrades at the same time, and the installs nobody will patch set the timeline.

The future looks different again. Managed hosts and edge providers moved fastest this time: Cloudflare turned on WAF protection by default at 03:02 UTC on October 21, about 11 hours before fixes shipped, and managed WordPress hosts patched within a day. 

Depending on who packaged and runs it, each install's fix comes from a different place:

Takeaway 3: Prioritize what the internet can reach

RCEs are dangerous no matter what, but one thing that makes this especially scary is that as a web technology, it's more likely than not that the impacted assets are internet-facing. 

Looking across our sample environments, 47% of U.S. organizations are running at least one vulnerable PHP install serving web requests. Of those U.S. organizations, 71% of the vulnerable assets discovered are exposed to the internet. 

Back to our timeline point, these assets are the right baseline to start the response from, given that they pose a high risk. Another takeaway from this incident is how little the CVSS severity score factors into the risk profile. Whether it's a pure 10.0 or a 9.2 is largely irrelevant. What matters is the risk combinations: a vulnerable version, configured to serve web traffic, exposed to the internet, and what the asset does for the business. Is it a mission-critical customer-facing application or the internal lunch menu?

The combinations also decide the response, not just the order. An internet-exposed asset on a version with a package update is a patch-and-verify job. The same exposure on a version nobody will fix is a different conversation: isolating it or taking it offline needs an owner and a business decision, not just a ticket.

None of this depends on the advisory. Exposure and ownership can be mapped on the first signal, which is what makes starting early pay off.

Takeaway 4: Unsupported PHP is as common as supported PHP

PHP support runs on two timelines: PHP's own release calendar, and the vendor who packaged your build. Managed hosts run a third, but their PHP sits outside your inventory and isn't counted here.

By PHP's calendar, 51% of U.S. organizations run an affected install from a supported line. Nearly as many run lines PHP retired long ago: 47% of U.S. organizations run PHP 7, 41% run 8.0 or 8.1, and 36% still run 5.4 to 5.6. In all, 56% of U.S. organizations run at least one affected install on a retired line.

On the packager's clock, Ubuntu, Debian, Red Hat, Sury, and Remi backported the fix to many of those older builds, some only under paid extended support. It barely moves the number. Counting backports, 52% of U.S. organizations still run at least one install nobody has fixed, down from 56%.

The installs nobody has fixed fall into a few groups:

An organization can sit in several groups. For all of them, the options are upgrade, switch streams, or isolate.

Takeaway 5: The PHP you run is the PHP your Linux shipped

Five of the six most common affected versions are the PHP that came with the server: RHEL 9's 8.0.30, RHEL 8's 7.2.24, RHEL 7's 5.4.16, and Ubuntu's 8.3.6 and 8.1.2. They arrived with the operating system (OS), often as a dependency of something else, and stayed as long as the server did. 

This means the operating system, not PHP, decides how this ends. Ubuntu's 8.3.6 and 8.1.2 and RHEL 9's 8.0.30 got backported fixes, so a routine OS update clears them. RHEL 8's 7.2.24 and RHEL 7's 5.4.16 have no fix today, so clearing them means moving to a newer module stream or OS release. The installs look alike; the age of the OS underneath decides which kind you have.

And the fix comes from whoever packaged PHP, not from php.net. Most affected U.S. organizations get PHP from several sources, so they need several advisories at once:

The version number won't tell you which case you're in. A backported fix keeps the old number: Ubuntu 24.04's fixed build still reports PHP 8.3.6, and RHEL 9's still reports 8.0.30. Tools that match on version alone will keep flagging those machines after they're patched, while an unpatched 8.3.6 looks current enough to pass a glance. Only the full package version, checked against each vendor's fixed build, settles it.

Before the next one

The guidance for PHP2Shell was to find every PHP installation, patch it, and restart. The first step is where a lot of the time goes, but it's the one you can do before the advisory lands.

PHP2Shell won’t be the last of its kind. Both attackers and defenders have frontier models at their fingertips, and are directing its power at every technology, old and new. The next critical CVE could leak early too, hit software older than some of the people patching it, and carry a severity score that changes overnight. The organizations that move fastest will be the ones who already know what they run, where it lives, what can reach it, and who owns it.

Axonius customers can find the discovery prompts in our October 21 blog.

Methodology

Figures are aggregated shares of organizations in an anonymized sample of U.S.-based Axonius customers, from an asset inventory snapshot taken October 19, 2026.