36 hours, whole estate patched: How Nublue handled PHP2Shell
When the PHP2Shell vulnerability broke, our infrastructure team had mitigations live across every client by Wednesday afternoon and the whole estate patched within 36 hours. Official arm64 patches were running late, so we built and signed our own rather than leave clients waiting. Here’s how the week unfolded.
By Maddi Nuttall

When the PHP2Shell vulnerability broke on Wednesday morning, our infrastructure team went straight to work. Within 36 hours, every client on our estate was protected, patched and secure.
That included clients on arm64 infrastructure, whose official patches were running late. Rather than leave them waiting, we built our own. Here's how the week unfolded, and what it says about managed hosting done properly.
What is PHP2Shell?
PHP2Shell is the name given to two critical vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Either one can let an attacker run their own code on a web server without logging in. They are rated 9.2 out of 10 for severity.
What made this one serious is where the flaws live. They sit in PHP's runtime, not in any one application. So a perfectly well-built Magento, WordPress or Drupal site could still be exposed, simply because it runs on PHP. Versions as far back as PHP 5.4 are believed to be affected.
The timing made it worse. Technical details leaked online before the planned release, and the PHP Foundation brought its patches forward to Wednesday 21 October as a result. Proof-of-concept exploits were already circulating, and security firms reported attack attempts in the wild. For hosting providers, that meant no time to wait and see.
Wednesday: assess, mitigate, track
Morning: We started by understanding exactly what had leaked. The team researched the disclosed details, worked out the likely attack scenarios and planned mitigations for each one before they were needed. We began testing fixes straight away and adapted as new information emerged through the day.
We also set up a dedicated board to track every client. It covered mitigation status, patching, environments, client communications and which sites sat behind Cloudflare. With one live view of the whole estate, nothing could slip through the gaps.
Afternoon: By Wednesday afternoon, mitigations were live across all our clients, before patches were available for everyone. We monitored patch releases closely. As official patches landed for each PHP release, we applied them to the clients running it.
Thursday: building our own arm64 packages
Morning: By Thursday morning, most of the estate was patched. The exception was clients hosted on arm64 infrastructure, where official patched packages were taking too long to arrive. With exploits already circulating, we weren't prepared to leave those clients relying on temporary mitigations any longer than necessary.
So we built the packages ourselves:
Compiled arm64 PHP packages from the official PHP sources
Built them in clean containers, so nothing else could find its way in
Published them to a signed internal apt repository on our own mirror
Set them to be replaced automatically by the official packages as soon as those were released
The last point matters. Clients don't end up on a custom build forever. They move back onto the official release path without anyone having to remember to do it. We talked this through internally and kept clients informed before rolling it out.
Afternoon: The rollout completed on Thursday afternoon. With every server patched, we removed the earlier temporary mitigations. The whole estate was secure, roughly 36 hours after we started.
What our clients said
The best measure of how it went is what clients told us. Many of them are agencies, whose own customers came to them worried. They were able to say it was already handled.
“Thank you so much Nublue. Massive thank you for all your hard work over the past day on patching all the sites on our servers. Loads of clients contacted us and we were so pleased to say things were in hand already patched. We got lots of compliments, and I did say this is why we use Nublue as our hosting partner. Wishing you a very quiet evening and weekend!”
“You are ahead of other hosting providers of some of my clients who are still waiting. One of them actually implemented mitigations across all servers that completely stopped Magento 2 stores from processing orders - without any prior communication! Incredible.”
“Good work. Thanks! Verified all served today and they are the latest patched versions.”
“Dancing around my room !!!!!!!!!!!! Thanks so much team Nublue!”
What managed hosting should mean
Incidents like PHP2Shell are when the difference between hosting and managed hosting shows. Our clients didn't have to raise a ticket, chase an update or patch anything themselves. The week drew on everything we do day to day:
Security and incident response: assessing the threat and getting mitigations live before patches were available
Managed patching: applying official fixes across the estate as soon as they landed
Managed AWS: the engineering depth to build, sign and distribute our own packages when the official ones ran late
Clear communication: a live view of every client, and updates before they had to ask
A huge thank you to our team for an exceptional couple of days. Thank you too to our clients for their trust.
Want a hosting partner who's on it before you ask? Visit www.nublue.co.uk or email [email protected].