PHP2Shell rollout patched vast hosting infrastructure
PHP2Shell exploitation attempts were already reaching websites on October 21, 2026, as hosting engineers waited for fixes to two critical PHP vulnerabilities. Kinsta says it responded with Cloudflare filtering, temporary PHP configuration changes and a platform-wide patch rollout covering hundreds of thousands of containers. By October 23, those filters had blocked more than 550,000 related requests, while the host’s investigations found no evidence that an attempt had succeeded.
The PHP security team gave advance notice on October 20 that a critical release would arrive the next day. The flaws were subsequently identified as CVE-2026-109618 and CVE-2026-109619. Both affect PHP’s internal handling of memory and, under certain conditions, could permit remote code execution, meaning an unauthenticated attacker could make the server run code. Their CVSS 4.0 score was 9.2. CVSS, or Common Vulnerability Scoring System, is a standard scale for expressing the severity of a security flaw.
For WordPress owners, the location of the vulnerabilities was crucial. PHP is the runtime, the underlying software that executes WordPress, so updating a plugin, theme or WordPress itself could not correct the vulnerable PHP code. The runtime had to be patched by whoever managed it. Kinsta reports that its engineers began seeing requests aimed at the flaws during the early hours of October 21 and manually inspected the targeted sites for evidence of compromise.
Every production and staging environment on Kinsta’s platform was already behind Cloudflare. A staging environment is a private copy used to test website changes. Cloudflare introduced emergency Web Application Firewall rules before the public PHP2Shell disclosure. A WAF is a filter that examines web traffic and can reject requests matching known attack techniques. Kinsta says its engineers reviewed each new rule in Cloudflare’s changelog and changed its action to Block across the platform, without requiring customers to configure individual sites.
This filtering provided temporary protection while patched PHP packages were prepared. Cloudflare continued modifying its detections as attackers changed their payloads to evade existing rules. It also introduced full transaction detection, which considers information from both the incoming HTTP request and the server’s response and can stop a matching response from reaching the requester. By October 23, the protections covering Kinsta sites had rejected more than 550,000 PHP2Shell-related requests. That number represents blocked requests, not unique attackers, successful compromises or even necessarily 550,000 separate attack campaigns.
Kinsta also disabled PHP’s session upload progress feature through the session.upload_progress.enabled setting. PHP’s advisory identified that change as a mitigation for some exploitation paths, although it did not cover every possible route to the vulnerabilities. On October 23, the PHP team issued further advice to keep the feature disabled until a later bug-fix release. Kinsta kept this configuration change and the Cloudflare rules active throughout patch deployment and verification.
Official fixes arrived on October 21 as PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The host also needed packages for PHP 7.4, 8.0 and 8.1, branches that no longer received routine security releases directly from the PHP project. Its package provider, Freexian, supplied fixes for these older long-term-support branches through backporting, which applies a security correction to older software without forcing an immediate upgrade to a newer branch. This also means that a PHP version number alone does not always prove whether a vendor-maintained installation contains a particular fix.
Packages arrived progressively. PHP 8.5.12 entered Kinsta’s mirror at 14:24 UTC on October 21, deployment began at 15:54, and tens of thousands of containers were updated by 17:45. PHP 8.3.36 became available at 18:50, with its rollout beginning alongside PHP 8.5 by 19:04. Patched PHP 7.4, 8.0 and 8.1 packages arrived between 21:17 and 22:28, with deployments starting at 22:28. PHP 8.2 and 8.4 packages appeared at 23:25, followed by deployment at 01:37 on October 22. A container is an isolated software environment used to run a site and its supporting services.
At 04:31 UTC on October 22, 1,888 containers, approximately 0.5% of the total, still needed additional attention. Kinsta says engineers worked through those environments rather than treating package availability as proof of installation. At 08:26, it reported 100% protection coverage and marked the public incident resolved. The company continued checking environments afterward, with its firewall and PHP configuration mitigations still active.
Blocked-request totals could not establish whether earlier attempts had succeeded, so engineers continued manual inspections and traffic monitoring. Kinsta says it exchanged threat information with Patchstack, its Vulnerability Protection partner, and discussed observations and practices with other hosting providers. Cloudflare supplied attack filtering, while Freexian delivered the patched packages. According to Kinsta, these investigations found no evidence of successful PHP2Shell-related breaches, a carefully limited finding that does not mean attacks were absent.
Concern also drove precautionary shutdowns. The Netherlands’ National Cyber Security Centre temporarily took its website offline, while government sites in Germany, France, Belgium and Finland were suspended. Japan’s prime minister urged operators to patch quickly or temporarily stop services if they could not update. Kinsta customers proactively suspended about 3,000 sites, while others enabled site-wide challenges or requested server-level traffic blocks. Kinsta did not recommend taking hosted sites offline because its emergency filtering was already active. After patching, it identified and reactivated environments suspended specifically over PHP2Shell while leaving unrelated suspensions untouched.
The incident illustrates why site owners should establish who controls their PHP runtime, how quickly that party can deploy an emergency fix and what temporary defenses are available before patches arrive. Managed platforms can perform runtime updates centrally, but owners should still seek clear confirmation of coverage and incident findings. As a relevant option for readers reviewing that responsibility, AEU Hosting is managed WordPress hosting, secured end to end.
The central lesson is that PHP2Shell could not be solved inside the WordPress dashboard. Effective response required layered filtering, a limited configuration mitigation, patched PHP packages for current and older branches, verification across every environment, and evidence-based checks for compromise.