fidzu : php

On Tuesday 20 October (Wednesday morning in Australia), the PHP Foundation announced the pending release of fixes for two critical security vulnerabilities in PHP, the language Drupal is written in.

The release was scheduled for 14:00 UTC, which would be 1am for us. This post details how our team prepared and handled the rollout of this release to our clients' sites.

Lurking in plain sight

The PHP security release was for bugs that had sat unnoticed for more than a decade before security researchers found them with the help of AI. The exploit needed multiple steps to reproduce, which previously made it very difficult to detect. AI makes that much easier.

This reflects a bigger shift in cybersecurity. AI is now being pointed at decades of existing code and turning up serious flaws faster than open source security teams have had to deal with before. While the headlines have been about PHP this week, other open source projects are experiencing a similar increase in security reports.

PHP's maintainers were following established security practices and had planned a coordinated release with the researchers who found the flaws. They were forced to bring the release date forward by a day when it was undermined by someone leaking details during the embargo period. The PHP Foundation has been candid about how it unfolded, and it's a reminder that how quickly you respond now matters as much as the code you run.

The day before the update

Our team learned of the PHP critical security release about 17 hours before the planned release. We immediately formed a war room to plan our approach and start communicating with our clients.

That made this the highest priority for PreviousNext. Every site we build runs on PHP, as does every site on Skpr, our managed Drupal hosting platform. We worked together to come up with a planned approach to the deployment including:

• Identifying if we could block exploits using web application firewall (WAF) rules

• Planning how to update PHP in application containers without rebuilding them from scratch

• Planning for what would happen if build and deployment services like GitHub Actions or CircleCI weren't available due to increased load

• Preparing to block all traffic to the origin (PHP servers) at the content delivery network (CDN) layer while the updates were being built and deployed - following advice from CERT-EU and cyber.gov.au.

We drafted tailored communications to our clients and then our delivery team worked to get each client's approval in advance to deploy the update overnight, and permission to block traffic while the updates were being built and deployed. Clients hosted on their own providers received a message specific to their setup, and what we'd need to coordinate with their host. Every client also had access to immediate updates via our ticketing system as the situation developed.

We weren't working in isolation. Members of our team sit on the global Drupal Security Team, the group that coordinates security for the entire Drupal project, which gave us a direct line into how the best Drupal teams in the world were handling the same problem. We were also in conversation with team members at GovCMS sharing updates as we saw them.

As a Top Tier Drupal Certified Partner, and with Skpr a hosting partner in Drupal Steward, the Drupal project's security program for hosting platforms, we were in close contact with the Drupal Association throughout the incident. With plenty of patchy information doing the rounds on social media, having a direct line to accurate information was vital.

While our delivery managers were communicating with clients, our Platform team was preparing for the release. Our Platform Lead, Nick Schuch, built a tool to scan every container on every hosting cluster and report the PHP version. He also built a tool to apply the PHP update without needing a complete rebuild of the container.

At the same time, our Platform Engineer, Nathan ter Bogt, confirmed that protections baked into Skpr, such as read-only file systems, designed to prevent writing to running containers and execution of PHP by malicious actors. Nathan also prepared the firewall rules and holding page we'd use if we had to block traffic.

At release time

The PHP release was made 20 minutes earlier than scheduled, at 12:40am, likely because there were reports of exploits already being used. Our team was already online and it was all hands on deck, with the team working through the plan we'd mapped out the previous afternoon.

Several things happened at once: Nick started building new PHP packages from the official release while Nathan checked whether firewall rules or a PHP configuration change could block the attack. The two PHP advisories (CVE-2026-109618, CVE-2026-109619) made it clear that patching was the only effective mitigation, so we decided to block all traffic and display planned maintenance pages. Our delivery team stayed in contact with our clients' internal teams to let them know we were taking this step.

Once the new packages were built, Nick used our custom tooling to rebuild the application images for each client site and deployed them. Then we started manually checking each site to make sure it was working as intended.

In practice the process was more complex than we'd anticipated. With thousands of developers deploying fixes at the same time, GitHub slowed right down, which was one of the scenarios we'd planned for.

Real incidents rarely run to the minute, and the team saw it through to the end. By 3:54am the process was complete and every site was secure.

Wrapping up

For our clients, the most important part of Wednesday wasn't the technical work. It was knowing what was happening at every step, from the moment the vulnerabilities were announced to the confirmation that their site was patched. Nobody woke up on Thursday to find their site had gone dark without warning, and nobody had to chase us for an update. That only works when the communication plan is treated as seriously as the technical one.

Preparation and tooling are what make a 1am response calm rather than chaotic. A team that already knows exactly what's running on every server, and has the tools to patch all of it at once, can spend the night making good decisions instead of scrambling. That comes from a senior team with decades of combined Drupal experience, and from running our own hosting platform where we control every layer of the stack. A smaller organisation relying on shared hosting, or an agency without its own platform, faced a much harder night.

While this was a genuinely critical threat, it doesn't change our view that PHP and Drupal are a secure and stable choice. No technology is immune to what happened this week, and the next headline could just as easily be about Java, Python or JavaScript. What protects an organisation is the team behind its platform and how quickly they can act. With AI now writing code and helping attackers find holes in it, having experts on call 24/7 is fast becoming a basic requirement for anyone running a critical website.

We unfortunately expect more nights to come like Wednesday, but our team will be equally ready for them. If you're responsible for a critical website, it's worth asking your current provider a few questions. When did they first contact you about this vulnerability? What was their plan if attackers moved before the fix? And what time was your site patched? If their answers are anything less than confident, feel free to have a chat with us.