Update your PHP Docker image for php2shell

Only check systems you own or are responsible for.

Short answer

The fix is in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and the official php image uses the upstream version as its tag. Running docker pull does nothing for containers that are already running: you have to point your build at a fixed tag, rebuild your image, and recreate every container (web, queue worker, cron) from it. Then check php -v inside the running container.

Type your version into the checker or see the fixed-versions table for every branch.

What is being fixed

php.net’s security announcement says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution: CVE-2026-109618 and CVE-2026-109619, both rated CVSS 4.0 9.2. php.net says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. A container is not an exception: what matters is the PHP version inside the image.

Which official image tags carry the fix

Our registry check was on 21 Oct 2026 at 17:11 UTC (data last reviewed 22 Oct 2026). Earlier on 21 Oct, at about 16:35 UTC, the 8.5.12 and 8.4.27 tags existed with empty manifests, so this moved fast: treat the table as a snapshot, not a promise. The maintainers committed the update (“[security] Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35”) to docker-library/php; the live state is on the Docker Hub tag pages: 8.5.12, 8.4.27, 8.3.36, 8.2.35.

Two traps:

• Floating tags can lag. In the earlier 16:35 UTC check the 8.5 tag still ran 8.5.11 and 8.4 still ran 8.4.26; by 17:11 UTC both resolved to the fixed versions. A floating tag you pulled earlier, or a local copy, can still hold the old version. Do not assume a floating tag such as latest is fixed because it is “the newest”. Pin the full patch version and re-pull.
• An empty tag is not a fix. If a pull of your fixed tag fails or returns nothing, the image is not published yet (or you mistyped the variant). Wait and retry; do not fall back silently to an older tag.

PHP 8.1, 8.0 and 7.4 got no official image. php.net says the security team provided only minimal source backports (for example the PHP-8.1 branch) for people building from source. The practical fix is to move to a supported branch.

Step 1: Find what you are running

# the image each running container was started from
docker ps --format '{{.Names}}\t{{.Image}}'

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

Remember that queue workers, schedulers and one-off CLI containers often use the same image. Fix all of them.

Step 2: Change the tag, rebuild, push

In your Dockerfile, replace the floating tag with the fixed patch version:

# before
FROM php:8.4-fpm-alpine
# after
FROM php:8.4.27-fpm-alpine

If you build on top of someone else’s image (anything whose own FROM is a php image), you inherit their PHP version: check that image’s tags for a rebuild, or switch your FROM to a fixed php tag.

Rebuild without trusting your local cache, then push:

docker build --pull --no-cache -t registry.example.com/myapp:2026-10-22 .
docker push registry.example.com/myapp:2026-10-22

--pull refreshes the base image, which is the step docker pull alone never does for an already-built application image. Use a new, unique tag for each build so the deployment actually changes.

Pin digests (optional)

A tag can be re-pointed; a digest cannot. Once you have confirmed the fixed tag is published and runs the right version, record its digest and pin it:

docker buildx imagetools inspect php:8.4.27-fpm-alpine

FROM php:8.4.27-fpm-alpine@sha256:<digest-from-the-command-above>

Take the digest from a tag you have actually pulled, never from a tag that is still empty. Confirm with php -v after the build (Step 4).

Step 3: Roll out so containers are recreated

Docker Compose

docker compose build --pull        # if you build the image yourself
docker compose pull                # if the image comes from a registry
docker compose up -d --force-recreate

Kubernetes: set the new image tag in the Deployment (or your Helm values or manifest), then wait for the rollout. In the example, php is the container name in your pod spec; change it to match yours:

kubectl set image deployment/myapp php=registry.example.com/myapp:2026-10-22
kubectl rollout status deployment/myapp

kubectl rollout restart re-pulls a reused tag only when imagePullPolicy is Always; unique tags or digests remove that doubt. Repeat for every Deployment, CronJob and worker that uses the image.

Plain docker run: stop and remove the old container, then start a new one from the new image. Restarting the old container reuses the old image.

Back up volumes and databases before moving to a new PHP branch (for example 8.3 to 8.4); a patch bump inside the same branch is low risk, but a branch jump can change behaviour and extensions.

Step 4: Verify inside the container

docker exec <container> php -v
# Kubernetes
kubectl exec deploy/myapp -- php -v

The version should read 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher for your branch. Check the PHP-FPM or Apache container, not only a throwaway docker run. Then enter that version in the checker.

Alpine images and the apk PHP packages

Two different things share the name “Alpine”:

• Official php:*-alpine images: PHP version comes from the image tag. Use the table above, and confirm with php -v after pulling.
• A plain alpine image where you run apk add php84 (or php83, php85): you depend on Alpine’s own packages.

For the second case, Alpine’s security database for 3.24 lists these as fixed, and the 3.24 community package index now carries them:

On edge, the same versions are listed as fixed, but not every architecture had them yet: aarch64, armv7 and loongarch64 had them, while x86, ppc64le, s390x and riscv64 still listed the older builds. Distro packages can keep older version numbers because fixes are back-ported, so compare against the vendor’s fixed package version (the -r0 build in the table), not only the upstream number. Rebuild so the layer is not cached:

docker build --pull --no-cache -t registry.example.com/myapp:2026-10-22 .

In a running Alpine container you can confirm with:

apk update && apk list -I 'php84*'
php -v

Alpine 3.23’s community repository (where PHP lives) reached end of support on 2026-05-01 according to Alpine’s release data, yet Alpine’s security database and its 3.23 community package index list fixed builds there too: php85 8.5.12-r0, php84 8.4.27-r0 and php83 8.3.36-r0. Alpine 3.22 is in the same position (community support also ended on 2025-11-01) and also has fixed builds: php84 8.4.27-r0, php83 8.3.36-r0 and php82 8.2.35-r0. On Alpine 3.21 only php82 has a fixed build (8.2.35-r0); for the other older releases (3.21 php83 / php84, 3.20) we list no fix, because Alpine’s security database names no fixed build for them (the 3.21 package index does now carry a newer php83 build, but the security database does not list either CVE for it). Alpine 3.24’s community support runs to 2026-11-01. On 3.23 and 3.22 run apk upgrade and check the installed version; if you are on an older release, move to 3.24, or switch to an official php image tag.

Still unsure?

Compare what php -v printed in the running container against the fixed-versions table, or check whether your host or panel has shipped its fix on the hosting status page.

If you would rather have someone map your own Dockerfile, Compose or Kubernetes setup: a $49 personal patch plan gives you written steps for your exact setup by email within 24h. See /fix-service/.