PHP2Shell: Pierluigi Paganini on the PHP flaws under attack

PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS 4.0, that allow unauthenticated remote code execution against every common PHP web deployment from PHP 5.4 onward. PHP shipped fixes on 21 October 2026 in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12, but Amazon’s honeypots had recorded exploitation attempts from 17 October, four days before the patches existed. In a question-and-answer piece published by Security Affairs on 24 October, the site’s founder Pierluigi Paganini answers the questions operators are asking: how serious the flaws are, why attackers moved first, and what to do this week. This article summarises his answers and adds the version, exposure and mitigation detail from the vendor advisories.

What is PHP2Shell?

PHP2Shell is a pair of memory-handling bugs in the PHP interpreter itself, not in WordPress, Laravel or any other application written in PHP. According to Cloudflare, the flaws were disclosed on 21 October by researchers at Calif.io, Wiz, OpenAI and Quarkslab. Datadog Security Labs, which reproduced both bugs, describes CVE-2026-109618 as a failure to handle memory exhaustion during request initialisation, which leaves half-built internal state that later code treats as valid, and CVE-2026-109619 as stale state carried from one request into the next when a worker process is reused, reachable through PHP’s session upload-progress feature and, on PHP 8.5 only, through fatal-error backtraces. Both end in command execution on the server. Datadog lists the Apache module, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as affected, with default configurations vulnerable.

The disclosure did not go to plan. SecurityWeek reported on 21 October that details of both flaws had leaked online ahead of the coordinated release, and PHP had said it would bring the patches forward if technical details appeared or in-the-wild exploitation emerged. Both happened. Cloudflare says it deployed protections about nine hours before public disclosure after observing attack traffic, and Sansec warned that mass exploitation would begin within 15 minutes of the patch release. Older branches are covered only partly: PHP published minimal source backports for 7.4, 8.0 and 8.1, and distributions such as Ubuntu have shipped fixed packages that keep their existing version numbers, so a server reporting PHP 8.3.6 can be either patched or exposed depending on the package build. On 23 October Cloudflare added that a related flaw in the same upload-progress feature, CVE-2026-115560, affects fully patched releases including 8.5.12 and will need a further PHP update.

Why did attackers move before the patch?

Because they could, and that is the point Paganini makes first. Asked how researchers uncovered the early exploitation, he explains that AWS saw attempts against its honeypot network four days before disclosure and patches, which shows that attackers can find or weaponise a flaw before defenders have anything to deploy. He adds two cautions that the headlines have tended to drop: a detected attempt is not evidence of a successful compromise, and while AI may be shortening the time from bug to working exploit, not every attack is AI-driven. The window between disclosure and exploitation, he says, can now be measured in hours, and many organisations still run patching schedules built for a world where it was measured in weeks.

What can an attacker do with remote command execution?

Run commands on the server as the web process, which in practice means everything that process can reach. Paganini’s answer sets out the consequences in plain terms: theft of the data the application holds, installation of malware, changes to the website’s content, and use of the compromised server as a platform to attack other systems. For a business that translates into outages, financial loss and reputational damage; for an ordinary user it means exposure if their data sits on an affected system. He is careful to separate the two audiences. Operators of PHP applications have work to do now; individual users do not need to panic, though unique passwords and multi-factor authentication limit the damage if a service they use was compromised.

What should operators do this week?

Patch PHP itself, then look backwards. Paganini’s checklist is short: apply the security updates, confirm which PHP applications are exposed, review logs for suspicious activity back to 17 October, restrict access to vulnerable services, investigate any sign of compromise, and use temporary mitigations wherever a patch is not yet available. The vendor advisories fill in the mechanics. Datadog’s interim measures for CVE-2026-109618 are to lift PHP’s memory limit at administrator level and cap request sizes at the front end; for CVE-2026-109619, to disable session upload progress and, on PHP 8.5, fatal-error backtraces, then restart every worker. Cloudflare’s managed WAF rules for both CVEs have been on by default for all plans, including free ones, since 03:02 UTC on 21 October, with a note that the rule covers only PHP’s default upload-progress field name. Detection signals worth searching for include multipart POST requests carrying session or upload-progress fields the application never uses, “Allowed memory size exhausted” errors reported at an unknown location on line 0, and, most directly, shells or download utilities spawned by web-server worker processes.

Paganini’s broader answer is that traditional vulnerability management is still necessary but no longer sufficient when exploitation precedes the patch. Operators need an inventory of what is internet-facing, controls and monitoring in front of it, temporary mitigations ready to apply, an incident-response plan that has been tested, and the habit of checking whether they were targeted before a flaw was public rather than after.

How much of the web is exposed?

Most of it, by any measure that counts PHP hosts. CybelAngel’s analysis of Shodan banner data published on 21 October counted about 2.24 million internet-facing hosts advertising PHP, of which roughly 1.5 million reported a version; 883,717 of those, 59 per cent, were on branches with no official release, led by 368,570 hosts on PHP 5.x and 329,358 on 7.x. The United States accounted for 228,770 of the hosts on unsupported branches. WordPress.org’s own statistics, cited in the same analysis, put 35.1 per cent of WordPress sites on an unsupported PHP version, including 16.46 per cent still on PHP 7.4. Because those hosts cannot simply install a vendor release, the realistic fix for many of them is a migration to a supported branch, which is exactly the kind of work that does not happen in a week.

Does AI change the equation?

Paganini’s answer is a measured yes on both sides. AI can analyse code, spot suspicious patterns and speed up the conversion of a flaw into a working exploit, but it is one factor among several and its value to defenders depends on reliable data, skilled teams and response processes that actually run. The point is not theoretical. One of the four organisations credited with the PHP2Shell disclosure is OpenAI, and four days before the Security Affairs piece SOCRadar documented ransomware affiliates using commercial coding assistants for reconnaissance planning and exploit work, a finding we covered in our report on The Gentlemen after the leak. The same tools are now on both sides of a flaw like this one, and the side that applies them faster wins the window.

What this means for site owners

If you run anything on PHP, and most of the web does, the question is not whether your application is affected but whether your interpreter has been rebuilt. Updating WordPress, plugins or themes does nothing for PHP2Shell; Cloudflare makes that point explicitly, and so does Paganini. Check the PHP package version against your distribution’s advisory rather than the version string alone, confirm the web server was restarted after the update, apply the upload-progress mitigation until the follow-up fix for CVE-2026-115560 ships, and read your logs from 17 October forward. Ransomnews ran that checklist on its own host this week: the fixed package from our distribution arrived on 22 October, the web server was restarted, and the web application firewall rules were already in place. The flaws will be with us for years on the hosts that never update, which is why ransomware affiliates, who buy and harvest access in bulk, will treat PHP2Shell as a long-term supply of entry points rather than a one-week event. Our guide to business ransomware protection covers the monitoring and backup controls that limit what an attacker can do once inside.

Frequently asked questions

Sources and further reading

• Security Affairs, Pierluigi Paganini answers questions about the PHP2Shell flaws (24 October 2026)
• Cloudflare, Cloudflare deploys protections against php2shell vulnerability (21 October 2026, updated 23 October)
• Datadog Security Labs, PHP2Shell: critical vulnerabilities in PHP, detection, analysis and remediation (21 October 2026)
• SecurityWeek, PHP2Shell: mass exploitation looms for leaked critical PHP flaws (21 October 2026)
• CybelAngel, 2.24 million internet-facing PHP hosts, 59 per cent on unpatched branches (21 October 2026)
• Ubuntu Security, USN-8948-1: PHP vulnerabilities (21 October 2026)
• AWS Security Blog, Using AWS WAF to apply mitigations for PHP2Shell
• Related: The Gentlemen after the leak and initial access brokers and the 2026 ransomware supply chain

Reporting by the Ransomnews Research Team, drawing on Pierluigi Paganini’s answers as published by Security Affairs, linked and credited above. Technical details are taken from the vendor advisories cited; no exploit code or payloads are reproduced.