Patch guide

How to patch PHP2Shell in Docker images and Kubernetes

Short answer

Containers don’t patch themselves. Check PHP in each running container with docker exec <name> php -v, rebuild your images with docker build --pull --no-cache on a fixed base (e.g. php:8.3-fpm with 8.3.36+), redeploy every service, then verify the version inside the new containers.

On this page

Why containers need special attention

A container keeps the PHP it was built with. Upgrading the host does nothing for it, and an image built last month still contains last month’s PHP. You have to rebuild and redeploy — and Google Cloud’s guidance is to verify the running version afterwards, not just the build.

1. Find PHP in your running containers

docker ps --format '{{.Names}}\t{{.Image}}'

# PHP version inside a running container
docker exec <container> php -v

To check an image before deploying it:

docker run --rm --entrypoint php <image> -v

Any 8.5 below 8.5.12, 8.4 below 8.4.27, 8.3 below 8.3.36, 8.2 below 8.2.35, or any 8.1 and older is vulnerable — see fixed versions.

2. Rebuild on a patched base image

Official php images

Floating tags such as php:8.3-fpm or php:8.4-apache are rebuilt when a new PHP release ships. Force Docker to pull the new base and rebuild every layer:

docker build --pull --no-cache -t myapp:php2shell-fix .

To make builds reproducible, pin the exact fixed release in your Dockerfile once that tag is published:

FROM php:8.3.36-fpm

Then confirm what you got:

docker run --rm --entrypoint php myapp:php2shell-fix -v

Images that install PHP from a distribution

If your Dockerfile installs PHP with apt-get, dnf or apk, rebuilding with --pull --no-cache fetches the patched packages. Distribution packages may keep an old version number — check the changelog inside the image (see distro backports).

FrankenPHP and other bundled runtimes

FrankenPHP embeds PHP in its binary. Update to a FrankenPHP image or release built against a fixed PHP version, and check the PHP version it reports.

3. Redeploy everything

# Docker Compose
docker compose build --pull --no-cache
docker compose up -d

# Kubernetes — after pushing the new image tag and updating the deployment
kubectl rollout restart deployment/<name>
kubectl rollout status deployment/<name>

Use a new image tag (or digest) rather than overwriting an old one, so every node actually pulls the patched image.

4. Verify the running containers

docker exec <container> php -v
kubectl exec deploy/<name> -- php -v

Want CI to stop vulnerable images from shipping? The CLI reference shows a GitHub Actions step that fails the build if the image’s PHP is vulnerable.

Managed container platforms

  • Google Cloud Run and Cloud Run functions: patched automatically only if automatic base image updates are enabled; otherwise rebuild and redeploy.
  • App Engine standard (PHP 8.2+): patched by Google; App Engine flexible and custom runtimes need a redeploy.
  • GKE, ECS, AKS and self-managed Kubernetes: your responsibility — rebuild, push and roll out.

After patching

Containers are often rebuilt from scratch, which removes web shells planted in the filesystem — but stolen secrets stay stolen. Rotate credentials your PHP services used and review logs from 17 October onward. Compromise checklist.

Running a larger fleet? Get help scoping the rollout.

Shayan Abbas writes these PHP security guides from the official advisories and vendor guidance listed below, and updates them when those change. About this site

Sources

  1. Google Cloud — Responding to core PHP vulnerabilities (containers, Cloud Run, GKE)
  2. Qualys — PHP announces critical security release (check containers and bundled copies)
  3. Docker Hub — official php image

Know about the next critical PHP bug first

Short, plain-English alerts when a serious PHP vulnerability or fix lands — with what to patch and how. About two emails a month.