How We Handled a Critical PHP Security Release Across 100+ Environments

I coordinated Redberry’s response to the critical PHP security release on 21 October. Early in the day, the hardest question was how far our responsibility extended across the systems we had helped build.

The obvious starting point was our 30 ongoing client engagements. Our delivery teams work on these systems every day. Where we managed the infrastructure, we handled the update ourselves. Where the client owned it, we alerted their team and remained available to assist.

But this was not all. The response also reached back into years of completed work and relationships with former clients. Many of those systems were still live and important to the businesses using them. Our contracts might have ended, but we knew the applications and the people relying on them. For each one, we had to consider whether the client had a dedicated infrastructure team, whether someone was already handling the update, and where our involvement could make a difference.

That made the response larger than our active project list. It brought together current delivery teams, DevOps, project managers, engineers familiar with earlier engagements and client infrastructure teams, all working towards the same urgent update through different deployment paths.

What did the PHP release require us to respond to?

The PHP release addressed two critical vulnerabilities in the runtime used by our Laravel applications. CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2, could allow unauthenticated remote code execution. PHP published fixed releases for its supported branches: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Official PHP advisory.

We had advance notice of the release. That gave us time to prepare, but the patched runtimes and images still had to become available through the platforms we used. During that window, we needed people ready to act and clients ready to make decisions.

That meant looking beyond production websites. Our developer-wide instruction covered staging, development, prerelease and other environments, along with queue workers and schedulers running separately from the web application. Internal products were part of the same exercise.

How far did our responsibility extend?

We considered our relationships, the importance of the systems still running and the client’s ability to respond, alongside our contractual responsibilities.

We reviewed 121 client engagements dating back to 2022, including the 30 still ongoing. We needed to establish where we still operated infrastructure, which systems remained live and important, and who was equipped to respond.

For a former client with an established infrastructure team, the useful intervention could be a direct warning and an offer of assistance. Where a critical system was still live and responsibility was less clearly covered, we needed a closer conversation about who could act. A contractually completed engagement could not answer either question.

We decided to act in 57 cases. In 27 of those, we had no contractual obligation to do so. Depending on the situation, acting meant notifying the client, offering our help, coordinating with the responsible team or taking on the patching work ourselves. The relationship and the importance of the running system informed that decision.

How did we turn that responsibility into action?

We assigned technical execution according to infrastructure ownership and kept a named coordinator for each client relationship.

Nine of our active engagements ran on client-managed infrastructure. For those, we notified and coordinated with the client’s responsible team, which owned the update.

Our own patch rollout covered the other active engagements and six projects for former clients. That brought our patching scope to 27 projects: 12 on Laravel Cloud and 15 on custom infrastructure stacks.

Our DevOps lead together with our CTO and architects owned the custom infrastructure work. A separate lead coordinated the Laravel Cloud applications. Project owners coordinated client communication and brought in the relevant engineers or external infrastructure teams.

On projects where we managed the infrastructure, we updated every environment. This included production, staging, development, prerelease and any others in use. We then verified that each application ran correctly on the patched runtime. For client-managed infrastructure, we notified the responsible team, explained the urgency and remained available to assist.

That division let teams move in parallel. DevOps could prepare the container rollout, the Cloud lead could follow Laravel’s updates, and project teams could reach the clients whose infrastructure decisions we could not make ourselves.

We prepared separate client notices for Cloud, custom infrastructure stacks and client-managed systems. Mixed infrastructure management arrangements needed tailored communication so that automation on one part of an engagement did not imply the rest was covered.

What did we do while waiting for patches?

We worked with existing clients to decide which systems and environments needed to be taken offline for a temporary security maintenance window before we could patch them.

Those were operational decisions with a business consequence. Taking a live system down interrupts people using it. Leaving an exposed system running while waiting for a deployable fix carries a different risk. We had to agree on the precaution for each affected system, explain the interruption and coordinate the work needed to bring it back.

The same decision did not apply uniformly across the portfolio. Infrastructure management arrangements, available protections and the path to a patched runtime differed. Some applications required a planned interruption; others could receive the update through the infrastructure platform. The client needed a clear account of what would happen to their system.

These conversations were part of the response from the outset. They made it possible to act deliberately while the technical teams were still waiting for the artifacts they needed.

What difference did our Laravel relationship make?

Our direct contact with Laravel helped us keep the response aligned with changing platform guidance throughout the day.

As a Laravel Premier Partner, we were in direct communication with the Laravel team through private partner Slack channels. We could follow their updates as the response developed and adjust what we were asking our own teams to do. The distinction between automatic patching, server updates and custom-image rebuilds had immediate consequences for our plan.

Cloud made the largest practical difference. Twelve of the projects in our patching scope ran on Laravel Cloud, including two for former clients. Laravel handled their runtime patching automatically, removing the need for us to rebuild and redeploy each application manually.

That changed the work assigned to our Cloud lead: follow the provider’s rollout, keep project teams informed, and coordinate application checks afterwards. We still owned the client relationship and verification of the applications we maintained.

Alongside those 12 Cloud projects, we had 15 projects on custom infrastructure stacks requiring our teams to handle the runtime updates and deployments. Every application patched by the platform reduced the manual execution we needed to coordinate alongside the remaining rebuilds, server updates and client conversations.

Thank you to the whole Laravel team for how you handled this. The communication throughout the day mattered, and Cloud’s automatic patching made a difficult rollout considerably more manageable for our team and clients.

What did patching the custom infrastructure involve?

The custom infrastructure stacks required us to update the PHP runtime through each project’s deployment path, covering both container-based and server-based workloads.

For our container stack, updating PHP on the host would not replace the PHP runtime packaged inside an application image. The work therefore followed the runtime through the deployment chain: obtain the patched base image, rebuild the application image, release it, replace the running services and check the deployed runtime.

Build caching and release identity mattered here. A successful build alone would not establish that it had picked up the patched base. Equally, publishing a new image would not establish that every service had started using it. Our verification needed to cover both the artifact and the running workload.

Web services, queue workers and schedulers were all part of that deployment coverage. Restarting the web service while leaving a separately deployed worker on the previous image would leave the rollout incomplete.

Server-based workloads needed a different treatment. We had to account for each server’s operating system, installed PHP branches, package availability and processes. Some applications also required maintenance coordination because their deployment arrangements differed.

The common requirement was to verify the runtime actually serving the application, then check application behavior. The update mechanism depended on the stack.

Why did supported PHP versions make the response easier?

Keeping the projects we maintain on officially supported PHP versions gave us an established security-update path when the release arrived.

That is our maintenance policy, and this response demonstrated its practical value. On supported branches, the immediate task was to apply the relevant security release and validate it. We could keep emergency patching separate from a larger compatibility upgrade.

PHP’s supported branches at the time were 8.2 through 8.5. Older branches were outside normal upstream support, although vendors could provide backports and PHP supplied exceptional minimal source patches for 7.4, 8.0 and 8.1. An older installation therefore needed its patch route assessed individually. PHP support policy · Security advisory.

The operational benefit of staying current is having fewer decisions to make under pressure. Where a reliable fix cannot be deployed promptly, exposure must be addressed through isolation or taking the service offline while remediation is arranged. Routine version maintenance reduces the likelihood of facing that choice during an emergency.

How did we bring the day to a close?

By midnight at Redberry in Georgia, roughly six hours after the patched PHP releases became available, we had coordinated and verified patching across more than 100 environments in 27 projects. All were patched and live. Every precautionary shutdown had ended: the temporary security maintenance windows were closed, and those systems were back online. All relevant clients and former clients had been notified.

Getting there meant closing both the technical work and the communication. For infrastructure we managed, completion covered the applicable environments, the deployed runtime and application checks. Where clients managed the infrastructure, we coordinated with their responsible teams and recorded the outcome. Sending a notice was tracked separately from technical verification.

Teams could act within their own responsibilities while keeping the overall response visible. That let us bring together the work happening across different platforms and client organizations and know when our agreed scope was complete.

It was a difficult, long day. A huge thank you to the Redberry team: the developers, DevOps and project teams who handled the deployments, checks and client conversations through to the finish. The midnight outcome depended on that collective effort.

Thank you also to the PHP maintainers for the fixes and to the Laravel team for helping the ecosystem respond. For us, the day showed how much responsibility can remain attached to software long after its original delivery, and how much clear ownership matters when all of those systems need attention at once.