PHP2Shell: What scanning and patching data reveal

Threat actors are still hunting for reliable exploits for PHP2Shell in the dark web

Exploitation requires target system knowledge, which increases difficulty for threat actors

Pre-PHP2Shell we’ve observed ~30M PHP hosts, of which 18.4M advertised a vulnerable version

Post-PHP2Shell we’ve observed over 33% of systems being patched in the first 7 days

Exploitation is facilitated in certain clusters of hosts, given it’s easy to obtain stack information

PHP2Shell ( CVE-2026-109618 and CVE-2026-109619 ) arrived with predictions of a Log4Shell-scale mass exploitation event. Panic was visible, many rushed to update or even disconnect systems from the Internet until a patch was applied. PHP runs a large of the web and the vulnerable ranges were reported to cover every branch from 5.4 to 8.5, which are essentially the majority of versions we can see deployed in the internet installed base.

But, it turns out that the world dodged a bullet. Well, not exactly dodged, the bullet is still coming, although at a slower speed than anticipated. Make no mistake, these are very serious flaws that can and will be exploited. Their nuances, however, have bought the blue team a bit more time. On top of that, the internet reacted, and the patching efforts made a difference.

PHP2Shell: The timeline of events

Back in August 2026, two parties independently discovered the vulnerabilities later dubbed PHP2Shell: Ryan Austin, a researcher at the California-based security firm Calif, as part of the OpenAI "Patch the Planet" project in August 2026, and the Israeli-American cloud security company Wiz, a subsidiary of Alphabet Inc. and a part of Google Cloud. The vulnerabilities were reported to PHP and the responsible disclosure process started, still in August.

The PHP maintainers announced the update early and before release, after news of the vulnerabilities leaked on 20 October on the Hacker News forums, which leads us to today. But even before Oct 20, 2026, the action had already begun, as Amazon reported later, having seen scan activity going back to the 17th.

The only apparent exploit chain that looked like it made any sense came from 94.154.43.163, an IP address hosted at an ASN that might be familiar to some of you: (219502) Storm Industries LLC. That ASN is on a Spamhaus ASN-DROP-listed network with documented Mirai distribution and C2 activity. ASN-DROP is an unusually severe network-level designation. Ordinary hosting providers can accumulate abuse reports from individual customers. Spamhaus’s published ASN-DROP criteria concern autonomous systems assessed as hijacked or leased by professional spam or cybercrime operations, with no legitimate traffic observed.

On 24 October, 94.154.43.163 sent 30 requests to one sensor in roughly 100 seconds, combining oversized bodies, upload-progress requests and deeply nested fields. The same source attempted malware delivery the day before its PHP2Shell experiment. On 23 October, 94.154.43.163 sent 151 Realtek command-injection datagrams to 128 sensors, directing targets to fetch tadashi.mpsl.

Most other IP addresses also come from shady sources, so we are fairly certain that malicious threat actors are scanning more actively, despite only a few reports of proper exploits in the wild. One was the address implicated in Sophos’s subsequently retracted claim.

The apparent explosion in PHP scanning was largely a measurement trap, as some scanners are very noisy. The expanded analysis identifies 1,035 PHP-fetching addresses across 25 clusters.

So far, our honeypot data shows that botnet operators appear to be experimenting with PHP2Shell, but most observed traffic lacked the structure needed for exploitation. Request volume substantially overstated technical capability.

The vulnerabilities are real, patched, and under attack, but the underground does not believe reliable mass RCE exists yet. Forum users report that most public PoCs work only in a lab, and many are hunting for a working exploit. The money on offer is mostly speculative: bounties, profit- deals and a buyer for shells. We found no verified mass-compromise claim.

Skepticism dominates all conversations. Posters say PHP2Shell PoCs work locally but struggle against live targets because of build-specific offsets and ASLR, with brute-force attempts crashing workers. “PoC yes, RCE no” sums up the mood: one user reported zero successes against 20 targets. An Exploit contributor on 24 October claimed success with Apache + mod_php, mostly on low-cost hosting, but only denial of service with Nginx + PHP-FPM in a lab. A minority claimed exploitation was succeeding through complex, failure-prone chains.

AI features heavily in both development attempts and criticism. Posters describe widespread efforts to generate working exploits, while dismissing many GitHub PoCs as copied or AI-generated code that works only locally. Others call the publicity marketing for AI security vendors. On Dread, discussion is amused and fatalistic; one high-reputation user alleged an 8.5.12 patch bypass (the fixed 8.5 release), citing unnamed researchers, but the claim remains unconfirmed.

Requests for working exploits span Exploit, XSS, Cracked, BreachForums, PwnForums, Tahribat, Dread, and Telegram, among many others. Users want cross-build offsets, scanners, live targets, and testing environments. One lab-seeker was advised to build a WordPress installation; others asked where to follow exploit-development discussions.

Commercial offers are emerging alongside that demand. SafeHarbor offered $10,000 for a working exploit on 22 October, mentioning target lists, monetization, and possible profit-sharing; others mocked the budget. CodeStudio advertised general pay-after-results hacking. On 26 October, darkentity01 offered 25–5,000 per site for shell access allegedly obtained through PHP2Shell, with currency unspecified. N0deNull offered custom tooling and later claimed remote execution, but supplied no verified proof.

Technical description

There’s been a lot of back and forth on how exploitable PHP2Shell is, so we believe it’s worth doing a brief overview of the technical details of it. The exploit is associated with CVE-2026-109618 and CVE-2026-109619, which are used together to trigger RCE in a vulnerable instance. The original research does a good job explaining the underlying details and why and where the vulnerabilities exist, but our main interest here is in what conditions these are triggered and what are the requirements for it, so we’ll try to deconstruct the issues from a high-level perspective.

In the PHP2Shell case the primitives that allow for exploitation are an Out-of-Memory (OOM) corruption (CVE-2026-109618) and a stale global state (CVE-2026-109619). The OOM corruption allows an attacker to trigger an OOM error that forces a worker to exit the current context, leaving its memory in an invalid state. The worker then goes on to handle the shutdown procedure and, because the memory is in an invalid state (and attacker controlled), it reads and branches from there. The stale global state allows an attacker to lead a worker into an invalid global state following a request (similarly to the OOM scenario, a worker is interrupted without exiting cleanly), and a follow-up request will then be able to use that stale state.

The OOM corruption is achieved by doing a multipart POST request that contains crafted strings and fields whose parsing creates multiple arrays. The crafted strings contain pointers and metadata used to replicate internal PHP structures, and the purpose of the multiple arrays is to consume most of the request’s memory allowance. The corruption happens when a new element is being added to an array and its metadata is changed, but before the element is fully initialized, PHP tries to allocate memory for its key, reaches the limit, and exits the current context.

As the request goes to handle the shutdown procedure and free the array, the array’s metadata makes PHP process an element that was never fully initialized. By arranging memory reuse beforehand, the attacker aims to leave a pointer in that element that leads to a crafted string containing a fake HashTable. A normal flow would call the array’s destructor callback for each element, using a function pointer stored in the HashTable. In the attack scenario, cleanup reaches the fake HashTable, whose destructor pointer points to another function like zif_system . Together with crafted argument data, this allows for RCE.

This OOM corruption description is a simplification of a more complex flow, but even in this simplification there’s still a big question: how does an attacker know the addresses it must use to place and link the fake internal PHP structures, as well as the addresses for functions like zif_system ? And this is where the stale global state vulnerability enters: earlier stages use it to leak the heap and code addresses needed by the final request.

The stale global state issue relies on generating a request that initializes session upload-progress state and then leads the worker into an OOM scenario. This interrupts processing before the session state is properly reset. The request’s memory is freed, but the worker survives with global pointers still referencing that freed memory. A following request to the same worker can use those pointers before normal initialization resets them. By arranging for crafted data to occupy the freed memory, the attacker can manipulate what PHP reads, leading to the leaking of memory from the worker.

These vulnerabilities work in tandem to provide an RCE exploit, with reliability depending on the PHP build, memory layout, and how requests are distributed between workers. While the OOM corruption can be triggered within a single request, exploitation of the stale global state requires at least two requests to reach the same worker: one to leave the stale state behind, and a following request to use it before normal initialization resets it.

To effectively exploit these vulnerabilities, an attacker needs to identify or adapt to the target’s PHP build, the way PHP handles requests, and the relevant PHP and web server configuration. The PHP version alone is not enough, because different builds can have different memory layouts and function offsets. Exploitation also depends on reaching the affected operations, triggering the required interruption, and arranging memory allocations so the resulting invalid state can be controlled. For the stale global state, the relevant requests must reach the same surviving worker before that state is reset. Some of this information can be inferred or obtained through memory leaks during exploitation, rather than being known beforehand.

In the months leading up to October 21st, we measured the exposure of PHP instances in the internet being around 29.2M hosts, of which 18.4M (63.1%) disclosed a vulnerable version. The remaining did not provide version information, so the true number is higher than the one we measured. On top of this, 59.5% of the exposed population, 11M hosts, run an EOL branch, for which no patch, or only minimal backports for PHP2Shell exists.

A note for the attentive reader: in the introduction we mention vulnerable ranges as 5.4 to 8.5, because this is what the original research quotes as being the affected versions, and effectively the upload-progress feature was added in 5.4, but here we are looking at all older versions as well, we have not confirmed if older versions are indeed not affected, but we’d rather err on the side of caution, besides, why are people running PHP < 5.4 today?!

As we’ve previously described , PHP 7.4 (reached EOL in November 2022) is still the single largest branch in our data, with 18.7% vulnerable hosts, and its final release (7.4.33), runs on 2.85M hosts by itself. Many of these servers likely upgraded to 7.4 years ago and stopped there, because moving to PHP 8 means changes to the application. Nearly half of all vulnerable hosts (47.9%) run PHP 7 or older, and PHP 5.6, unsupported since 2018, still accounts for 6.5%.

Some of the most common old versions are the defaults that long-term Linux distributions shipped: 5.4.16, 5.3.3, and 7.2.24 together account for more than 940,000 hosts. Distribution vendors sometimes backport security fixes to these packages without changing the version number, so a few of these servers may be in better shape than their banner suggests.

Supported branches make up the other 40.5%: 8.3 (16.0%), 8.2 (12.0%), 8.4 (8.1%), and 8.5 (4.4%). These are the hosts a patch could reach (excluding the minimal source-backports that PHP provided). Close to half of them ran the latest point release before the fix, such as 8.3.35 or 8.4.26, which suggests they're maintained and updated regularly.

From a geographical perspective, by volume the United States has the most vulnerable hosts, with more than 3 million (16.5% of the total). Germany (10.7%), Japan (5.8%), and the Netherlands (5.5%) follow, and each of these four countries had more than a million vulnerable hosts before the fix. Russia, Denmark, the United Kingdom, and France each had between 640,000 and 810,000. These countries are to some of the world's largest hosting markets, which largely shows where PHP hosting is concentrated.

If we look at the of EOL branches, some countries are more problematic than others, where they have a significant percentage of hosts that are in an EOL version. On the other hand, some countries have a big percentage of hosts in a supported branch, which makes updating easier (foreshadowing…?)

To have a sense on how the internet responded to PHP2Shell, we analysed the number of hosts that were patched after the patch release, and validated what their version was before October 21st.

Of the 9.47 million hosts we saw running a vulnerable version before the release and scanned again afterwards, 33.5% now run a patched build.

On supported branches (8.2 through 8.5), 68.6% (on average) of 4.13 million hosts patched within a week. The newer the branch, the faster it moved: 8.5 and 8.4 both reached 77%, 8.3 reached 66%, and 8.2 reached 62%. Most of these hosts patched in place, moving from the point release straight to the fixed one, which suggests that hosting providers and distribution packages pushed the update for their customers.

On EOL branches (8.1 and older), only 6.4% of 5.34 million hosts are patched, and every one of them got there by jumping to a supported branch. The largest single group in the whole dataset is PHP 7.4: 1.73 million hosts, of which 91% still ran 7.4 at the end of the week. These servers were already years behind on security updates before PHP2Shell, and a new vulnerability didn't change that.

Looking day by day, the curve is steep and then flattens. On the day of the release, 9.8% of the supported-branch hosts we scanned already ran a fixed build. By October 22 it was 55%, by October 24 it was 78%, and on October 27 it reached 85%.

Across all hosts with a known PHP version, the curve flattens much sooner, at around 38%. The gap between the two lines is the EOL population: a large of the internet's PHP runs on versions that will never receive this fix, and those hosts keep the overall exposure high even as supported deployments catch up.

When we group hosts by the sector, the spread is wide. Nonprofits and NGOs (65.4%), business services (62.3%), and utilities (53.3%) patched fastest. Insurance, transportation, education, healthcare, manufacturing, and technology all landed above the 33.5% overall rate.

Finance is one of the surprises. At 26.3%, it trails the overall rate despite being one of the most heavily regulated sectors. Telecommunications (23.6%) and retail (24.4%) sit at a similar level, and media and entertainment (8.7%), real estate (8.8%), and food production (11.8%) are the slowest.

Geography tells a similar story, and it tracks hosting providers closely. Sweden leads at 89.6%, followed by Denmark (65.5%), Norway (57.6%), Germany (51.6%), and Austria (47.3%). These countries are to large shared-hosting providers that updated their PHP fleets within days. One Swedish provider alone patched 96% of its vulnerable hosts in the first week. Looking back, some of these were also the countries with the lowest percentage of EOL hosts.

The United States, which has the most exposed hosts of any country, sits below the overall rate at 26.2%. Much of Asia moved far more slowly: China (3.8%), South Korea (3.9%), Taiwan (5.2%), Vietnam (8.5%), and India (8.7%) all remain under 10%. Most of South America sits between 10% and 20%, and Eastern Europe ranges from 6% in Lithuania to 30% in Czechia.

The pattern holds across every view of the data. Where a provider manages PHP for its customers, patches arrive in days. Where the site owner is responsible, or the server runs a branch that no longer gets fixes, they often don't arrive at all.

Because of the specificities of PHP2Shell, we looked for clusters of hosts running PHP that might make for easier targets, where some of the requirements to trigger the exploit are easier to meet. As we are still in the early days of the disclosure, we will describe the observed clusters in general terms without giving away too much detail. We believe these clusters are easier targets, and they still account for a significant number of the hosts we observed between late September and late October 2026:

Distro-frozen legacy stacks: systems still running the default web stack of an end-of-life distribution, unchanged since install. Past the distribution's end of life the version banner is accurate, since fixes are no longer backported, and every host runs the same packaged build. This tells an attacker exactly what is running and reduces the exploit difficulty. Around 97% of these hosts did not change version over the month we observed.

Shared hosting: systems where a single front-end serves a large number of sites; in one case 24 addresses carry over 33 000 host names. Some platforms let each customer pick a PHP version, including releases from the PHP 4 and 5.2 era, while others offer a single frozen version to every customer. Depending on how well the provider isolates sites, a compromise here could lead to multiple compromised entities.

Network appliances: most firewall and appliance management interfaces do not disclose the PHP version, or even that they run PHP. However, by fingerprinting the appliance (e.g. over 80K pfSense and 26K OPNsense hosts), one can infer the PHP version and configuration it ships with. These are also administrative interfaces exposed to the internet, which is a problem in itself. Just on October 29th, Palo Alto identified active exploitation of PHP2Shell in some of their devices.

Embedded devices: similarly to the clusters, many embedded devices ship outdated PHP versions (e.g. PHP 7.2.22 on backhaul radios, PHP 5.1.6 on consumer devices). They cannot be patched by their operators, often run as root, and frequently lack protections like ASLR, which makes exploitation significantly easier.

PHP2Shell has not broken the internet, but not because it is harmless. Both CVEs are on CISA's KEV list and exploitation on honeypots has been confirmed. What slowed things down is the bug itself. A reliable chain needs a memory leak and a corruption step to land on the same worker, using offsets that match the exact PHP build. So far that has kept most attackers at the "PoC yes, RCE no" stage. Our sensors saw a lot of noisy scanning and only one chain-shaped sequence. Underground forums are full of people looking for a working exploit and short on anyone who has one.

Exploitation gets easier wherever the target is predictable: distro-frozen stacks, shared-hosting platforms, appliances whose PHP build follows from their fingerprint, and embedded devices without ASLR. Many of these are also the hosts that will never be patched.

In the first week, 68.6% of hosts on supported branches (8.2–8.5) moved to a fixed build, mostly thanks to hosting providers and distribution packages. Only 6.4% of hosts on end-of-life branches did, and the ones that did got there by upgrading. Around 11 million vulnerable hosts run a branch that will never get an upstream fix. That group, not the patched majority, will set how long PHP2Shell stays a problem.

Supported branches: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's fixed package).

End-of-life branches (8.1 and older): treat these hosts as unpatchable. Upgrade to a supported branch, rely on a vendor that backports security fixes, or take them off the internet.

Appliances and embedded devices: check vendor advisories. Do not expose management interfaces to the internet.

Everyone: assume a reliable exploit will eventually spread. The window bought by build-specific offsets will close as attackers build per-build offset tables and target the predictable clusters described above.