PHP2Shell in Docker: Rebuilding PHP Images So the Fix Actually Ships

By Umair Ali Sadaqat · Updated · Editorial policy

A container keeps the PHP it was built with until you rebuild and redeploy it. How to find every PHP image you run, move pinned tags to fixed releases, rebuild without stale layers and prove production has the patch.

Containers make PHP updates repeatable, and they also make it easy to believe you have updated when you have not. Updating the host does nothing for PHP inside a container. A new upstream image does nothing until you rebuild your image from it and replace the running containers. Here is how to make sure the Black October fixes reach production.

1. Find every PHP image you run

List what is actually running, not what your repository says:

``bash docker ps --format '{{.Image}}\t{{.Names}}' kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u ``

Include sidecars, cron and queue worker images, and any image built from a PHP base for tooling that also serves HTTP. Then check each one:

``bash docker exec <container> php -v ``

The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (and later in each line).

2. Fix pinned tags

Look at the FROM line in each Dockerfile:

  • php:8.3.30-fpm (patch pinned) will never receive the fix. Change it to php:8.3.36-fpm or later.
  • php:8.3-fpm (branch tag) moves to new patch releases, but only when you pull and rebuild.
  • A digest pin (@sha256:...) is frozen by design. Update the digest to one built on a fixed release.

For images from other sources (Bitnami, distribution-based images, FrankenPHP), check that publisher's tags and notes. The advisory lists FrankenPHP among affected setups, so FrankenPHP images need an update too.

3. Rebuild without stale layers

Docker caches layers, and a cached base layer can quietly keep the old PHP:

``bash docker build --pull --no-cache -t myapp:php-fixed . ``

--pull fetches the newest base for your tag; --no-cache stops old layers being reused. In CI, make sure the build runner is not reusing a cached base image either.

4. Redeploy and replace every container

Push the new image and roll it out. Then confirm no old container survived: rolling updates can stall, and some orchestrators keep old replicas when a health check fails.

``bash kubectl rollout status deployment/<name> kubectl get pods -o wide ``

Run php -v inside a running production container to confirm the version. For a check that reflects real requests, read the runtime version from your error tracker or APM.

5. Images built from source

If your Dockerfile compiles PHP (common for slim custom builds), update the source version or tarball checksum and rebuild. If you are on an end-of-life branch, see the old PHP versions guide for the PHP team's backport branches.

Temporary measures in containers

If you need the stopgap settings from the mitigation guide, bake them into the image's php.ini or pool config rather than mounting an override at runtime that someone might forget. Containers also make one of the PHP team's suggestions easy: a per-container memory limit, so a worker that misbehaves is killed without taking the host down. Do not use RLIMIT_AS or RLIMIT_DATA for this; the advisory warns they can trigger the bug.

Keep it from happening again

  • Rebuild PHP images on a schedule, weekly or at least monthly, even when your code has not changed.
  • Use an image scanner in CI so a known-vulnerable PHP version fails the build.
  • Keep base image tags at branch level and record the resolved digest at build time, so you get updates on rebuild and still know exactly what shipped.

After patching, run the compromise checklist against any container that holds persistent data, such as uploaded files on a volume.

Move your site to WeInc

If a container pipeline for a marketing site is more than you want to maintain, a hosted builder takes the runtime off your plate. Move your site to WeInc: first month free with code BLACKOCTOBER, until November 21, 2026. New customers only. Claim the offer

More in Blog

Related guides and tools

Start building

How we research, test and update this page: our editorial policy. We.Inc is our own product.

Product

Who It's For

Features

Resources

Company

View Sitemap