Of the companies with internet-facing assets running an identifiable PHP version, 97% are using a version vulnerable to PHP2Shell.  Two-thirds have at least one asset running a PHP branch that has been unsupported for years. And for more than half of all companies running PHP, the version is not visible at all. 

As of October 21, 2026, just hours after the PHP security team released a fix, the picture across the internet’s third-party ecosystem is concerning. The question security leaders need to answer this week isn’t just “Are we patched?” It’s “Which of our vendors are still vulnerable?” And for many organizations, getting that answer will take more than checking their own systems.

The findings are based on Panorays’ continuous external monitoring of companies and 330,000 PHP-serving assets. Here’s what the data reveals, why it matters for third-party risk management, and what security teams should focus on over the next 72 hours.

What is PHP2Shell, and Why Updating Your App Won’t Fix It

PHP2Shell is the name given to two vulnerabilities in the PHP runtime itself: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS score of 9.2.

Wiz Research discovered the vulnerabilities with the help of frontier AI models and reported them in August. The PHP team released patched versions today at 14:00 UTC. The CVE identifiers leaked a day early, proof-of-concept code is circulating, and Cloudflare reported detecting exploit attempts against its customers during the leak window.

Both vulnerabilities stem from how PHP handles cleanup when a request terminates unexpectedly, typically because it runs out of memory.

In the first case, PHP is interrupted before internal request data is fully initialized, then incorrectly treats the partially initialized data as valid. In the second, state from a terminated request persists in the worker, allowing a subsequent request from another user to reuse it.

In both cases, the result can be memory corruption that enables unauthenticated remote code execution (RCE), or memory leaks that expose sensitive data—including passwords, tokens, and API keys—from other requests.

Three things make this different from the usual WordPress-plugin CVE:

  • The flaw is in the engine, not the application. Wiz demonstrated pre-auth RCE on stock WordPress, Drupal and Joomla, but a plain “Hello World” script on a vulnerable PHP is enough. Updating your CMS, your framework or your plugins does nothing. Only the runtime matters: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed.
  • Every version since 5.4 is affected. That covers more than a decade of releases, and most of the web.
  • If someone else runs your PHP, they have to patch it. Shared hosting, managed WordPress, agency-built sites, SaaS vendors on PHP stacks. That is the third-party problem, and it is where the rest of this post lives.

PHP’s guidance is clear: there are no complete mitigations, and updating to a fixed version is the only safe option. Keep that in mind when evaluating advice that claims a single configuration change can eliminate the risk.

What the data shows

We looked at every company in the Panorays monitoring database with PHP detected on an internet-facing asset: Over 350,000 assets, exported on 21 October 2026, before patched builds could realistically be deployed anywhere. We classified each asset by the PHP version it advertises against the fixed releases (8.5.12, 8.4.27, 8.3.36, 8.2.35) and PHP’s support status.

By branch, the most common versions in the wild are 7.4 and 8.2 in a dead heat, then 8.3, then 5.6. A branch that reached end of life in 2018 is still the fourth most common thing we see. Roughly a third of version-identified assets are on 8.x, a fifth on 7.x, and one in six on 5.x.

We also compared our customers, prospects, and partners against the broader internet population. They look the same: 61% of them have an EOL asset versus 66% of everyone else. Nobody should read this as a problem of careless companies. It is a problem of a runtime that is everywhere and that most organisations inherit from a host, an agency, or a vendor.

Two honest caveats. Banner-based version detection can be wrong in both directions: distributions backport fixes without bumping the version string, and reverse proxies sometimes report the wrong thing. And “version hidden” means exactly that, not “safe.” Treat these as a floor on exposure and a ceiling on what external scanning alone can tell you.

The visibility gap is the finding

The 54% figure is the one that stands out. More than half of the companies running PHP on internet-facing systems don’t disclose their PHP version. That means no external scanner, including ours, can reliably determine whether they’re vulnerable based on version information alone.

For teams managing third-party risk, that has a direct implication. Counting hosts with an old banner tells you where the problem is visible. It does not tell you where the problem is. For the majority of your vendors, the only way to know is to ask, get an answer you can hold them to, and verify it against what you can observe.

In other words, this is not a scanning problem. It is an assessment problem: external evidence to prioritise, a targeted question to close the gap, and a re-scan to confirm the answer was true. Scanning alone stops at 46%.

End-of-life doesn’t mean unpatchable

You may see reports claiming that only PHP versions 8.2 through 8.5 will receive patches, leaving older versions vulnerable. That’s not entirely accurate, and the distinction matters when deciding which vendors need urgent follow-up.

  • 8.2 to 8.5: official releases today. 8.2 itself reaches end of life on 31 December 2026, so a vendor on 8.2 is patchable now and needs a migration plan anyway.
  • 7.4, 8.0, 8.1: the PHP security team published minimal source backports on GitHub specifically for this incident. Anyone building from source, or any vendor with an engineering team, can apply them.
  • Linux distributions and LTS vendors (Debian, Ubuntu, RHEL, SUSE, CloudLinux and others) received the patches in advance and are shipping their own packages, including for branches PHP no longer supports. A vendor on “7.4” via a distro package may already be fixed without the version string changing. The volunteer remirepo.net repository, by contrast, will not have updates today.
  • 5.x, 7.0 to 7.3: this is the real dead zone. No upstream fix, no backport, and distro support is patchy to non-existent. The honest options are upgrade, take it offline, or isolate it behind authentication or a VPN until it can be replaced. CERT-EU recommended exactly that isolation step.

So when a vendor says “we’re on an unsupported version,” the follow-up question is “which one, and who built your package?” The answer separates a two-day fix from a two-month migration.

A 72-hour playbook for third-party risk teams

You can’t patch your vendors’ servers, but you can identify which ones pose the greatest risk, get clear answers from them, and verify their responses. Here’s the approach we’re recommending to customers today.

Hours 0 to 12: scope. Build the list of third parties that (a) run PHP on an internet-facing asset and (b) touch your data, your users, or your network. Start with what you can observe externally, then add the vendors you know are on PHP stacks even if their version is hidden: managed WordPress hosts, marketing and CMS agencies, e-commerce platforms, ticketing and support tools, anything that looks like Drupal, Joomla, Magento, Laravel, or MediaWiki. Don’t forget the vendors nobody onboarded: look at outbound DNS and SaaS-discovery signals, finance’s vendor payments and the SSO application list. Those shadow vendors are where most surprises live.

Hours 12 to 24: prioritise. Three questions decide the order. Does the asset handle our data or our customers’ data? Is it on an end-of-life branch, especially 5.x or 7.0 to 7.3, where no vendor patch is coming? Is it a single point of failure for a business process? High on two of three goes to the top.

Hours 24 to 48: ask, precisely. Send a short attestation, not a 200-question survey. The three questions that actually move things:

  1. For each of your internet-facing systems that process our data, what PHP runtime version is deployed today, and is it at or above 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or carrying a vendor backport for CVE-2026-109618 and CVE-2026-109619?
  2. If not yet patched, what is the committed date, and what interim controls are in place (WAF rules, isolation, upload limits, session upload progress disabled)?
  3. Who operates the PHP runtime: you directly, a hosting provider (which one), or a platform? If a provider, when did they confirm their fixed build is deployed?

Ask for a dated answer from a named owner. A “we’re looking into it” is a finding, not an answer.

Hours 48 to 72: verify and track. Re-scan the assets that claimed a patch. Where the version string moved, close the item. Where it didn’t, go back with the evidence. Then keep measuring: patch velocity across your vendor base over the next two weeks tells you more about a vendor’s security operations than any questionnaire ever will.

For Panorays customers, the flagged-asset view, the vendor filter and the PHP2Shell attestation are already in the platform. If you are not a customer, the three questions above are yours to use.

For your own perimeter

The vendor work only makes sense if your own house is in order, so briefly:

  • Patch the runtime. PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net, or your distribution’s package. Patch what serves web requests, not just the CLI, and restart every worker. On 7.4, 8.0, or 8.1, apply the PHP-provided backport or your vendor’s package. On anything older, isolate or upgrade.
  • If you can’t patch today, reduce the blast radius, knowing it is not a fix. PHP lists memory_limit=-1 set at the pool level, a low post_max_size, session.upload_progress.enabled=0 applied before request parsing, and fatal_error_backtraces=0 on 8.5. Each closes a specific path; none closes all of them. Remove stored credentials and cloud roles from the box, drop its privileges, and make sure logs ship somewhere the box can’t delete them.
  • Keep your WAF on, and credit where due. Cloudflare deployed managed rules for all plans (including the Free version) about nine hours before disclosure, and built a new request-plus-response detection to catch successful exploitation. Akamai, Imperva, AWS, Google, and others shipped guidance too. Treat all of it as defense in depth around the patch, not instead of it.
  • Hunt. Wiz published the signals: unusual multipart requests followed by memory-limit errors or bursts of HTTP 500s, unexpectedly large or malformed PHPSESSID cookies in responses, and unexplained PHP worker churn. Application logs will show little, because this happens below the application. Look at the web server and FPM logs instead, going back to at least 20 October when the CVEs leaked.

What we’ll publish next

Today’s numbers are a baseline: 0% patched, by definition. The useful number is how fast that changes, and across which kinds of vendors. We will re-run the same measurement on the same population and publish the patch rate at day 7 (28 October) and day 30 (20 November), broken down by branch and by whether the runtime is self-managed or hosted. If you want to compare your own vendor base against the internet’s, those posts will give you the yardstick.

What worries  me more than PHP

The code behind PHP2Shell has been in the engine for over a decade. What changed this year is not the bug; it is that a small team with frontier AI models turned a flaw once considered impractical to exploit into working, portable exploits in days. Wiz said it plainly, and they are right: complexity is no longer a defense.

That means more of these to come. Decade-old bugs in foundational software, suddenly weaponised, in runtimes that your vendors inherited from their vendors. The organisations that handle it well will not be the ones with the best patch process for their own servers. They will be the ones that can answer “which of our third parties are exposed, and have they fixed it” in hours, with evidence, and then do it again next month for the next one.

If you’re working through this today, I hope the numbers and the playbook help. If you’ve seen something in your own vendor base that contradicts them, I’d like to hear it.

— Demi Ben-Ari, Co-Founder and Chief Strategy Officer, Panorays

Don’t wait for a vendor breach to discover your exposure. Get the visibility you need to act. Book a demo today.