NEW data shows that organisations aren’t patching PHP2Shell as quickly as attackers are exploiting it. The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were publicly disclosed on 21 October, and threat activity surged immediately. Cloudflare’s Matthew Prince reported thousands of exploitation attempts in the 10 hours before disclosure, rapidly increasing to hundreds of thousands within hours and millions soon after.
Check Point Research put the early impact at around 10% of organisations worldwide, while open-source signals from Ox Security and Flare indicated that the overwhelming majority of PHP deployments remained unpatched or were running outdated PHP branches. Cisco Talos suggested about half of PHP systems wouldn’t receive patches. By 23 October, Ox noted the 99% figure had edged down to 97.5%, and Flare reported only about 5% of upstream-supported PHP versions had been updated.
The article notes that addressing PHP2Shell is not simply a matter of a one-click update. Discovering all PHP deployments is essential, since PHP often runs as a component of other software, and patches may be delivered via backports or firmware updates from manufacturers rather than a straight PHP version bump. In practice, many migrations or replacements involve substantial rewriting and testing, leading to slow remediation.
Temporary mitigations include disabling PHP’s session.upload_progress.enabled to block a known attack path for CVE-2026-109619, though this does not fix CVE-2026-109618. Canonical’s Ubuntu fixes cover all versions since 14.04, but applying them may still leave systems reporting older PHP versions. The piece emphasises the importance of asset discovery, inter-organisational coordination, and, where possible, extending WAF protections to third-party applications while fixes are rolled out.