PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619

If you run PHP anywhere in your environment, patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. Two critical flaws disclosed this week, CVE-2026-109618 and CVE-2026-109619 (nicknamed "PHP2Shell"), let an unauthenticated attacker run code on a server with nothing more than a crafted web request. Both carry a CVSS v4.0 score of 9.2, every earlier release is affected, and exploitation in the wild has been reported.

The patch is the easy part. The hard part is finding every copy of PHP you own, because PHP rarely shows up where you expect it. This post covers what the flaws are, how far exploitation has gone, and how to get to full coverage fast.

What happened

Details leaked before the planned embargo, so the PHP security team moved fast and shipped fixes within about a day of announcing them.

The two vulnerabilities

Both bugs live in PHP core, not in any framework or plugin, so they reach anything that runs PHP to serve web requests.

Affected server setups include PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk. No login is needed: the attacker only has to reach a PHP endpoint over HTTP.

Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every earlier release is affected. PHP has also published minimal source backports for 7.4, 8.0 and 8.1, but there are no official releases for those branches. Treat a backport as a stopgap and plan the upgrade.

Is it being exploited?

Yes, though reliable public exploits are still scarce. watchTowr reports exploitation in its honeypot network as of October 21, and Tenable relays Cloudflare's CTO saying Cloudflare is seeing early attacks. Other telemetry, such as Patchstack's, shows mostly probing so far. Neither CVE is in CISA's KEV catalog yet, and no public indicators of compromise have been released.

How hard the bug is to weaponize depends on the platform. VulnCheck reproduced both flaws and found:

• Code execution works on ARM64, and on x86 systems where address space layout randomization (ASLR) is turned off.
• Dozens of public proof-of-concepts exist, but very few work and none bypass ASLR on x86-64.
• Red Hat likewise rates RCE as hard in practice on default PHP-FPM deployments.

Don't read that as permission to wait. Exploits mature quickly once a patch diff is public, and fake PoC repositories for headline CVEs often carry malware, so treat any you find with caution.

Most at risk: internet-facing PHP applications, especially those running mod_php or on ARM64 hosts. It's also worth retro-hunting recent web server and PHP-FPM logs for unexplained worker crashes and unusual multipart requests.

Why finding PHP is harder than it looks

No one has a complete list of PHP-based applications, and anything custom-built won't be on any list. PHP hides in several places at once:

• OS packages on Linux (php, php-fpm, php8.x), which package managers and most inventory tools see.
• Homebrew and similar on macOS, outside the system's own package list.
• Bundled copies on Windows. PHP on Windows usually arrives as a zip extracted to a folder or inside a stack like XAMPP, WampServer, Laragon or a vendor product. It often never registers as an installed application at all.
• Applications that ship their own PHP, where the fix depends on the application vendor rather than the OS.
• Containers, where the version is baked into the image tag.

PHP is often more widespread than teams expect, and it doesn’t only run on servers. Developer tools, local web stacks and bundled applications put it on workstations too, often without registering as an installed application.

The reliable answer is to look at the binaries themselves. In testing, PHP builds from version 5 through 8 all embed their version string (X-Powered-By: PHP/x.y.z), so you can read the exact version straight from the file without running it.

How Tanium helps

Tanium itself is not affected. Tanium does not use PHP, so there is no impact to Tanium software or Tanium Cloud services.

Tanium Guardian content for PHP2Shell shows where PHP is installed and running so you can prioritize patching. It combines:

• The existing Installed Applications and Homebrew Applications sensors, which find PHP installed through package managers on macOS and Linux.
• A new Windows PHP installations sensor that finds PHP on Windows systems where Installed Applications can’t see it.
• Detection of running PHP processes by command line, so you can see which copies are actually serving traffic.

The new sensor uses Tanium Index to locate PHP binaries without a disk scan, then reads the version straight from each binary without executing it. That keeps the endpoint impact light, comparable to an SBOM inventory, and it depends on a healthy Index deployment.

Know what's exposed to the internet. More than 13 million internet-facing assets run PHP versions that may be affected, according to Censys Internet Intelligence. Tanium External Attack Surface Management (EASM) discovers the internet-facing assets tied to your organization and identifies the PHP services, versions and web properties among them, with these CVEs surfaced through its coverage of exploitable and weaponized vulnerabilities. Tanium Attack Path Mapping then shows which of those exposed assets share an exposure point with a cloud instance, role or privileged identity: the places where one exploited PHP server becomes a route deeper into your environment.

Already using Tanium SBOM? Inventorying PHP versions there is a sound early step. It shows which applications carry a vulnerable PHP and need a vendor update.

What to do now

Work through these in order; the first three matter most today.

1. Find every PHP install, including Windows copies that never registered as applications. Record the exact version of each.
2. Rank by exposure. Internet-facing servers, mod_php setups and ARM64 hosts come first.
3. Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 through your OS vendor, a php.net build or your application vendor. Restart PHP-FPM and web server workers so the new binary is loaded.
4. If you can't patch yet, isolate internet-facing PHP apps where you can, as CERT-EU advises, and put WAF or IDS rules in front of them (Cloudflare and VulnCheck have both shipped rules for the known vectors).
5. Apply the partial setting with care. session.upload_progress.enabled=0 blocks one demonstrated path for CVE-2026-109619 only and does nothing for CVE-2026-109618. It must be set in php.ini, an FPM pool or server config, followed by a worker restart; ini_set() and .user.ini won't apply it.
6. Hunt. Review recent web server and PHP-FPM logs for worker crashes and malformed multipart uploads.
7. Plan off end-of-life PHP. Anything on 8.1 or older has no official fixed release.

Where fixed packages stand (as of Oct 21, 16:30 UTC)

Distro packages are still rolling out, so check your vendor before assuming a fix is available.

The Remi repository won't ship updates today, so PHP advises switching to distro packages or building from source if you depend on it.