Last week we covered two critical vulnerabilities that put millions of PHP instances at risk and the steps organisations should take. For CVE-2026-109618 and CVE-2026-109619, dubbed PHP2Shell, the picture has changed significantly since then: attacks have moved from probes that crash servers to shells that actually execute commands, and the US cybersecurity agency CISA has added both flaws to its Known Exploited Vulnerabilities (KEV) catalog.
If you have not patched yet, this post explains why the answer to “when?” is now “immediately”.
Timeline: from leak to working shell
- Before the patch: Technical details leaked online; exploitation attempts began before fixes were available.
- 21 October 2026: PHP released emergency versions fixing both flaws.
- 23 October 2026: CISA updated its alert with a Sigma detection rule and said it had not yet observed successful exploitation.
- First honeypot report: About 26 hours of monitoring logged 30 out-of-memory errors and 11 worker crashes, but no code execution.
- 24 October 2026: 35 shells were launched across three honeypots: the first confirmed remote code execution in the wild.
- 26 October 2026: CISA added both CVEs to the KEV catalog.
Meanwhile, security firms reported millions of exploitation attempts after the patch was released.
How the attack chain works
The attack seen on honeypots run by Perplexity researcher Adel Karimi is a four-stage chain of HTTP requests:
- Memory exhaustion: the first requests exhaust PHP’s memory, forcing the process into a specific state.
- Memory disclosure: follow-up requests leak memory contents.
- ASLR bypass: the leaked information makes it possible to defeat ASLR, the protection that randomises memory addresses.
- Command execution: the final request runs a shell command on the server.
The traffic closely matches a public proof-of-concept exploit and is consistent with exploitation of CVE-2026-109618. One IP address produced 3 shells on a single honeypot; another produced 32 shells across all three. No second-stage payload download was observed during monitoring, which suggests attackers are, for now, validating access and building target lists.
Expel’s Marcus Hutchins called the findings by far the highest-quality confirmation of in-the-wild PHP2Shell exploitation he had seen so far.
An important caveat: conditions favoured the attacker
Karimi’s honeypots ran PHP 8.4.26 under Apache mod_php with a single worker. The researcher stresses that this was an intentionally favourable setup and does not measure reliability on other configurations. That is no reason to relax: attacks usually mature on the easiest targets first and then spread.
Which versions are safe?
The patched versions PHP released on 21 October:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Unsupported branches (7.4, 8.0, 8.1) are not covered by these releases. A source patch was published for them, and some packagers produced builds from it. Even so, do not treat an end-of-life PHP version as safe; plan the upgrade.
Watch out: php -v can mislead you
Distributions such as Ubuntu, Debian and RHEL often backport security fixes without changing the version number. A patched Ubuntu 24.04 server, for example, may still report 8.3.6 in php -v. Verify the fix from the package changelog and the distribution’s security notice, not from the version string. Third-party PHP repositories may also ship updates a few days after the official release.
Checklist for organisations
1. Patch and restart processes
Upgrade every PHP installation to a patched version. Without a restart, PHP-FPM, Apache (mod_php) and containers keep running the old code in memory. Rebuild container images on a patched base image.
2. Find unknown PHP assets
Forgotten admin panels, test environments, old campaign sites and third-party applications (CMS, e-commerce, support portals) are the most commonly missed targets. Cortex Xpanse discovers your internet-facing assets from an attacker’s perspective and exposes these blind spots.
3. Hunt back in time, assuming breach
On systems that were internet-facing before you patched, look back to at least 17 October for:
- Repeated out-of-memory errors and worker crashes in PHP logs
- Unexpected processes and outbound connections started by the web server user (e.g.
www-data) - New or modified files in web directories (web shells)
- Matches for the Sigma rule published by CISA in your SIEM
Platforms such as Cortex XDR and Cortex XSIAM automatically detect and correlate suspicious process chains and web shell behaviour on servers.
4. Apply virtual patching while you patch
For systems that cannot be patched right away, inline prevention layers such as Palo Alto Networks Advanced Threat Prevention buy time by stopping exploit traffic at the network level. Check that your security profiles are applied to the relevant traffic and set to block.
5. Remove unnecessary exposure
Take admin interfaces and internal applications off the internet and restrict access through a VPN or Zero Trust Network Access (ZTNA). A PHP application that is not exposed to the internet will not be hit by the first wave of campaigns like this one.
Why did it move so fast?
PHP2Shell is a concrete example of how much shorter the vulnerability lifecycle has become in the frontier AI era: leaked technical details, pre-patch probing, a working exploit within days and a CISA KEV listing within five days of the patch. At this pace, “we will patch in the next maintenance window” is not enough. Lasting defence comes from an up-to-date asset inventory, a fast patch process, network-layer protection that covers the patching window and detection that catches a breach early, all working together.
At Albisec we can inventory your internet-facing PHP assets, review your Palo Alto Networks security profiles against PHP2Shell and run a rapid investigation for a possible breach. Get in touch or open a support ticket.
Sources: SecurityWeek, “PHP2Shell Exploitation Moves From Probes to Working Shells”, Eduard Kovacs, 26 October 2026 (updated 27 October); PHP security releases of 21 October 2026. Image: Albisec.
