How Sevalla Responded to PHP2Shell in Less Than 24 Hours

When a critical runtime vulnerability hits, publishing an advisory is only the beginning.

At 14:00:57 UTC on October 21st, 2026, the first official patched PHP release announcement disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Collectively known as PHP2Shell, they created an urgent patching problem for teams running PHP applications in production.

Within an hour of the first official patched PHP release announcement, Sevalla had published mitigation guidance.

Within hours, we contacted every company running a PHP application and tracked patched releases across every PHP build and strategy Sevalla supports.

Before 24 hours had passed, our team proactively redeployed affected running applications so customers didn't have to handle every update themselves.

Here is how it happened.

October 21st: Respond before every patch is available#

14:57 UTC

Sevalla published a security advisory with PHP settings designed to make exploitation harder across every supported build strategy.

At that point, patched PHP releases were not yet available through all upstream sources used by Sevalla's different deployment methods.

Waiting for every patch to arrive was not an option.

The immediate priority was to give customers practical mitigation steps while we tracked the patched releases as they became available.

15:58 UTC

Heroku published the patched PHP releases.

Applications using Buildpacks could upgrade by deploying again.

16:24 UTC

Sevalla emailed every company running a PHP application.

Customers did not have to discover the issue themselves. We contacted the companies we knew were running PHP and pointed them directly to the advisory.

16:56 UTC

Docker Hub published patched versions of the official PHP images.

Dockerfile applications could upgrade with a new deployment. Applications with a PHP version pinned in the FROM line could update that version before redeploying.

17:59 UTC

FrankenPHP published patched images.

That gave Railpack applications, along with Dockerfile applications based on dunglas/frankenphp, a path to the patched release through a new deployment.

By the end of October 21st, Sevalla had patched releases available for most PHP deployment paths it supports.

October 22nd: Every Sevalla build strategy had a patch path#

05:32 UTC

Sevalla’s Nixpacks builds began installing the patched PHP releases.

At that point, every supported PHP build strategy on Sevalla had a path to a patched release.

Customers could redeploy applications without the build cache to upgrade PHP.

We could have stopped there.

We didn’t.

We started redeploying affected applications ourselves#

06:28 UTC

The Sevalla team began proactively redeploying running PHP applications using affected releases. We performed these deployments without the build cache to ensure updated PHP packages and images could be fetched. Those deployments were performed without the build cache so the patched PHP release would be installed.

Applications without a running instance were not included in this first pass.

By this point, less than 16 hours had passed since Sevalla published its initial advisory.

15:03 UTC

The team then expanded the response to hibernated PHP applications running affected releases.

The team also redeployed those applications without the build cache.

Suspended applications were not redeployed.

Not every application could be patched through a proactive redeployment. Some configurations required customers to make changes themselves, and we contacted affected customers with guidance on the next steps. Suspended applications were also excluded from the redeployment process.

In roughly a day, Sevalla moved from mitigation guidance to customer notification, patched support across every build strategy, and proactively redeployed affected workloads.

The important part wasn’t the advisory#

A security advisory tells you there is a problem.

It still leaves someone with work to do.

Your team may need to determine which PHP release you’re running, how your application gets that runtime, whether the upstream image or buildpack has been updated, whether your build cache will preserve the vulnerable version, and which applications need to be redeployed.

Across multiple production applications, that can quickly turn into a significant operational task.

With PHP2Shell, Sevalla designed its response to reduce that burden.

We tracked the upstream releases.

We made sure each supported PHP build strategy had a path to the patched version.

We identified running applications using affected releases.

Then we started redeploying them.

This is what removing infrastructure work looks like#

Security incidents are part of running production software.

Your development team should understand the risk. You need clear information about what is affected. And you need confidence that the underlying platform is responding quickly.

Your team shouldn't have to spend the day watching Buildpacks, Docker images, FrankenPHP releases, Railpack, and Nixpacks to figure out when it is safe to redeploy.

That is infrastructure work.

Sevalla is built to take as much of that burden off development teams as possible.

PHP2Shell gave us a chance to put that into practice.

We didn’t just publish an advisory and wait.

We responded, communicated, tracked the fixes, and started updating affected production workloads.

Because running production applications will always come with infrastructure problems.

You shouldn't have to manage every one of them yourself.