Securify

Two critical remote code execution vulnerabilities in PHP’s core — dubbed “php2shell” by the security community — have triggered an emergency patching scramble across the internet. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws carry a CVSS v4.0 score of 9.2 and allow unauthenticated attackers to execute arbitrary code on any web server running PHP. With PHP powering roughly 69 percent of websites globally, the exposure is staggering: Palo Alto Networks’ Cortex Xpanse identified over 22.6 million potentially vulnerable instances on the internet.

What Happened

The drama began on the morning of October 20 when an anonymous post on Hacker News claimed that two critical PHP flaws, rated CVSS 10.0, were headed for public disclosure on October 22. The post was quickly taken down, but screenshots had already spread across social media and security Slack channels.

Hours later, watchTowr — the offensive security research firm — confirmed on X (formerly Twitter) that the leak was real and that the vulnerabilities were under an active embargo. The PHP security team responded the same evening by publishing an advance notice and accelerating the release timeline, scheduling an out-of-cycle emergency release for October 21 at 14:00 UTC — a full day ahead of the original embargo.

On the morning of October 21, PHP released patched versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The patches landed while proof-of-concept exploit code was reportedly already circulating privately, and a short exploitation demonstration video had been posted and then removed online.

Inside the Vulnerabilities

Both vulnerabilities live deep in PHP’s error-handling internals, specifically in how the interpreter uses longjmp() — a low-level C function for non-local control flow jumps — during fatal error conditions. According to Palo Alto Networks’ Unit 42:

CVE-2026-109618 involves PHP’s out-of-memory error handling. When PHP runs out of memory while setting up request data, it uses longjmp() to bail out. But the abrupt jump leaves request memory in a partially initialized state. During the subsequent cleanup phase, PHP treats that partial data as valid — creating a reliable path to code execution. PHP’s own security team confirmed they achieved complete RCE over HTTP against mod_php using default input and memory limits, meaning no unusual server configuration is required to trigger the flaw.

CVE-2026-109619 is a use-after-free condition. When PHP encounters a fatal error and takes the longjmp() path, global memory pointers are left dangling — still pointing to freed memory regions from the previous request. If the same PHP worker process handles a subsequent request before those pointers are re-initialized, an attacker can read or branch on the stale data, leading to heap use-after-free, memory disclosure, and ultimately arbitrary code execution with the web worker’s privileges.

Crucially, both attacks are unauthenticated. An attacker does not need credentials or any access to application code — the exploit triggers in PHP’s core request handling, before any application-level logic runs.

Who Is Affected

Every PHP installation serving web requests is potentially at risk. This includes the most common deployment configurations: PHP-FPM behind Nginx, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

Early reports indicated the flaws may affect PHP versions as far back as PHP 5, though PHP has not officially confirmed the full scope. What is certain is that only the currently supported branches — 8.2, 8.3, 8.4, and 8.5 — have received vendor patches. PHP 8.1 and all older branches (the entire 7.x and 5.x lines) are end-of-life and will not receive official fixes, though PHP has published minimal source backports for 7.4, 8.0, and 8.1 as a stopgap.

The scale of exposure is sobering. Shodan scans as of October 20 showed approximately 884,000 internet-facing hosts reporting PHP 8.1 or older in their HTTP banners — roughly 59 percent of the 1.5 million hosts advertising any PHP version. Another 740,000 hosts reported running PHP without exposing a version number. Unit 42’s broader scan counted over 22.6 million exposed instances, encompassing servers that may not advertise PHP in their headers but run it behind reverse proxies or load balancers.

Exploitation Status

As of October 21, neither Huntress nor watchTowr had observed active exploitation in their monitored environments. The flaws are not yet in CISA’s Known Exploited Vulnerabilities catalog. However, the security community is treating mass exploitation as a matter of when, not if. For context, when a previous critical PHP flaw (CVE-2024-4577) was disclosed, Akamai observed exploit attempts within 24 hours. At least one European government reportedly took its website offline as a precautionary measure before the patches dropped.

Palo Alto Networks confirmed that proof-of-concept exploits exist, and the brief appearance and removal of an exploitation video suggests working exploit code is already in capable hands.

What You Should Do Right Now

1. Inventory everything. PHP hides in places you might not expect: vendor appliances, Windows software bundles, control panels like cPanel and Plesk, and CMS platforms including WordPress, Drupal, Joomla, and Magento. Find every instance.

2. Patch immediately. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Prioritize internet-facing servers. Check your Linux distribution or hosting provider for backported packages — they may land on a slightly different timeline.

3. Address end-of-life installations. If you are running PHP 8.1 or older, your options are: upgrade to a supported branch, take the system offline, or place it behind a VPN or web application firewall. CERT-EU has advised organizations to “consider isolating internet-facing applications from public networks until a fix is available.”

4. Monitor for post-exploitation. Watch for PHP worker processes (php-fpm, php-cgi, httpd, or apache2) spawning suspicious child processes: shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl), download tools (curl, wget, nc, certutil.exe), or reconnaissance commands (whoami, id, uname -a). For Linux servers without EDR, Florian Roth’s open-source process-watcher can log these child processes in observe mode.

5. If you suspect compromise, isolate the server immediately. Preserve web server and PHP-FPM logs. Look for web shells, newly created files in web roots, new cron jobs, scheduled tasks, and unauthorized user accounts.

What to Watch Next

The next 48 to 72 hours are critical. History shows that mass scanning and exploitation of PHP vulnerabilities follows public disclosure within hours, not days. The sheer ubiquity of PHP — and the enormous installed base of end-of-life versions that will never receive official patches — makes this a slow-burning crisis that will likely fuel breaches for months.

Expect CISA to add both CVEs to the KEV catalog shortly, which would impose a binding patch deadline on U.S. federal agencies. Organizations using next-generation firewalls should check for virtual patching signatures — Palo Alto Networks released Threat Prevention signature 543004 on October 20 for customers with Advanced Threat Prevention Plus.

The php2shell saga also raises uncomfortable questions about vulnerability embargo processes. A single leaked Hacker News post compressed the disclosure timeline by a full day, and the security community’s real-time reaction on social media effectively broadcast the existence of these flaws to both defenders and attackers simultaneously. Whether that accelerated timeline helped or hurt overall security is a debate that will play out in the weeks ahead.