Cato CTRL Threat Research: PHP2Shell Exploitation Attempts in the Wild, and How Cato IPS Blocked Them

Executive summary

On 21 October 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, a pair of critical runtime vulnerabilities known as PHP2Shell. One day later, we described how our self-evolving CVE mitigation agent turned the patch into reviewed IPS protection in minutes. This report follows what happened next, including how quickly attackers moved, what their attempts looked like, and how Cato’s cloud-delivered IPS protection blocked them on inspected customer traffic.

Key findings

• Attempts started on patch day. We observed no external PHP2Shell-pattern requests from 17 to 20 October. The first scanning or invalid-PoC attempt appeared on 21 October, the day the fixes were released, and about two thirds of all attack sources in our sample first appeared that day.
• Cato IPS blocked both exploitation attempts and scanning or invalid-PoC attempts. In the sample analyzed, about 41% of blocked attempts were exploitation attempts aimed at remote code execution (RCE), and 59% were scanning or invalid-PoC attempts. About 96% of all hits related to CVE-2026-109618.
• Exploitation attempts fell into two main types. Command-execution attempts were the most common, followed by deserialization attempts.
• A handful of sources drove most attempts. In our sample, a small number of source IPs generated most of the blocked attempts, repeating proof-of-concept (PoC) style requests.
• Attempts appear opportunistic, not sector-focused. Healthcare made up about one third of the organizations that received blocked attempts, but the same sources reached unrelated sectors and countries.

Introduction

PHP2Shell is a pair of flaws in the PHP core runtime rather than in a single application or plugin. CVE-2026-109618 concerns out-of-memory handling that can interrupt request initialization and leave invalid data for cleanup to process. CVE-2026-109619 concerns request-owned state that is retained after its memory is freed and later accessed by the same worker. Both can lead to unauthenticated code execution, and the highest demonstrated risk is in Apache mod_php, where exploitation can occur before any application code runs.

In our first threat brief, Cato AI native SASE delivers PHP2Shell protection at machine speed, we described how our self-evolving CVE mitigation agent built a PoC and generated IPS signatures in minutes, with researcher review before release. At that point, our initial telemetry showed scanning activity only.

This follow-up answers the questions security teams ask next. Once the patch was public, how fast did attackers move, what did they try, and did protection keep up? We look at timing, attempt types, sources, the industries that received attempts, and the tooling involved.

Methodology

We queried a sample of anonymized, aggregated Cato cloud security telemetry from 17 to 26 October 2026 for inbound requests matching the PHP2Shell pattern and our PHP2Shell IPS protections. We group blocked attempts into two categories, exploitation attempts and scanning or invalid-PoC attempts. The second category covers simple scanning as well as exploit attempts that used false or invalid proofs of concept. Results are shown as approximate percentages, and industries are grouped so that no individual organization can be identified.

Limitations

• Sample-based. The figures reflect a sample of Cato-inspected traffic, not global internet activity, and show the shape of activity rather than exact volumes.
• Attempts, not outcomes. This research describes attempted attacks, not compromises.
• Geolocation is not attribution. Source country reflects where an IP is hosted, often a cloud or VPS provider, not who operates it.

Technical insights

1. Timeline from silence to patch-day onset

Figure 1 shows the clearest finding. From 17 to 20 October, we observed no external requests matching the PHP2Shell pattern. On 21 October, the day PHP published its fixes, the first external scanning or invalid-PoC attempt appeared in the morning, and that day accounts for about 72% of the PHP2Shell-pattern requests in our sample. This is consistent with Amazon Threat Intelligence, which reported proof-of-concept exploits circulating on 21 October. Amazon also reported a single exploitation attempt against its own honeypots on 17 October, four days before public disclosure. We saw no such pre-disclosure activity in Cato customer traffic.

Figure 1. Daily share of external PHP2Shell-pattern requests across the observation window.

Daily volume is spiky because one noisy scanner can dominate a day. A better measure of how activity spread is when each attack source first appeared. In Figure 2, 100% represents all attack sources observed during the study window. About two thirds of them first appeared on 21 October, and new sources appeared on most days after.

Figure 2. Attack sources by first-seen date, as a share of all sources observed in the window.

Hour by hour, 21 October unfolded in two phases (Figure 3). A few early scanning or invalid-PoC attempts in the morning were followed in the afternoon by a single source sending a burst that made up about 80% of the day’s requests. Later in the day, activity fanned out, with about 40% of the day’s sources active within a single hour, which is typical of a PoC circulating and many operators running it at once.

Figure 3. Share of requests and of active sources per hour on 21 October.

2. From scanning and invalid PoCs to code execution attempts

In the sample analyzed, about 96% of blocked attempts related to CVE-2026-109618, the out-of-memory flaw, and about 4% to CVE-2026-109619. About 59% were scanning or invalid-PoC attempts, and 41% were exploitation attempts aimed at remote code execution (Figure 4). Some attempts relied on PoCs that were not valid against the vulnerable code path, so we grouped them with scanning activity. Exploitation attempts fell into two main types, command execution and deserialization, with command execution the more common.

Figure 4. Blocked PHP2Shell attempts by CVE and by intent, based on a sample of Cato telemetry.

3. Source geography

Based on a sample of the sources we observed, the United States leads by share of source IPs (about 36%), followed by the Netherlands and Germany (about 14% each). By share of blocked attempts, US-hosted sources account for about 54%, the Netherlands about 18% and Moldova about 16% (Figure 5). Activity was concentrated, with a small number of sources generating most of the blocked attempts in the sample.

Figure 5. Source IP geolocation by share of sources and share of blocked attempts, based on a sample of sources.

4. Who received the attempts

Blocked attempts reached organizations across a broad range of industries (Figure 6). Healthcare and social care is the largest group at about one third, followed by technology and security services. The remainder is spread across professional services, automotive, education and non-profit, and other sectors, in several countries.

Figure 6. Industry mix of the organizations that received blocked attempts.

Does the healthcare share mean healthcare was singled out? The evidence suggests not. The same sources sent attempts to healthcare organizations and to unrelated sectors in different countries. For example, a single source reached healthcare, technology and software organizations on the same day. The sample is small, and the share may also reflect the composition of our customer base. One plausible explanation is shared technology. PHP-based portals, forms and line-of-business applications are common across many industries, including healthcare.

Additional recommendation

Cato customers do not need to deploy anything for PHP2Shell protection. The IPS signatures are delivered and enforced from our cloud. We also recommend updating every PHP instance to the fixed version released by the PHP project.

Conclusion

PHP2Shell showed how short the window between patch and attack has become. We saw no PHP2Shell-pattern traffic for four days, then scanning or invalid-PoC attempts on the day the fixes were released, followed by exploitation attempts. The attempts were automated, repetitive and opportunistic, reaching organizations across many industries and countries. With a runtime-level bug, the deciding factor is whether an organization exposes PHP, not which industry it is in.

Dedicated PHP2Shell signatures, built by our self-evolving CVE mitigation agent and reviewed by our researchers, blocked exploitation attempts on inspected traffic. Because enforcement happens in the Cato cloud, customers did not need to install anything, and this virtual patching reduces exposure while application owners upgrade.

This research covers a sample of attempts on inspected traffic, not outcomes, during the first days after disclosure.

We will continue to monitor PHP2Shell activity and update protections as attacker techniques evolve.

Indicators of attack

Source IPs from a sample of blocked PHP2Shell attempts. Cloud and hosting IPs may be reassigned.

Public reporting corroborates one of these sources. On AbuseIPDB, independent reporters tagged 85.11.167.243 as PHP2Shell activity. None of the sources in our sample appear in Amazon Threat Intelligence’s published PHP2Shell indicator list.