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.