PHP2Shell: Find the PHP You Did Not Install

ProIT NW, a senior-led Microsoft consultancy in Seattle serving the regulated mid-market, is flagging this for teams that would say they do not run PHP. On October 21, 2026, the PHP project shipped fixes for two critical vulnerabilities, nicknamed PHP2Shell, that can allow unauthenticated remote code execution. You probably don't run websites. You may still run PHP, inside products you bought for other reasons.

What the PHP project announced

The php.net advisory says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 "fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately." The CVEs are CVE-2026-109618 ("RCE via OOM corruption") and CVE-2026-109619 ("RCE via stale global state"). Both rate Critical, CVSS v4.0 base 9.2.

The advisory's scope is broad: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." The risk is highest for mod_php, "with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." And: "PHP 8.1 and older no longer receive updates from the PHP project."

Step one: find the PHP you did not install

CISA's alert makes the problem plain: "PHP is often a component of other software and prevalence may not be directly observable." The NSA's October 21 advisory puts the same point as an instruction: "All users should immediately conduct an inventory, where feasible, of hardware/software services reliant on now-vulnerable PHP versions." It also lists "Replacing end-of-life PHP services which will not be compatible with patching" among the additional steps to consider. For a regulated mid-market organization, that usually means:

• Network and security appliances. Firewall and firewall-management web interfaces, and network access control (NAC) servers.
• Management consoles. Antivirus and endpoint management consoles, backup consoles, and NAS web interfaces.
• Windows servers. Legacy line-of-business and intranet applications running PHP under IIS FastCGI, forgotten XAMPP, WampServer or Laragon installs, and vendor-bundled php-cgi.exe.

You can search Windows servers for php.exe and php-cgi.exe yourself. For appliances you can't look inside, the evidence is the vendor's statement. The Dutch NCSC maintains a community tracker of vendor statuses at github.com/NCSC-NL/php2shell. As of October 23 it listed HPE Networking ClearPass Policy Manager as vulnerable (6.14.0 and below, and 6.11.15 and below; 6.14.1 and 6.11.16 are partially mitigated and still affected), and Cisco Expressway Select Series as vulnerable. Statuses change, so check the tracker itself rather than this paragraph.

Step two: you can't patch what the vendor hasn't shipped

On an appliance, the PHP version is the vendor's decision. Palo Alto Networks is a useful example, because its advisory states the case precisely. PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 are affected, on "PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series)." "No special configuration is required to be affected by this issue." Hotfix releases are listed with ETAs between October 26 and 30, 2026, so as of October 24 none had shipped. Palo Alto says it is "not aware of any malicious exploitation of this issue against our products" rates the issue HIGH for its products, and lists its cloud products such as Cloud NGFW and Prisma Access as not affected.

The same advisory carries the control that applies far beyond one vendor: "The risk is highest on PAN-OS when you allow access to the management interface from external IP addresses on the internet."

CISA's guidance is stricter: "Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." CISA also advises you to "Monitor for suspicious activity, including PHP worker processes launching shells or downloading tools," and its October 23 revision added a SIGMA detection rule. On an unsupported version, php.net's advice is to contact your vendor, as "some distributions and LTS vendors provide backported fixes" or upgrade. The PHP security team also provided minimal source-only backports for PHP 7.4, 8.0 and 8.1, which are useful only if you build PHP from source.

What about Windows and IIS?

Patch Windows PHP too: php.net says "Windows source and binaries are on the same page." Be honest about the evidence, though. The advisories report a confirmed exploit against Apache mod_php, and one path for CVE-2026-109619 validated against PHP-FPM with a suitable application (GHSA-6wmf-4rv5-p3rp says "validated against mod_php and FPM," and that the FPM path "depends on a suitable application operation"). For CVE-2026-109618, GHSA-w8hw-w9fx-j79w says "no complete FPM exploit has been demonstrated for this SAPI." They do not report an exploit through IIS FastCGI, but php-cgi, which IIS FastCGI runs, is explicitly in scope. Patch it. The evidence should shape your order of work, not your decision.

The second deadline: PHP 8.2 on December 31, 2026

Per php.net's supported versions page, PHP 8.2 has security support until December 31, 2026. 8.3 runs until December 31, 2027, 8.4 until December 31, 2028 and 8.5 until December 31, 2029. If your inventory turns up 8.2, 8.1 or older, the application is on borrowed time. Moving a legacy Windows line-of-business app off an end-of-support runtime is a project, so start it now.

One more item, so you don't overreact to it: on October 23, php.net published an informational advisory about CVE-2026-115560, "an unlikely RCE vector" that "can only occur under an unusual combination of configuration and application code". It will be fixed in the next regular release. In the meantime php.net suggests keeping session.upload_progress.enabled=0.

What to do this week

1. Ask the vendor of every appliance and console for its PHP2Shell statement, and check the NCSC tracker.
2. Search Windows servers for php.exe and php-cgi.exe, including old XAMPP, WampServer and Laragon folders.
3. Restrict management interfaces to a jump host. Remove any exposure to the internet.
4. Patch to the fixed PHP builds (8.5.12, 8.4.27, 8.3.36 or 8.2.35) or to the vendor hotfix when it ships.
5. Plan off PHP 8.2 and anything older before December 31, 2026.
6. Keep session.upload_progress.enabled=0 where you control it, pending the next PHP release.
7. Record what you found, who you asked and when. An auditor will ask how you knew.

The 30-second version

Two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) allow unauthenticated remote code execution, with fixes shipped October 21, 2026. No cited source reports successful exploitation: CISA had not observed it as of publication and neither CVE is in the KEV catalog as of version 2026.10.23. Patch anyway. Your exposure is likely inside products you didn't install as PHP: firewalls, NAC, consoles and legacy Windows apps. Inventory first, press vendors for statements, close off management interfaces, and move off PHP 8.2 before December 31. If you'd like a senior engineer to help build that inventory, the project intake form takes about three minutes.

Sources and further reading

• php.net — 2026 news archive, security advisories of October 21 and 23, 2026
• CISA — Critical Vulnerabilities in PHP Require Immediate Patching (Oct 21, 2026; revised Oct 23)
• NSA — Critical Patches Recommended for PHP Vulnerabilities (Oct 21, 2026)
• Palo Alto Networks — CVE-2026-109618 advisory
• NCSC-NL — php2shell community vendor tracker
• php.net — Supported versions
• CISA KEV: patch, then assume compromise

Pro IT NW handles identity, security and compliance work for the regulated mid-market in Seattle and the Pacific Northwest. Vendor-neutral, labor-only. This alert relays the PHP project's, CISA's and Palo Alto Networks' published guidance; confirm current status at those sources before you act, as it may be revised.