php2shell Response: How IONIX Customers Had a Patch List Before the Patch Existed
Six days after PHP shipped the php2shell fix, 94% of measurable internet-facing PHP hosts are still unpatched, CISA has added both CVEs to its Known Exploited Vulnerabilities catalog, and honeypots are recording working shells. IONIX customers spent those six days working a prioritized list instead of building one. This post walks through how that list came to exist, how it narrowed, and the one thing IONIX decided it could not claim.
Before the patch existed, the list did
Details of CVE-2026-109618 and CVE-2026-109619 leaked on October 20. PHP announced an emergency release for 14:00 UTC the next day. The attacker’s clock started on the leak. The defender’s clock could not start until somebody produced a list of PHP hosts to patch.
On the morning of October 21, before PHP’s fix was out, IONIX published a php2shell entry in the Live Exposure Defense section of the portal for every customer, with their potentially affected assets already mapped. No new scan was needed. IONIX fingerprints the technology on every internet-facing asset as part of continuous discovery, so the PHP servers were already tagged from the “Server” and “X-Powered-By” response headers IONIX collects on every scan. The same morning, IONIX published a rolling advisory with interim configuration mitigations and, by the afternoon, tested WAF rule guidance for Cloudflare and Akamai.
That first list was wide on purpose. It included every asset where IONIX detected PHP, whatever version it reported. PHP had not yet published affected versions, and across the internet around four in five PHP servers hide their version anyway. A wide list on day zero that a team can start working beats a precise list on day three.
Customers with many affected assets had one more thing: the “What should I fix first” button in the Live Exposure Defense entry, which turns the list into a prioritized remediation plan ranked by exposure and asset importance.
Within 48 hours: from “runs PHP” to “runs a vulnerable version or has the vulnerable feature switched on”
PHP published fixed versions on October 21. IONIX Research then ran two checks across every customer’s external attack surface.
The first is a version check: read the PHP version the host advertises and compare it to the fixed releases, 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The second is a feature check, built for the hosts that strip their version header. CVE-2026-109619 is reached through PHP’s session upload progress feature, which is on by default. IONIX sends a few small, benign form posts with no file attached, some carrying the upload progress field, and watches whether the server issues a new session cookie only for those posts. A new cookie means the feature is reachable. The check never touches the vulnerable code, so it cannot crash the server.
By October 23, every customer had three php2shell lists in the portal, in priority order:
- CVE-2026-109618: assets that advertise a vulnerable PHP version. Highest confidence. Patch first.
- CVE-2026-109619: assets that advertise a vulnerable version, or where the upload progress feature is reachable. This list catches PHP that hides its version. Assets advertising a patched version are excluded.
- php2shell tracker: every asset with PHP in its response headers, for the long tail.
Live Exposure Defense customers received each update as a push notification and a live portal refresh. Customers on the base platform saw the updated lists after their next completed scan, and could filter the Discovery view for PHP assets in the meantime.
The thing IONIX would not claim, and said so
IONIX’s standard response to a critical CVE closes the loop with a safe exploitability test: a non-destructive request that tells a vulnerable host from a patched one, so the team patches confirmed-exploitable assets first. For php2shell, IONIX stated in its public advisory that no such test exists.
Both bugs are memory-corruption flaws. The only way to prove a host is exploitable is to trigger the flaw, and that crashes the PHP worker. IONIX Research’s published position is that it cannot safely produce a “confirmed exploitable” list for these CVEs, there is no current ETA for one, and customers should treat every asset on the three lists as one to patch or mitigate.
That decision cost IONIX a cleaner headline. A vendor that labeled hosts “not exploitable” on the strength of a version string would have been wrong about every server behind a distribution backport that patches without changing the version, every server behind a load balancer that rewrites headers, and every server on an end-of-life branch with no official fixed version to compare against. The PHP core developers said the equivalent about configuration workarounds: “ini settings won’t save you.”
Where the WAF story got uncomfortable
IONIX’s rolling advisory was blunt about the edge: no WAF signature can be counted on to block these bugs. CDN and cloud WAFs inspect only the first part of a request body, so a padded payload gets past them. The size-cap rule misses an out-of-memory variant that uses many small part headers. The rules do not cover the other trigger paths for CVE-2026-109619. Traffic that reaches the origin without passing through the CDN is unprotected.
Those caveats matched what IONIX found across hundreds of organizations in its State of the WAF report, published the same month: 47% of live internet-facing web applications have no blocking firewall at all, and 29% of WAF-protected applications with a testable origin answer requests sent straight to the origin. For a vulnerability where the WAF vendors themselves called their rules a stopgap, the question for every security team was which PHP hosts had no stopgap at all. Those hosts went to the top of the patch order.
Six days later
| Milestone | When |
|---|---|
| CVE identifiers leak | October 20 |
| IONIX publishes php2shell entry with PHP assets mapped for every customer, plus interim mitigations | October 21, morning UTC, before the fix |
| PHP ships fixed versions | October 21 |
| IONIX publishes tested Cloudflare and Akamai WAF rule guidance | October 21 |
| Version-narrowed and feature-checked lists live for every customer | By October 23 |
| Third PHP CVE (CVE-2026-115560) reported, tracked in the same entry | October 23 |
| CISA adds both CVEs to the Known Exploited Vulnerabilities catalog | October 26 |
The industry number at day five, from OX Security’s Shodan tracking, is 93.6% of measurable in-range hosts still unpatched. The hosting-panel segment is at 100% unpatched. Magento is at 100%. WordPress is at 94%.
IONIX customers are not at zero either. Patching hundreds of PHP hosts across a group’s subsidiaries takes time, and some of those hosts run PHP 5 and need a migration rather than a patch. The difference is that those customers have known since the morning of October 21 which hosts, which of them advertise a vulnerable version, which have the vulnerable feature reachable, and which sit with no WAF in front of them. The work is a queue, not a hunt.
Get the same list for your own attack surface
IONIX is still offering a free php2shell assessment. Give us your company name. Within 24 hours you get your external attack surface mapped across subsidiaries, acquisitions, and digital supply chain, every internet-facing PHP asset identified, the version and feature checks above applied, and a prioritized patch order.
Request your free php2shell assessment
php2shell response FAQ
IONIX published a php2shell entry with potentially affected PHP assets mapped for every customer on the morning of October 21, 2026, before PHP released the fix. Version-narrowed and feature-checked lists were live for all customers by October 23.
No. CVE-2026-109618 and CVE-2026-109619 are memory-corruption bugs. Confirming exploitability means triggering the flaw, which crashes the PHP worker. IONIX’s published position is that it cannot safely produce a confirmed-exploitable list for these CVEs and that customers should patch or mitigate every potentially affected asset.
IONIX sends a few small, benign form posts with no file attached, some carrying PHP’s session upload progress field, and checks whether the server issues a new session cookie only for those posts. A new cookie means the feature that CVE-2026-109619 abuses is reachable. The check never reaches the vulnerable code.
A CVE-2026-109618 list of assets advertising a vulnerable PHP version, a CVE-2026-109619 list of assets advertising a vulnerable version or with the upload progress feature reachable, and a php2shell tracker of every asset with PHP in its response headers. Patch in that order.