How Upsun handled PHP2Shell: protection in place 22 hours before the patch

On 21 October 2026, the team behind PHP released an emergency fix for two critical security flaws. PHP is the programming language behind a large share of the web, including WordPress, Drupal and many online stores. Researchers at Wiz named the flaws PHP2Shell. An attacker could use them to take control of a website without ever logging in.

Updating a website, its CMS, or its plugins doesn't help. The only real fix is (and was) a new version of PHP itself.

On Upsun Cloud, we had WAF rules protection in place about 22 hours before that fix existed. Customers didn't need to do anything. Once the PHP team released the fixes, we patched and restarted affected sites for them, including sites on older versions of PHP that PHP itself no longer supports.

Here's how it happened. All times are UTC.

The warning (20 October)

PHP gave advance notice that a critical fix was coming the next day. There were a few details, but mainly a warning.

That was enough to start protecting Upsun Cloud customers. Every visit to a site on Upsun passes through our edge layer first, a protective layer between the internet and our customers' applications. A change there protects every customer at once, without touching their code.

Our engineers quickly set new rules to stop the kinds of requests most likely to trigger the flaw. By 15:50, those rules were blocking attacks in every region. The official fix was still almost a day away.

Disclosure day (21 October)

Morning: getting ready

At 08:40 we opened an incident and split the work. One group focused on the fix. Another focused on keeping customers informed. We learned from past incidents that the same people can't do both well at the same time.

By 09:45, our status page and a blog post were live. Both told customers the same thing: protection is already in place, and you don't need to do anything. Our support team used one agreed answer for every question, so everyone heard the same message.

Through the morning, engineers kept strengthening the protection, adding more rules.

Midday: attackers move early

By late morning, attackers were already scanning the internet for vulnerable sites, hours before PHP released any details. Our edge rules caught them and blocked them. At 12:50, we told customers on the status page that we were seeing attacks and that they were already protected.

Afternoon: the fix arrives

PHP released the fix at about 13:36, a little ahead of schedule. It covered current versions of PHP, plus older versions PHP no longer maintains.

Customers usually decide when to roll out their own platform updates. For a flaw this serious, we didn't want anyone waiting, so we got ahead of it and applied the patch for our customers.

We did it carefully. The update replaced only PHP itself. It didn't touch anyone's code or configuration. Each new version was tested in a separate region before it reached a single customer site. And if a project had changes waiting to go live, we didn't push them out. We contacted the owner instead, so nothing reached production before they chose to release it.

The only planned downtime was a brief refresh to apply the patch. During that refresh, Upsun holds incoming page requests until the site is ready, so most visitors saw a slower page load instead of any errors.

By late afternoon, every protective rule was blocking in every region, stopping about 1,700 malicious requests an hour, mostly from automated attack tools.

• 18:02: Every current version of PHP was patched across all Upsun Cloud regions.
• 19:13: We published a detailed technical post for developers on the Upsun Developer Center.
• 19:36: Patches for older versions started rolling out.

Evening: the older versions

Patching current versions is the expected part. The harder work was everything else.

• Older versions PHP no longer supports: patched the same evening. Customers on them got the fix without having to upgrade.
• Versions too old to fix: we are contacting every affected customer directly, so no one has to find out from a status page.
• Sites that couldn't be updated automatically: we are contacting those owners directly too.

At 23:35, the status page confirmed every Upsun Cloud region was updated.

The morning after (22 October)

At 04:12, the last patches were in place and the status page moved to monitoring. A small amount of cleanup continued through the day.

What made the difference

A protective layer in front of every site. It's part of how Upsun handles security, and it's the only reason we could protect every customer before a fix existed, without asking anyone to change anything.

We maintain PHP ourselves. When PHP released fixes for versions it no longer supports, we could put them to use the same day.

We got ahead of it, safely. We applied the patch proactively, so no site sat exposed while an update waited in a queue. It changed only PHP, never customers' code or configuration, and nothing went live that they hadn't chosen to release.

Clear roles from the first hour. Engineers could focus on fixing. Customers still got clear, consistent answers.

What you should do

• On a supported version of PHP? Nothing. You're already patched.
• On a very old version of PHP? Plan an upgrade. Our protection reduces the risk, but it doesn't replace a fix.
• Not sure? Ask your developers to check the Developer Center post, or open a ticket from the Upsun Console.
• Run PHP anywhere else? Make sure it gets patched there too.

For the full incident history, see the status page.

For the technical details, including affected versions and how to check your environment, read Critical PHP security patches: Upsun rollout and what to check on the Upsun Developer Center.