More than half of the PHP2Shell status updates we tracked came before the patch existed.
On October 21, PHP shipped emergency fixes for PHP2Shell, two critical remote code execution bugs that affect every PHP version released in the last decade (Wiz). Details leaked a day early, so the companies that run PHP knew a serious problem was coming before there was anything to install.
Many of them didn’t wait. Across the services StatusGator monitors, more than 100 posted outages, maintenance windows or warnings about PHP2Shell before the patch was released. Some took entire products offline. Others turned off file uploads or paused deployments. A few caused outages at companies that never mentioned PHP at all.
About this data. StatusGator has monitored cloud status pages since 2015 and now tracks more than 11,000 services. On October 21, 1,790 of them reported a degradation and 363 entered a maintenance window, both about 1.6 times a normal Wednesday. That puts it among the most disruptive 2% of days we have recorded since 2019. Full methodology is at the end of this post.
As of 00:30 UTC on October 22, 213 services we track had posted at least one status update naming PHP, PHP2Shell, or the two CVEs (CVE-2026-109618 and CVE-2026-109619). Another 59 posted security maintenance or precautionary notices that day without naming PHP. Some reported problems caused by a vendor with its own PHP security issue. (We monitor vendor relationships to help understand impact.)
Of those 213, 113 posted before PHP’s 14:00 UTC release. Most of the disruption we measured was providers protecting themselves, not attackers getting in.
The effect showed up across everything we monitor. On October 21, 1,790 services reported some kind of degradation. On a typical weekday over the past two weeks, that number is about 1,100. (That’s even more than the day before, when a Google Cloud outage in Europe disrupted hundreds of services.)
The world was waiting for the patch
PHP2Shell was supposed to be disclosed on October 22. Details leaked on October 20, and PHP moved the release up a day, according to The Hacker News. That left providers with an awkward gap: they knew a critical bug was coming, but there was nothing to install yet. Many chose to take things offline rather than wait.
All times UTC.
| Time | What happened |
|---|---|
| Oct 20, evening | PHP posts an advance notice and moves the security release to October 21 |
| Oct 21, 01:56 | First status page update citing PHP that we recorded from German cloud host dataforest. |
| 03:05 | Australian hosts Synergy Wholesale and VentraIP post advisories |
| 07:02–07:10 | Five hosting brands, all owned by World Host Group (WHG), post near-identical “PHP Update” notices within eight minutes (Rocket.net, hosting.com, Doteasy, Nimbus Hosting, Stablepoint) |
| 13:34 | Advisories for both CVEs appear on GitHub (Wikipedia) |
| 14:00 | PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Help Net Security). 120 services had cited PHP by this point. |
| 14:19 | watchTowr reports active exploitation attempts (The Hacker News) |
| 14:00–17:00 | Patch rollout. Status updates citing PHP climb to 171 services. Knock-on outages begin at vendors’ customers. |
The curve rises steadily from early morning UTC and is already more than halfway up when the patch lands. Europe’s working day drove much of it. Dutch- and Belgian-language status messages show up throughout the morning list.
Who took action, and how far they went
Nearly half of the 213 services that cited PHP took something offline. 69 marked themselves down and 32 more entered maintenance. The other 112 posted warnings or advisories while staying up. By 00:30 UTC, 97 of the 213 had returned to operational, a median of 4.5 hours after their first notice.
Three groups stood out:
Hosting providers and developer platforms. These were first and most numerous, since they run PHP on behalf of their customers. Namecheap, Hostinger, IONOS, Fasthosts, Liquid Web, Cloudways, Kinsta, Pantheon, Acquia, Flywheel and Pagely all posted updates. Laravel Cloud paused deployments, and Laravel Forge‘s control panel slowed under the load of customers updating PHP.
European software companies that switched off entirely. Several chose a full shutdown over the risk of running unpatched. Teamleader took its Focus product offline. CCV Shop took merchant webshops offline. Simplicate, Speakap, Prepr and ValidSign did the same, and DENIC, which runs Germany’s .de registry, took its website down as a precaution.
Education. Open LMS, Schoology, PowerSchool and Nearpod all posted PHP-related notices during the school day in the US.
Most popular quick fix: disable uploads
At least 18 services disabled or restricted file uploads instead of going fully offline. That lines up with PHP’s own guidance: one of the bugs can be reached through PHP’s upload progress tracking, and the recommended stopgap is to turn that feature off (per The Hacker News). KingHost said so directly in its status update.
The result was a day of partial outages that users would only notice when they tried to attach something. Rentman, Ryver, ClickMeeting, inSided, ShopWired, GetResponse, Pirate Ship and EverTrue were among those that switched off uploads or imports for part of the day.
Your services’ services were also affected
Some of the most visible problems came from services that never ran into PHP themselves. They depended on a vendor that did.
| Upstream service | What happened | Services that reported knock-on problems |
|---|---|---|
| Dropbox Sign | Emergency maintenance, 14:35 to 16:15 UTC. AdvicePay‘s status page attributed it to the PHP vulnerability. | Ashby, Ironclad, JazzHR, AdvicePay, SalesRabbit, Funnel Leasing |
| BambooHR | Took parts of its service offline while it handled the vulnerability, starting 10:49 UTC | Zapier, Merge, Kudos, Culture Amp, Ashby |
| MyParcel | Taken offline as a precaution over “vulnerabilities in an external component” | Picqer |
E-signature and HR integrations caused the most knock-on problems, a sign of how many products depend on them. For companies downstream of those providers, parts of their site, product or integrations simply stayed broken until the provider patched.
Status pages are not the whole story
In addition to official status pages, StatusGator’s Early Warning Signals algorithm watches for spikes in problem reports from users and alert when a service looks unhealthy, whether or not the provider has said anything yet. For planned maintenance, status pages usually came first. BambooHR, for example, posted its notice about an hour before the first user report reached us.
But many providers had unplanned side effects from their maintenance, and Early Warning Signals caught some of those first:
- Nearpod: 2 hours 48 minutes ahead. User reports started at 15:47 UTC and our Early Warning Signal fired at 15:52. Nearpod’s status page moved to down at 18:40, with a maintenance notice that cited PHP. 209 of the 257 reports we received that day came in before that update.
- Laravel Forge: 1 hour 26 minutes ahead. Presumably crushed by traffic, Forge’s control panel slowed down in the afternoon, and its status page later listed PHP updates among the tasks running slowly. It marked the problem resolved at 18:07. Users kept reporting errors. Our Early Warning Signal fired at 18:59, and Forge’s status page went back to down at 20:25.
- Docebo: reports while the page said operational. Docebo’s status page went back to operational at 13:49. Our Early Warning Signal fired at 14:08, with users describing the platform as down for security maintenance. Perhaps they resolved their own incident before patching was actually complete.
- PlayPosit: the page never changed. Our Early Warning Signal fired at 14:07. PlayPosit’s own status page stayed green all day. The only acknowledgment came from parent company WeVideo‘s page, which posted urgent security maintenance for PlayPosit at 13:38.
On a day full of announced maintenance, the problems nobody announced were the ones users found first.
Our takeaways for huge patch days
- A zero-day can mean planned downtime, announced on short notice. More than 100 services chose to go offline or post warnings before a patch existed. If you depend on them, their status pages are where you find out.
- Know your vendors’ vendors. Teams using Ashby, Ironclad or JazzHR lost e-signatures because of Dropbox Sign. Teams syncing through Zapier or Merge lost BambooHR data. None of those companies mentioned PHP in their own updates. StatusGator tracks service relationships to help you understand impact.
- Have a stopgap that isn’t a full shutdown. Turning off uploads kept at least 18 services partly running while they waited for the fix. Other workarounds were floated, but simply disabling whole features helped many companies reduce their risk.
- Watch what users are saying. The outages that weren’t announced, like Forge’s relapse and PlayPosit, showed up in user reports first.
StatusGator tracks the status pages of more than 11,000 cloud services in one place and uses Early Warning Signals to flag problems that providers haven’t posted yet. If PHP2Shell caught your team off guard, try it free.
Methodology
Limits. Keyword matching undercounts. It misses providers that patched without saying why or described it in vague terms. Our search terms were mostly in English, so non-English updates that didn’t name PHP or the CVEs were likely missed. These numbers are a minimum.
Source. Status changes recorded by StatusGator from the public status pages of more than 11,000 services, from 18:00 UTC on October 20 to 00:30 UTC on October 22. We counted only real status transitions, not repeated checks.
Cited PHP (213 services). At least one status update whose title or body mentions PHP, PHP2Shell, CVE-2026-109618 or CVE-2026-109619. We used several search patterns to catch variations of these terms.
Related (59 services). Updates posted on October 21 that mention security maintenance, precautionary shutdowns, disabled uploads, or an affected upstream vendor (Dropbox Sign, BambooHR, MyParcel), without naming PHP. Notices about the unrelated eMudhra certificate authority compromise, which also made headlines that day, were excluded.
Daily degradations. Services moving from operational to warning, down or maintenance on a given UTC day. The weekday average covers October 7 to 19. The “normal Wednesday” comparison and the 2% figure compare each day with the average of the same weekday over the previous eight weeks, across 2,327 days since 2019. This adjusts for the number of services we monitor growing over time.
Early Warning Signals. Spikes in user-submitted problem reports detected by StatusGator. Lead time is measured from the Early Warning Signal to the provider’s next status page change.
