What was our approach to mitigating risk with PHP2Shell?

PHP security risks: Key information

The PHP Foundation has disclosed two critical software vulnerabilities and issued an emergency patch that needs to be implemented immediately. They recommend taking down websites temporarily if they cannot be patched right away. 

Vulnerabilities:

CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)

The PHP Foundation’s update and further information on the patch required can be found here: https://www.php.net/archive/2026.php#2026-10-21-5 

As of writing this, we’re recovering from pulling an all-nighter after going through the biggest cyber security incident to ever take place that didn’t actually result in any successful hacks (yet). 

With millions of websites potentially exposed, developers and security teams around the world were racing to protect their systems before attackers could exploit the vulnerabilities.

How did PHP trigger a worldwide security scramble?

In August, cyber security firm Wiz found serious flaws in PHP, alongside researchers at Calif and OpenAI. The PHP Foundation was responsibly informed in secret, and began working on patched versions ready for late October. 

Initial details were leaked on Tuesday 20th October by unknown actors, which were then unfortunately corroborated by Calif themselves, when they accidentally posted a video showing basic details of how the flaws could be used to hack various websites.

The video was taken down, but not before it was shared widely online, leading to hackers trying to figure out how the vulnerabilities could be exploited. 

This forced an emergency news post in response on PHP.net, revealing patches would be released on Wednesday 21st October. The internet exploded with conjecture and the reports started coming in of increased attacks, with evidence from Amazon Threat Intelligence and Cloudflare of the vulnerability being exploited in the wild.

As word spread of the vulnerabilities online, opportunistic attackers immediately started trying to exploit it. The risk is that these security flaws can allow unauthenticated remote code execution, meaning attackers can run malicious code to gain control of systems. 

At-risk websites would be exposed to ransomware attacks, data breaches and operational disruption without patching.

What was our approach to mitigating risk with PHP2Shell?

Thanks to the way the news broke about the vulnerabilities, we had some time to prepare in advance. We immediately started internal discussions, quickly realised what the implications would be - that we would need to update every single one of our clients' websites in a short timeframe - and began planning the rollout across all projects.

Our approach

The PHP Foundation shared a set of config changes that could be made in the interim to help protect against any attacks, which meant we could get started within minutes of analysing the announcement, rolling out interim config changes across all sites, whilst waiting for supply chains to rebuild against new PHP versions.

Within four hours, Linux had built and tested entire operating systems with the PHP packages included, and released them for use. At that point we halted interim fixes and switched across to building the new packages, whilst reversing any interim fixes that were no longer required. 

We continued throughout the night to ensure all of our clients’ sites were protected against any attacks, and around 12 hours after the Linux images were released, we had finished.

Risk mitigation

Our core strategy was to have different risk mitigation tactics available to us and our clients so we could work together to choose the best approach.

Thanks to AWS and Cloudflare’s proactivity we could avoid this for some clients, and for other sites we assessed whether some quick changes could be made to mitigate risk, such as WAF configuration changes. Shutting down websites remained an option if either we or our clients felt the risk was too high.

Security doesn't stop when a website goes live

Incidents like this demonstrate just how quickly vulnerabilities can put business-critical websites and services at risk, and why ongoing maintenance, monitoring and the ability to respond quickly are so important.

If you're concerned about how these vulnerabilities might affect your website, or need advice on protecting your systems, get in touch with our team.