PHP2Shell: Nearly 70% of Websites Rely on PHP. Do You Know Which of Yours Are Exposed?

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, widely referred to as PHP2Shell. The PHP security advisory says the two flaws "can allow unauthenticated remote code execution": under the conditions described in the advisories, an attacker who can reach the site over the network could run their own code on the server without logging in. PHP rates both Critical: 9.2 out of 10 on the CVSS v4.0 severity scale. It asks all PHP users to update immediately.

On a supported branch, the fix is a version update. Applying it is only possible on servers you know about, so the harder step is listing every website, subdomain and old service of your company that still runs PHP.

What we know and what remains unconfirmed

What we know

• Two identifiers: CVE-2026-109618 (remote code execution through corrupted state after an out-of-memory condition) and CVE-2026-109619 (remote code execution through internal state left over from an earlier request handled by the same worker process).
• PHP rates both Critical, 9.2 on CVSS v4.0. PHP's advisories for CVE-2026-109618 and CVE-2026-109619 describe the attack as reachable over the network with no account and no user interaction, but with high attack complexity and requirements that depend on how PHP is deployed.
• Fixed versions, released on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• PHP names as at risk "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed". It considers the risk highest for mod_php, where a working exploit has been demonstrated.
• PHP 8.1 and older get no new releases from the PHP project. Given the severity, the PHP security team published minimal source patches for PHP 7.4, 8.0 and 8.1 for people who build PHP themselves. Linux distributions and long-term support vendors received the patches in advance and may ship their own fixed packages.
• PHP says only an update is a complete solution. The temporary settings listed in the advisory reduce specific attack paths but do not make an installation safe.

What remains unconfirmed

• How far back the flaws go. Early reports, repeated by CERT-EU before the release, said the flaws could affect every version from PHP 5 onward. The official advisories identify fixes for the four supported branches, but do not establish the earliest affected release.
• How reliably they can be exploited on a given server. The advisories confirm impact on Apache with mod_php, and for CVE-2026-109619 on PHP-FPM under specific application and deployment conditions. Other setups are rated susceptible from source analysis, and reliability depends on the PHP build, extensions and the web server in front of it.
• Scale. Tenable cites two different counts: an estimate of over 1.3 million internet-facing hosts that may be vulnerable, and a Shodan search finding over 1.9 million hosts running PHP. Neither shows whether those systems have the fixes or meet the exploitation conditions.
• Attacks in the wild. On 21 October Cloudflare's CTO said the company was seeing early attacks, as reported by Tenable; that does not show how many systems were compromised. Neither CVE was in the CISA Known Exploited Vulnerabilities catalog when we checked on 21 October.
• Exploit code. Code claiming to exploit PHP2Shell is circulating. Unverified exploit code can itself contain malware, so do not run it to test your own servers.

Why updating plugins does not fix it

These flaws are in PHP itself, the language runtime underneath the application. WordPress, Drupal, Magento and many other systems run on PHP, but updating the CMS, a plugin or a theme does not, by itself, update the PHP software on the server. The fix has to come from a new PHP version or a fixed package from your distribution or hosting provider.

Running PHP does not by itself prove that these flaws can be exploited on a site: the official conditions above depend on the version, the way PHP is connected to the web server and its configuration. But the question "are we affected?" can only be answered for servers you know about.

Web application firewall rules are a stopgap. According to Sansec, Cloudflare deployed temporary rules against known exploit attempts. They cover traffic routed through Cloudflare; requests sent directly to the server bypass them.

Which PHP sites does your company run?

W3Techs counts PHP on 69.3% of the websites whose server-side language it can identify (W3Techs, 21 October 2026). A significant share of them still runs outdated branches that the PHP project no longer maintains: W3Techs puts PHP 7 at 27.0% and PHP 5 at 7.7% of PHP sites. That is a measure of versions in use, not of how many sites are vulnerable, and some distributions and commercial vendors backport fixes to older versions.

When you list them, include the sites that sit outside the main website's hosting and maintenance arrangements, for example:

• a test or staging copy of a site left online after a project ended;
• an old campaign landing page on a forgotten subdomain;
• a hosting control panel or webmail with a PHP front end;
• a site a contractor built and still hosts on their own account;
• a subsidiary's or regional office's website managed outside central IT.

You can't patch what you don't know exists. A server missing from the list can miss the update. Record who patched each site and how they confirmed it.

Seeing PHP from outside is also not the same as confirming the vulnerability. A server sometimes reveals PHP and its version, for example in the X-Powered-By header, but that header can be disabled, and a version number does not show whether a distribution has backported the fixes into it. A site that shows no version may still run PHP. To confirm, ask the administrator or hosting provider for the running PHP version, the package revision and the security advisory that covers it.

Five checks to start now

1. Inventory your public websites, subdomains and related services, including those run by contractors, subsidiaries and hosting providers.
2. Identify the technologies and versions behind each of them where possible, and record who is responsible for each one.
3. Find outdated and unsupported PHP installations, including PHP 8.1 and older.
4. Check the official vulnerability information from PHP and your distribution or hosting provider. Update affected systems, or restrict their exposure until you can. Ask the administrator or provider to record the PHP version and package revision serving each site, with the advisory that covers both fixes, and to confirm that PHP processes were restarted afterwards.
5. Set up regular tracking of changes to your external attack surface, so new sites and services join the list when they appear.

Why a one-off check is not enough

New critical vulnerabilities are published regularly, and the list of your internet-facing systems changes whenever a site is launched, moved or retired. An annual check can miss vulnerabilities disclosed between assessments. Sansec records Cloudflare's report of early PHP2Shell attacks at 07:43 UTC on 21 October, before the scheduled release.

We have seen the same pattern before: in the PAN-OS chain of three CVEs, the deciding factor was a management interface reachable from outside; after CVE-2023-20198 in Cisco IOS XE, the first question was again which devices exposed their web interface. In each case the answer starts with an up-to-date list of what is exposed.

Want to know which websites and internet-facing systems show up for your company? Use Check My Company below. It is a free request to the IntruForce team. We reply by email to agree which assets to check and confirm you may authorize the check. Nothing is checked before that. Once agreed, the automatic check usually takes a few hours.