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

Our view

We would not start by debating how severe PHP2Shell is. We would start with the list of sites and services, including those a contractor or a finished project left behind.

IntruForce

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.
• CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 26 October 2026, the list of flaws it knows are used in attacks. The entries do not name affected organizations.
• On 23 October PHP added a recommendation: until the next regular bugfix release, set session.upload_progress.enabled=0 in php.ini or the server configuration, not in application code. It addresses a separate vulnerability, CVE-2026-115560, which the 21 October releases do not fix. PHP says it needs an unusual combination of session settings; ask your administrator to check the exact conditions in PHP's advisory.
• Installing updated packages does not fix PHP processes that are already running. Restart the PHP workers that serve web requests after the update and after applying these settings, and confirm they all run the fixed build.

What remains unconfirmed

• How far back the flaws go. The official advisories list fixed versions only for the four supported branches. Researchers at Calif report that the earliest affected code they found dates to PHP 5.4.0; the PHP project has not confirmed a starting version.
• 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. PHP's analysis of its source code indicates that other setups may also be affected. Tenable reports that Trail of Bits demonstrated working exploits against unpatched PHP 8.2 to 8.5 on 26 October; on a real server, the result still depends on the PHP build, its 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.
• How many attacks succeed. Amazon's threat intelligence team reported an exploitation attempt on 17 October, four days before the fix, and now describes broad exploitation attempts; it says it is unclear whether they would succeed against real systems. watchTowr reports PHP2Shell activity against its honeypots on 21 October. On 24 October Adel Karimi documented commands run on three PHP 8.4.26 honeypots using Apache with mod_php and a single worker; the evidence matched CVE-2026-109618, not CVE-2026-109619. These reports do not show how many organizations were compromised.
• Exploit code. Code claiming to exploit PHP2Shell is circulating, and the attacks Karimi recorded closely match one public proof-of-concept family. 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. For products that ship their own copy of PHP, such as appliances, security tools and hosting control panels, check the vendor's advisory for a supported update or mitigation. 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. If a server may have been attacked before it was updated, ask them to keep its logs and review activity from 17 October onward.
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. With PHP2Shell, Amazon reported an exploitation attempt four days before the fix was published.

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.