PHP2Shell Timeline: How the Hosting Industry Reacted

On October 21, GoDaddy had patched every PHP version on its Managed Hosting for WordPress by 19:30 UTC. Its Web Hosting servers, which run custom PHP packages from a vendor, were fully patched at 13:30 UTC the next day. Both rollouts addressed PHP2Shell, two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can under the right conditions let an unauthenticated attacker run code on a server.

The pattern repeats across the industry. Edge networks had blocking rules in place hours before PHP’s advisories went public at 13:34 UTC on October 21, and distributions and control panel vendors shipped fixed builds the same day. CloudLinux’s fixed alt-php packages, the builds behind PHP Selector, reached the stable repositories for CloudLinux 7, 8 and 9 at 00:07 UTC on October 22, more than ten hours after the advisories. InMotion Hosting patched its dedicated servers on October 21, while its shared servers waited for CloudLinux. The source of the PHP build was a major factor in the timing, alongside each provider’s own rollout.

In the days that followed, PHP disclosed a third flaw, CloudLinux released builds with the PHP.net version numbers, and CISA added the original two CVEs to its Known Exploited Vulnerabilities catalog. The sections below follow the response from the CVE leak on October 20 to that listing on October 26, and the chart that opens them covers the first 54 hours.

Two Critical PHP Flaws Leaked Ahead of the October 21 Security Release

Key facts

• Before the release: Cloudflare protected customers on free and paid WAF plans by default from 03:02 UTC on October 21, and Imunify360 shipped its first ruleset at 09:08 UTC.
• Checking a fix: backported builds such as CloudLinux’s alt-php85 8.5.11-5 kept the old version number, so hosts such as Hostinger and GoDaddy pointed customers to the PHP build date.
• End-of-life branches: PHP fixed 8.2 to 8.5 and published source backports for 7.4 to 8.1, so coverage of older versions depended on who built the package.
• Attempts, not confirmed breaches: CISA’s KEV listing also covers attempted exploitation, and no agency or host cited here reported a confirmed compromise.

Selected milestones from the first 54 hours of the PHP2Shell response, in UTC. The amber bar marks exploit-tool requests reaching more than 3,600 servers in Imunify360’s network, not confirmed compromises. Each tick in the hosting lane is one timed milestone from the rollout table below, and some ticks overlap because they came minutes apart. Sources: PHP, Imunify360, vendor and host updates.

Before October 20: An Embargo and an Early Probe

The fix was prepared under embargo. According to the PHP Foundation, the coordinated release was planned for 14:00 UTC on October 22, and according to PHP’s release announcement, Linux distributions and long-term support vendors received the patches in advance. By its own account, cPanel also took part in the coordinated disclosure and built and tested fixed packages before the public release. Wiz Research, one of the firms that reported the flaws to PHP, worked before disclosure with Google Cloud, Cloudflare, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva, Vercel and others on guidance, detections and mitigations.

October 17: Amazon Threat Intelligence recorded an exploitation attempt against its MadPot honeypots from an anonymized IP address, four days before disclosure. AWS notes that it remains unclear how the actor obtained exploit information before disclosure.

Vercel Paid $50,000 for a KVM Escape That Has No CVE and No Patch. Every VPS Host Is Waiting for the Write-Up.

October 20: The CVE IDs Leak

About 15:00 UTC: The two CVE IDs began circulating, without technical details. PHP moved the release forward to 14:00 UTC on October 21 while distributors were still packaging the fix.

About 20:00 UTC: Calif, one of the firms that reported the flaws, mistakenly published a video of its proof of concept that revealed a few additional details.

Evening: InMotion Hosting began switching off session upload progress for every PHP version on every server it manages, work it finished early on October 21. Setting session.upload_progress.enabled to 0 in php.ini or the PHP-FPM pool, then restarting every PHP worker, is the interim measure PHP’s advisory gives for CVE-2026-109619 and the one that appears most often in providers’ updates. The advisory warns against relying on .user.ini or ini_set() for it. InMotion also turned off fatal_error_backtraces on PHP 8.5, a second setting the advisory recommends for that branch.

23:33 UTC: According to Imunify360, the first request from a public exploit tool named PHP2Shell reached a server in its network.

October 21, Before the Release: Edge Rules and Switched-Off Settings

02:00 to 08:00 UTC: AWS recorded further exploitation attempts against MadPot.

03:02 UTC: Cloudflare turned on protection by default for customers on free and paid WAF plans. It asks paid-plan customers to confirm that its Managed Ruleset runs in block mode, and reports observing attack traffic against its customers, with attackers changing the payload to try to get past its rules.

07:34 UTC: Patchstack received reports of multiple active exploitation incidents from hosting partners.

07:41 UTC: Chainguard, which like other distributors had received the patch in advance, published built images containing the fix, more than six hours before the coordinated release. The PHP Foundation calls this a unilateral break of the embargo that let attackers study the fix in binary form.

08:00 UTC: OVHcloud put a workaround in place on its Web Hosting clusters. Cloudways followed from 09:16 UTC, and Pantheon also applied network-level measures before the release.

From about 08:20 UTC: According to Imunify360, requests from the PHP2Shell tool, which had reached at most a few dozen servers an hour overnight, scaled up sharply. By 11:00 UTC, they had reached more than 3,600 servers in its network.

09:08 UTC: Imunify360’s first WAF ruleset for the flaws arrived, covering ModSecurity and Coraza. Further rulesets followed at 13:07 UTC, which brought blocking rules to LiteSpeed servers, and at 17:17 UTC, according to CloudLinux.

11:30 UTC: SiteGround had rolled out server-level mitigation rules and disabled the affected functionalities on all supported PHP versions.

11:35 UTC: Hadrian reported exploitation “in the wild at scale.”

Other edge providers differed in how much they left to customers. Akamai released a dedicated App & API Protector rule and reports that its existing command injection rules are mitigating weaponized payloads. Bunny’s upload-progress rule, activated ahead of the release, blocks only when a Shield Zone’s WAF is in blocking mode, and Fastly’s Next-Gen WAF rule requires customers to opt in.

Several hosts described their interim measures without giving times. Hostinger switched off upload progress on its LiteSpeed, PHP Selector and cPanel PHP-FPM setups and on phpMyAdmin, added ModSecurity rules that run in deny mode and, on its web hosting platform, rejects malformed upload requests that PHP could misread. Namecheap enabled its HackGuardian feature globally on EasyWP, putting sites into partial read-only mode in which customers could not install new themes or plugins.

Some organizations took sites offline as a precaution. The Dutch National Cyber Security Centre (NCSC-NL) temporarily took its own website offline, and according to the agency, several other organizations, including government bodies, did the same. Before the release, Dutch broadcaster NOS named MijnOverheid.nl, DigiD and the website of the Tweede Kamer, the lower house of parliament, among the sites taken offline.

These measures had limits. Most of them were aimed at CVE-2026-109619, above all at its session upload progress path, and Hadrian reports that the majority of attacks it observed abused that path. As of October 22, Imunify360 reported that no rule blocked the out-of-memory path of CVE-2026-109618 yet, and that a variant built to look like a normal upload from the site’s own page could still get through. PHP’s advisory gives separate interim controls for CVE-2026-109618, including memory and request-size limits, and describes all of its interim measures as reducing exposure to specific attack paths without making a server safe. Bunny added two rules for multipart patterns described in the CVE-2026-109618 advisory at 14:15 UTC, after the release.

Tools that work inside PHP or the application had less room. According to Monarx, the flaws trigger before its PHP runtime protection can intervene, so ThreatShield cannot directly prevent exploitation. Wordfence notes that some attacks can begin before WordPress starts. On most shared and managed hosting, where the provider controls PHP, that leaves the fixed build as the remedy and its timing with the host.

Januscape and Bad Epoll: Two Linux Flaws That Let One Customer Take Over the Whole Server

October 21, From 13:34 UTC: Advisories and the First Fixed Builds

13:34 UTC: PHP’s GitHub security advisories went public, and the release followed at 14:00 UTC. PHP fixed the four branches it supports, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and published minimal source backports for 7.4, 8.0 and 8.1. All other builds came from packagers. PHP’s release announcement also urged users of the volunteer-maintained Remi repository for Enterprise Linux to switch to distribution packages or build from source, because the repository would not have updates that day. On October 21, InMotion’s UltraStack ONE servers on AlmaLinux 9 were waiting for Remi’s PHP 8.3 build.

13:42 UTC: The Danish host one.com warned that its countermeasures could temporarily disrupt uploads to websites, direct database access and calendar synchronization with third-party email applications, and reported CalDAV and phpMyAdmin back online at 16:44 UTC. Infomaniak disabled upload progress, and phpMyAdmin was unavailable on its platform for part of October 21.

14:39 UTC: CloudLinux planned fixes for alt-php and ea-php by 19:00 UTC.

14:52 UTC: PHP 8.2 to 8.5 were patched at one.com, the earliest timed patch milestone among the providers in our table.

15:39 UTC: Liquid Web reported that no patches or modifications had been rolled out to production systems while it tested deployment paths in staging. Kinsta likewise rolled out each PHP version once it had been validated, starting with 8.3 and 8.5 at 19:04 UTC.

16:26 to 19:48 UTC: Patching made Cloudways’ own website and affiliate portal unavailable.

17:50 to 19:49 UTC: Hetzner (17:50 UTC), OVHcloud’s Web Hosting clusters (17:53 UTC), Hostinger’s Agency Hosting (19:12 UTC), GoDaddy’s Managed Hosting for WordPress (19:30 UTC) and Pantheon’s live sites on PHP 8.2 to 8.5 (19:49 UTC) reported patched PHP.

Distributions and panel vendors shipped through the afternoon and evening. According to cPanel, EasyApache 4 PHP updates were on its mirrors within minutes of PHP’s release, with fixed builds for every supported version of cPanel & WHM within an hour. The table lists the coordinated packagers in alphabetical order, with the branches each vendor’s own notes name. Its times mark release milestones at each vendor, not when servers had the fix: DirectAdmin’s CustomBuild compiles PHP on each server, Docker builds its images from the merged definitions, and, as Wordfence and CloudLinux note, the fixed code runs only after the package is installed and PHP is restarted. Times are UTC on October 21 unless marked, and a date alone means the source gave no time.

Source	Release milestone	Branches
AlmaLinux	Testing 17:50, production 21:15	All streams on AlmaLinux 8, 9 and 10, including retired 7.2, 7.3, 8.0 and 8.1
CloudLinux alt-php	00:07 on October 22 (stable, CloudLinux 7, 8 and 9)	5.2 to 8.5
CloudLinux ea-php	20:55	ea-php52 to ea-php85
cPanel EasyApache 4 (25.91)	October 21	8.2 to 8.5, backports for 7.4, 8.0 and 8.1, none for 7.3 and older
Debian	October 21	8.4 in Debian 13, 8.2 in Debian 12
DirectAdmin CustomBuild	13:54, older branches 17:31	8.2 to 8.5 and 7.4 to 8.1, then 5.6 and 7.0 to 7.3
Docker official images	Definitions merged 15:16, rebuilt images followed	8.2 to 8.5
Ondřej Surý PPA (Ubuntu)	14:45	8.2 to 8.5
Plesk	October 21	8.2 to 8.5, backports for 7.4, 8.0 and 8.1 on Linux
Red Hat	15:53 for RHEL 8 php:7.4, others 20:06 to 20:36	php:7.4 and php:8.2 on RHEL 8, php 8.0, php:8.2 and php:8.3 on RHEL 9, php 8.3 and php8.4 on RHEL 10
Ubuntu	October 21	22.04, 24.04, 26.04 and 26.10, plus 14.04 to 20.04 through Ubuntu Pro

Control panels also updated their own PHP, separate from the versions that serve customer sites. In cPanel, the PHP that runs its interfaces, including Roundcube webmail, moved to 8.4.27 in versions 138.0.18, 136.0.50 and 134.0.66, with the fixes backported to 8.1.34 in 110.0.153. According to cPanel, an automated fixer prompts servers to install these updates and also updates its own PHP on versions 112 through 132. Plesk updated the PHP in its plesk-engine and sw-engine components to 8.4.27 in Plesk Obsidian 18.0.81 Update 4 and 18.0.80 Update 11.

CISA’s alert on October 21 advised organizations that cannot update immediately, or that run PHP 8.1 or earlier, to take PHP-based systems offline until they are patched. PHP offered no releases for 8.1 and older, so coverage of those branches depended on who built the package. Combell adapted PHP’s security fixes for its older versions and had patched every version from 5.6 to 8.5 on its shared hosting on October 21. Pantheon used its LTS vendor for 5.6 to 8.1, Cloudways its ELTS partners for deprecated versions from 5.6, and DreamHost its PHP Extended Support program. On its cPanel and Plesk shared hosting and managed servers, hosting.com was rolling out patches for every version from 5.2. Infomaniak patched 7.4 and newer and asks customers on older versions to upgrade.

Some setups were left without a fix. The EasyApache 4 packages cPanel ships for PHP 7.3 and older did not receive it. InMotion’s guidance lists no fix for PHP 7.4, 8.0 and 8.1 on Control Web Panel, and none for any PHP on CentOS 7, where it points customers to AlmaLinux 9 or TuxCare’s PHP Extended Lifecycle Support. Huntress notes that researchers published their own patches for end-of-life branches and that it cannot evaluate whether they are effective.

Customers running their own servers were outside these rollouts. GoDaddy, Hostinger, IONOS and Namecheap each left the PHP update to customers who manage their own VPS or dedicated server, and those customers had to obtain, install and activate the fixed build themselves.

Linux Kernel Flaw PwnEscape Lets a Virtual Machine Read Its Host’s Memory. Upstream Fixes Are Out.

October 21 to 22: Shared Hosting Waits for CloudLinux

20:18 UTC: CloudLinux’s status page listed fixed alt-php versions as available in its stable repositories. At 20:40 UTC, Namecheap reported patched versions in CloudLinux’s staging repositories, being deployed to a focus group of servers, and at 20:55 UTC CloudLinux released its fixed ea-php builds.

21:59 UTC: CloudLinux corrected its earlier update. The alt-php packages had gone to the TuxCare ELS alt-php repository, and servers on CloudLinux 7, 8 and 9, which install alt-php from CloudLinux’s own repositories, did not have them yet. From 22:29 UTC, it gave instructions for adding the ELS repository as a workaround. InMotion’s shared servers were among those waiting for CloudLinux on October 21.

00:07 UTC, October 22: The stable release of fixed alt-php for CloudLinux 7, 8 and 9 completed. Other rollouts continued through the night. Pantheon patched its live sites on PHP 5.6 to 8.1 at 00:16 UTC, Cloudways completed its Autonomous platform at 01:02 UTC, and by 01:20 UTC GoDaddy had patched Windows Hosting and was deploying its vendor’s patches to Web Hosting. Hostinger finished its cPanel servers at 03:34 UTC, and Hetzner patched PHP 5.6 and 7.3 at 04:32 UTC.

05:18 to 10:11 UTC: Namecheap’s deployment was almost over at 05:18 UTC, one.com had every available version patched by 05:20 UTC and Hostinger completed all managed hosting at 06:44 UTC. Kinsta resolved its incident at 08:26 UTC, IONOS at 10:10 UTC, and Cloudways had all active servers patched by 10:11 UTC.

The table covers providers that published timed updates, in alphabetical order, through the end of their rollouts. Providers reported different stages, from the start of maintenance to a finished rollout or a closed incident, so each time marks that provider’s own milestone and the times are not directly comparable. Times are UTC on October 21 unless marked, converted where the provider gave local time.

Provider	Patch milestones (UTC)
Cloudways	Autonomous 01:02 on October 22, all active servers 10:11 on October 22
GoDaddy	Managed WordPress 19:30, Windows Hosting by 01:20 on October 22, Web Hosting 13:30 on October 22
Hetzner	7.4 and 8.0 to 8.5 at 17:50, 5.6 and 7.3 at 04:32 on October 22
Hostinger	Agency Hosting 19:12, cPanel servers 03:34 on October 22, all managed hosting 06:44 on October 22
InMotion Hosting	Dedicated done, VPS in progress and shared waiting for CloudLinux as of October 21
IONOS	Maintenance from 15:31, resolved 10:10 on October 22
Kinsta	8.3 and 8.5 from 19:04, all of 7.4 to 8.5 rolling out by 23:25, resolved 08:26 on October 22
Namecheap	CloudLinux packages to a focus group at 20:40, deployment almost over at 05:18 on October 22, maintenance finished 16:50 on October 22
one.com	8.2 to 8.5 at 14:52, all available versions by 05:20 on October 22
OVHcloud (Web Hosting)	7.4 to 8.5 on all clusters at 17:53, 5.3 to 7.3 at 17:07 on October 23, maintenance completed 09:50 on October 26
Pantheon	Live sites on 8.2 to 8.5 at 19:49, live sites on 5.6 to 8.1 at 00:16 on October 22, pre-production 02:08 on October 22, incident closed 16:19 on October 22

October 22: Old Version Numbers and Last Servers

05:23 to 13:17 UTC: CloudLinux’s native PHP builds, the operating system’s own php packages rather than alt-php or ea-php, were still catching up. At 05:23 UTC, the native 7.3 fix for CloudLinux 8 was still being prepared. At 09:21 UTC, fixed native builds for CloudLinux 10 PHP 8.3, CloudLinux 9 PHP 8.0 and 8.1 and CloudLinux 8 PHP 7.2, 7.4 and 8.0 were in the beta channel and had reached about 0.2% of servers. At 13:17 UTC, CloudLinux added that some servers could not install the fixed packages because their cloudlinux-release package was outdated.

13:30 UTC: GoDaddy had patched all PHP versions on Web Hosting. At 13:33 UTC, Namecheap still had four regular shared hosting servers in progress, and at 14:12 UTC OVHcloud extended its Web Hosting maintenance to October 26 while it worked on PHP releases older than 7.4.

14:31 UTC: CloudLinux addressed confusion over version numbers directly. A patched site may not report PHP 8.5.12 or 8.4.27, because many vendors backported the fix into the version a server already ran, so the same fix carried different version strings depending on who built the package. CloudLinux confirmed that its fixed alt-php85 8.5.11-5 and ea-php84 8.4.26-2 carry the fix for both CVEs despite the lower numbers, and that reports of PHP 8.5.11 being vulnerable refer to the original PHP.net release.

16:19 to 19:50 UTC: Pantheon closed its incident at 16:19 UTC, reporting persistent but limited probing that was being blocked. Namecheap finished its maintenance at 16:50 UTC. At 19:50 UTC, CloudLinux reported fixed native PHP packages in the stable channel for every affected version. The same day, NCSC-NL reported that several websites taken offline had come back online.

The table shows how the same fix appeared under different version strings, depending on who built the package.

Package	Version string with the fix	Upstream release with the fix
CloudLinux alt-php85	8.5.11-5	8.5.12
cPanel EasyApache 4 ea-php84	8.4.27	8.4.27
CloudLinux build of ea-php84	8.4.26-2	8.4.27
Red Hat Enterprise Linux 10 php8.4	8.4.27	8.4.27
AlmaLinux 10 php8.4	8.4.24 (alma.1 build)	8.4.27
Ubuntu 24.04 php8.3	8.3.6-0ubuntu0.24.04.13	8.3.36

Hosts pointed customers to other checks. Hostinger notes that some sites show 8.5.11 after the update and asks customers to look for a build date of October 21 or later, hosting.com points to the same build date in phpinfo(), and at 17:15 UTC GoDaddy advised its Web Hosting customers to check the build date instead of the version number. Infomaniak reports that its version numbers stayed the same. Wordfence advises asking the host directly whether the PHP service is patched for both CVEs and has been restarted, and warns against relying only on php -v at a command prompt.

For administrators, the check depends on the package. CloudLinux’s instructions have administrators confirm a fixed alt-php by searching the package changelog for the two CVE IDs. Its native PHP 8.2 and 8.3 packages moved to the new upstream releases with changelogs that name no CVE IDs, so on those the version number is the check. CloudLinux also noted on October 22 that its security advisory metadata was not yet published, so security-only updates such as yum --security did not list the fixed packages.

October 23 to 26: A Third Flaw, Renumbered Builds and a KEV Listing

October 23, 00:08 UTC: CloudLinux released alt-php builds with the PHP.net version numbers, such as alt-php85 8.5.12-1, to its stable repositories for CloudLinux 8 and 9. At 13:10 UTC, ea-php builds with the new numbers followed, along with the renumbered alt-php for CloudLinux 7. According to CloudLinux, servers that had installed the earlier fixed packages were already protected, and the new builds only bring the version numbers in line with PHP.net. Namecheap later reported installing them on all its shared hosting servers, so PHP 8.2 to 8.5 there now show the PHP.net version numbers, while 5.2 to 8.1 keep their numbers with the fixes applied.

October 23: PHP published an informational advisory about a third flaw, CVE-2026-115560. According to PHP, it can only occur when an application sets session.serialize_handler to php_binary or php_serialize in its configuration and switches it to php at runtime with ini_set() before calling session_start(), with session upload progress still enabled. PHP is handling it in the regular release cycle and recommends setting session.upload_progress.enabled=0 until the next bugfix release, the same setting it listed for CVE-2026-109619 on October 21. The October 21 releases do not fix it. Hostinger (13:25 UTC), Pantheon (17:35 UTC) and GoDaddy (21:00 UTC) reported that the measures already in place covered their managed platforms. GoDaddy asked VPS customers to apply the setting themselves.

October 23, 17:07 UTC: OVHcloud completed the deployment of the patch for PHP 5.3 through 7.3 on its Web Hosting clusters.

October 23: Unit 42, Palo Alto Networks’ threat research team, reported post-compromise activity at a European government agency that it initially linked to PHP2Shell. On the same day, NCSC-NL reported that it knew of one report of possible abuse abroad, without confirmation that the attack succeeded. It added that further research showed the vulnerabilities to be complicated to exploit and the chance of large-scale abuse smaller than first estimated.

October 23, 21:36 UTC: CloudLinux corrected an earlier instruction and asked servers that had added the ELS alt-php repository as a workaround to keep it enabled. That repository is becoming the single source of alt-php and other ALT packages. CloudLinux 10 already receives them only from there, and CloudLinux 7, 8 and 9 will follow.

October 23 to 26: Red Hat added fixes for Extended Update Support and other long-life RHEL streams.

October 25: Unit 42 retracted its October 23 update, because it could not confirm that initial access was associated with the PHP2Shell CVEs.

October 26, 09:50 UTC: OVHcloud reported its Web Hosting maintenance completed.

October 26: In a summary of its response, cPanel advised administrators to confirm that arm64 hosts run a fixed version, since some package repositories published fixed builds for amd64 first, and to rebuild container images, CI runners and internal tooling that embed PHP. The same day, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog, with a due date of October 29, a deadline that applies to US federal civilian agencies.

Infinity Core: Six Linux Kernel Bugs, Five Root Exploits, Uneven Fixes

What Was Still Open on October 27

The fix for CVE-2026-115560 waits for PHP’s next regular release, and until then PHP recommends keeping session upload progress switched off. Red Hat still listed php:8.4 on RHEL 9 as affected, and CloudLinux’s incident remained open, with alt-php moving to the ELS repository.

Attempts Versus Confirmed Compromise

Companies with visibility into network traffic reported attack activity, though they described its scale differently. AWS, which recorded the earliest attempt, now describes PHP2Shell as “seeing broad exploitation attempts in the wild” and notes that it is unclear whether any of the attempts it observed would have succeeded against real-world systems. Fastly reported “evidence of active attacks in-the-wild pre-disclosure,” and watchTowr’s Attacker Eye honeypot network had observed exploitation in the wild by October 21. Pantheon’s network-level mitigations blocked over 60,000 suspicious requests probing the vulnerability on October 21, activity it had described earlier that day as low but slowly increasing.

The statements on compromise point the other way. Patchstack’s own telemetry showed only probing attacks shortly after the release, with no hard evidence of breaches at that point. The PHP security team had not identified a functional exploit among the proofs of concept it inspected by the time of the release. CISA had not observed exploitation when it published its alert on October 21. The Canadian Centre for Cyber Security noted reports of an available proof of concept but had identified no active exploitation. NCSC-NL had no signals of successful abuse at first, and its own tests found that the proofs of concept it examined did not yet work. Huntress had not observed in-the-wild exploitation on partner systems as of 20:30 UTC on October 21, and in Wordfence’s lab, the CVE-2026-109619 proof of concept ran code only on a specially configured PHP 8.5.11 build and crashed a normal optimized build of the same version.

Hosts reported the same. Kinsta closed its incident with no evidence of any breaches, Combell had detected no successful attacks, and Hostinger saw no increase in malware infections or unusual activity on its managed hosting.

Neither of the two later signals confirms a compromise. Unit 42 withdrew its link between an agency compromise and PHP2Shell. CISA’s KEV listing reflects what CISA calls reliable evidence of exploitation, but by its own definition the catalog covers attempted exploitation, including code that runs on a honeypot or fails on a system that is not vulnerable, as well as successful exploitation, and the listing does not say which applies. Imunify360 attaches a qualifier to its own figures that holds for request counts generally: they cover attempts that reached a server and do not show whether any attack succeeded.

Final Thoughts

The week showed how much of a fix’s timing depended on where a host’s PHP came from. Edge rules and switched-off settings bought hours against the session upload path, but not against every route, and on shared and managed hosting the fixed build remained the remedy. The timeline also separates three moments that are easy to conflate: PHP publishing a fix, a vendor shipping a fixed package, and a server running it after installation and a restart. Only the last one removes the flaw from a server. A week on, CISA’s KEV listing records exploitation activity without showing a successful compromise, and the third flaw’s fix still waits for PHP’s next regular release.

About the Data

Times are given in UTC. Where a provider published local times, we converted them, and where a source gave only a date, we report the date. The timeline draws on status pages, change logs, security advisories and vendor posts published between October 20 and October 27, several of which were updated after publication, and reflects their state on October 27. Traffic figures are each company’s own count of requests reaching its network and cannot be compared or added. Statements about protection and compromise are those of the provider or agency named.