From Leak to Root: The Timeline So Far

Every few days since the leak has added a new problem. Patching on day one solved the first one.

What Has Changed Since the Patch

Three things are different today than on October 21.

Until October 24, public reporting described scanning, fingerprinting, and exploits that did not work. Then a Perplexity researcher’s honeypots recorded working code execution against Apache mod_php on PHP 8.4.26, and CISA added both CVEs to KEV two days later.

Two caveats apply. That first honeypot used a deliberately favorable single-worker setup, and while GreyNoise has since recorded successful exploitation of its own vulnerable sensors, reliability against real-world builds is still unmeasured. Palo Alto’s Unit 42 also retracted an early report tying a European government breach to PHP2Shell.

The most serious, confirmed attack did not hit a website. Dream reported a suspected China-nexus actor that decrypted Palo Alto Networks’ PAN-OS firmware and built memory profiles for nine software versions. The PHP2Shell exploit landed as a low-privilege web user confined by SELinux, so the attacker chained in Fragnesia (CVE-2026-46300), a Linux kernel flaw disclosed in May, to reach root.

The result was root on 25 servers across the U.S., Japan, Taiwan, and South Korea, followed by attacks on Active Directory with confirmed credential extraction and directory enumeration. Palo Alto Networks confirmed exploitation of internet-exposed PAN-OS management interfaces, and Unit 42 says only about 0.02% of its installed base had those interfaces exposed and was affected.

CISA warns that PHP is often a hidden component inside other products, and the vendor list proves it. Citrix, F5, Ivanti, QNAP, Synology, Siemens, and Veeam are among dozens of vendors that have published PHP2Shell advisories or impact statements, and the Dutch NCSC’s tracking list had grown to 948 products by November 4.

Censys counted 32.5 million internet-facing PHP services still reporting vulnerable versions in late October, 10.3 million of them in the U.S. Patching surged on October 22 and 23, at roughly 4.3 million services a day, then fell off sharply. Another 60 million services hide their version entirely. By November 5, Censys still flagged about 28.8 million, a drop smaller than a single day of patching at the October peak.

Those are service counts, not unique servers, and distributions often backport fixes without changing the version number. Still, a large share of the remaining exposure runs end-of-life PHP (8.1 and older), which gets no official fixed release. In early Censys data, the single most common version in the wild was PHP 7.4.33, unsupported since 2022.

The Vulnerabilities at a Glance

Both PHP2Shell flaws sit in the PHP engine itself, so updating WordPress, Drupal, or any other application does nothing for them. Only a fixed PHP build closes them.

Per the PHP Foundation, one flaw corrupts memory when a request hits PHP’s memory limit at the wrong moment, and the other lets a request reuse freed memory left over from a previous one.

Affected: PHP 8.2 through 8.5 before the October 21 releases, and every end-of-life branch (8.1 and older), which gets no official release. PHP published minimal source-only backports for 7.4, 8.0, and 8.1 for organizations that build PHP themselves, and some Linux distributions and extended-support vendors ship patched packages. CISA says this covers all PHP installations serving web requests, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Risk is highest on mod_php, where an unauthenticated request can trigger the bug before any application code runs, but PHP also confirmed code execution on PHP-FPM through application code paths, so do not treat FPM as safe.

What To Do Now

If you patched on October 21, start at step 1 anyway. Most of the open risk is in what that patch did not touch.

1. Confirm the fix is running, not just installed.

   Check the version each web-facing PHP runtime actually serves. php -v only reports the command-line binary, which can differ from PHP-FPM or mod_php. Then restart PHP-FPM, Apache, and LiteSpeed, because a package update replaces files on disk, not code already loaded in running workers.

   Where a Linux distribution backports the fix without changing the version string, confirm against the distribution’s advisory. Banner-based external scans cannot settle this. You have to check the servers.

2. Find the PHP you did not know you had.

   CISA’s guidance is to inventory every system running any version of PHP, including products that embed it. Work through firewalls, VPN and identity gateways, NAS devices, backup consoles, phone systems, and OT and building management systems. Vulnerability management keeps that inventory current, and external penetration testing finds the internet-facing PHP that never made the list.

   End-of-life PHP gets no official fix, and CISA’s guidance is to take those systems offline until they can be patched or updated. If one truly cannot go offline, PHP’s source backports or an extended-support vendor’s package can buy time, alongside WAF or IPS rules with PHP2Shell signatures. Either way, put the migration on a dated plan.

3. Take management interfaces off the internet.

   The confirmed root-level compromises came through internet-exposed firewall management. On PAN-OS, apply the fixed builds, restrict management access to trusted internal IP addresses, and remove management profiles from internet-facing interfaces. Then run the same review on every appliance admin page you own. A configuration security audit is the fastest way to find the ones that slipped.

4. Close the path to root: patch and reboot kernels.

   Fragnesia is what turned a low-privilege foothold into root. Linux distributions have shipped kernel fixes, but a kernel update does nothing until the host reboots. Reboot internet-facing PHP hosts first and confirm with uname -r that the running kernel is the patched one. Where a reboot has to wait, distributions recommend blocking the esp4, esp6, and rxrpc kernel modules on hosts that do not use IPsec.

5. Turn off session upload progress and leave it off.

   Set session.upload_progress.enabled = 0 in php.ini, then lock it with php_admin_flag in PHP-FPM pool and Apache configs so a per-directory .user.ini or .htaccess file cannot switch it back on. Restart every worker afterward. This blocks the unpatched CVE-2026-115560 and was already a partial mitigation for CVE-2026-109619. Few applications use the feature, but it does not replace updating PHP.

6. Hunt back to October 17.

   Amazon saw exploitation attempts four days before disclosure, so any internet-facing PHP host left unpatched after October 17 deserves a compromise review. Look for shells or other unexpected child processes spawned by PHP workers (php-fpm, httpd, apache2), new PHP files in web roots, unexpected files in the PHP session directory, and memory-exhaustion errors or worker crashes in logs. CISA has published a SIGMA rule for exploitation attempts.

   If an exposed firewall or management server was involved, extend the review to Active Directory, because that is where the confirmed attacker went next. If you find evidence, or cannot rule it out, treat it as an incident, not a ticket. That is a compromise assessment, and it is what nGuard’s incident response team does.

The Problem Underneath

PHP2Shell was not a surprise to everyone. The PHP Foundation says work following its 2024 security audit first surfaced the memory flaw behind CVE-2026-109618, and that the fix then stalled for months, a delay it calls a structural failure. Reports from Calif, OpenAI, and Wiz, starting in August, showed that the flaw led to remote code execution.

When we covered Mythos in June, we said discovery is now cheap and remediation is the bottleneck. As of mid-October, PHP’s small security team had published 15 CVEs since July 1 and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible. A third PHP2Shell-era flaw has already surfaced, much as Log4Shell’s first fix in 2021 was followed by three more CVEs within weeks, and PHP’s next regular releases are due November 19.

The calendar adds pressure. PHP 8.2 reaches end of life on December 31, so a server patched to 8.2.35 today will be unsupported in under two months. Unsupported software is also a compliance finding: PCI DSS, for example, expects critical patches within a month of release, which the PHP project no longer issues for end-of-life branches.