Updating PHP in Docker: fixed image tags, rebuilds and rollouts

Pinning

Fixed tags, floating tags and digests

How you name the base image decides whether a rebuild picks up a fix on its own, and whether you can tell afterwards what you shipped.

# Floating: whatever 8.3 release was newest when the image was last built
FROM php:8.3-fpm

# Fixed release: the Dockerfile records exactly what you ship
FROM php:8.3.36-fpm-trixie

# Fixed image: identical on every build until you change the digest
FROM php@sha256:<digest of the image you tested>

• Floating tags such as 8.3-fpm only help if you rebuild. An image built last month on 8.3-fpm still holds last month's PHP, whatever the tag points at today.
• Full version tags make the change visible: a one-line diff from 8.3.35 to 8.3.36 is easy to review and easy to search for across repositories. Docker's documentation still treats every tag as mutable, because a publisher can point it at a new image.
• Digests are the only reference that never changes. Docker's documentation notes the trade-off: you opt out of security fixes until you change the digest yourself. Kubernetes' documentation advises against the latest tag in production for the same reason of traceability, and suggests a meaningful tag, a digest or both.

Docker Compose

For services with a build: section, rebuild with docker compose build --pull, then run docker compose up -d. For services that run a published image directly, pull first:

# Services that run a published image directly (image:, no build:)
docker compose pull
docker compose up -d

docker compose restart is not a substitute: it restarts the existing containers on their existing image.

Kubernetes

A Deployment rolls out new pods only when its pod template changes, for example a new image reference. Re-pushing the same tag changes nothing, and with any tag other than latest the default pull policy is IfNotPresent, so a node can reuse its cached copy of the old image.

# Point the Deployment at the rebuilt image, under a new tag
kubectl set image deployment/my-site php=registry.example.com/my-site:2026-10-27

# Watch the old pods being replaced
kubectl rollout status deployment/my-site

# Return to the previous revision if the new image misbehaves
kubectl rollout undo deployment/my-site

Red Hat's guidance for these flaws says the same thing in one line: replace the running container or pod.

Other orchestrators and hosted container platforms follow the same rule: deploy the new image reference, then check that no instance is still on the old one. Remember jobs and scheduled tasks that start from a PHP image only now and then; they pick up whatever image their definition names.

Distribution-based images

Images that install PHP from a distribution

Some Dockerfiles skip the official php image and install the distribution's PHP instead. The official image's documentation points that way for anyone who wants Debian's PHP packages: start from a Debian image and install them directly.

FROM debian:trixie-slim
RUN apt-get update && apt-get install -y php8.4-fpm

In an image like this, the fix arrives as the distribution's security update, under the distribution's own version number. On Debian 13 the fixed package is 8.4.27-1~deb13u1; on Ubuntu 24.04 it is 8.3.6-0ubuntu0.24.04.13, a backport that keeps the older upstream number. The Linux guide has the table for each release.

Defeat the build cache

Docker's documentation notes that the cache for a RUN step is not invalidated automatically between builds: it matches on the command text, and an apt-get install line does not change when a security update is published. A plain rebuild can therefore produce an image with the old packages. --no-cache runs every step again, and --pull refreshes the Debian base. Keep apt-get update and apt-get install in the same RUN line, as Docker's own guidance recommends.

# --no-cache reruns apt-get, so the fixed packages are fetched
docker build --pull --no-cache -t registry.example.com/my-site:2026-10-27 .

# Check the exact package versions inside the new image
docker run --rm registry.example.com/my-site:2026-10-27 dpkg-query -W 'php8.4*'

Confirm it worked

Check the PHP inside the container, not the Dockerfile

A Dockerfile says what you meant to ship. The container says what is actually serving traffic.

# A running container (container name)
docker exec my-site php -v

# A Compose service (service name)
docker compose exec php php -v

# A freshly built image, before it goes live
docker run --rm registry.example.com/my-site:2026-10-27 php -v

• Official image: the command line PHP is compiled in the same build as the image's FPM or Apache module, so php -v reports the release the container serves. Expect 8.5.12, 8.4.27, 8.3.36 or 8.2.35 for your branch.
• Distribution image: the command line and the web server's PHP come from separate packages, so check every PHP package with dpkg-query -W and compare each version with the distribution's advisory.
• Container age: in docker ps, the CREATED time of each PHP container should be later than your rebuild.
• From the outside: read the version the website itself reports, as described in how to check your PHP version, for at least one site per image.
• The registry: list the tags that could still be deployed, and delete or rebuild those on vulnerable releases.

On 26 October 2026 CISA added both CVEs to its Known Exploited Vulnerabilities catalogue. A replaced container starts clean, but data volumes, databases and anything the old container could reach do not. Signs a PHP site was compromised