Which php: Docker image tag is patched for PHP2Shell?

Short answer

In the official php image on Docker Hub, the PHP2Shell fixes (CVE-2026-109618 and CVE-2026-109619) are in the tags for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Those are the versions php.net released on 21 October 2026 to fix both bugs.

A tag that names an older patch version, such as php:8.2.34-apache, runs PHP 8.2.34 and does not include the fix. Moving tags such as php:8.2-apache or php:8.4-fpm now point at the fixed builds, but a server only gets them when you pull and rebuild.

On a patched tag you still have one setting to check: php.net's 23 October advice on session.upload_progress.enabled. See One more setting, even on a patched tag.

The official image has no 8.1 or older tag in its current build list. See PHP 8.1 and older below.

Patched tags, by branch

These are from the official image's build list, read on 24 October 2026. Each line is built on Debian trixie and Debian bookworm, and on Alpine (3.24 and 3.23) for the cli, fpm and zts variants. There is no -apache tag on Alpine.

The zts variants follow the same version numbers (for example php:8.4.27-zts).

php.net says every PHP install that serves web requests is at risk, including Apache with mod_php and PHP-FPM. The -apache image runs PHP as mod_php, which php.net rates as the highest risk. The -cli image is not meant for running a web server, but it is the only variant that ships php-cgi, and php-cgi is also on php.net's at-risk list.

Check the version inside your running container

The tag in your Dockerfile tells you what you built from. What matters is what is running now.

1. Find the container: docker ps

2. Read the PHP version inside it:

   docker exec <container> php -v

3. The official image also records the version it was built from in an environment variable:

   docker exec <container> printenv PHP_VERSION

4. With Docker Compose, use the service name: docker compose exec <service> php -v

Compare the first line with the table. On the official image, 8.2.35 or newer on the 8.2 branch has the fix, and 8.2.34 does not. The same rule applies to 8.3 (8.3.36), 8.4 (8.4.27) and 8.5 (8.5.12).

That rule only holds if your PHP comes from the official image. Every official php variant puts PHP at /usr/local/bin/php and sets PHP_VERSION. Check both:

docker exec <container> which php
docker exec <container> printenv PHP_VERSION

If which php shows a different path, or printenv PHP_VERSION prints nothing, your PHP was installed some other way, usually from the distro's packages. Read the distro section instead.

Rebuild on a patched tag

1. Change the tag to a fixed one on the same branch, so your extensions and code keep working. In a Dockerfile:

   # before
   FROM php:8.2.34-apache
   # after
   FROM php:8.2.35-apache

   Keep the same variant (-apache, -fpm, -alpine, -bookworm). Changing the variant changes the base system or the web server setup, not just PHP.

2. Get the new image. Which command depends on how your app is built.

   • Plain Docker with a Dockerfile. --pull makes Docker fetch the base image again instead of using the copy it already has:

     docker build --pull -t myapp .

   • Compose, service has a build: section (your own Dockerfile on top of php):

     docker compose build --pull
     docker compose up -d

   • Compose, service uses image: php:... with no build: section. There is nothing to build, so docker compose build won't fetch a new PHP. Change the tag in compose.yaml if it's pinned (for example image: php:8.2.34-fpm to image: php:8.2.35-fpm), or keep the moving tag, then:

     docker compose pull
     docker compose up -d

   docker compose up stops and recreates a container when its image changed, so the old PHP processes stop.

3. Re-check with docker exec <container> php -v and confirm the new version. Do this on every server and every service that runs the image, including queue workers and cron containers.

4. Push the new image to your registry and redeploy, if your hosting pulls images from one. A rebuild on your laptop doesn't change what runs in production.

One more setting, even on a patched tag

This applies after you move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, not only if you can't rebuild.

On 23 October php.net published an informational advisory about a separate, unlikely attack path (CVE-2026-115560). php.net is handling it in the regular release cycle and suggests setting session.upload_progress.enabled=0 "until the next regular bugfix release". The 21 October versions came before that release, so the advice covers the patched tags too.

php.net says it can only happen when all of this is true:

• your PHP config sets session.serialize_handler to php_binary or php_serialize;

• your app switches it to php at runtime with ini_set() before calling session_start();

• session upload progress is still enabled.

If your app never changes the serialize handler at runtime, php.net says you can keep upload progress on. If you're not sure, or you don't use upload progress, turn it off. If you already set it after the 21 October advisory, keep it.

Set it in PHP's config files, not with ini_set() or .user.ini. In the official image, PHP reads extra settings from $PHP_INI_DIR/conf.d/ (/usr/local/etc/php/conf.d/):

• With a Dockerfile. Create a file upload-progress.ini next to it containing:

  session.upload_progress.enabled=0

  and add to the Dockerfile:

  COPY upload-progress.ini "$PHP_INI_DIR/conf.d/"

  Then rebuild and redeploy as above.

• Compose service with only image:. Mount the same file into that folder:

  volumes:
    - ./upload-progress.ini:/usr/local/etc/php/conf.d/upload-progress.ini:ro

  Then docker compose up -d.

• PHP-FPM with your own pool config. You can set it in the pool config instead. Either way, restart the workers (recreating the container does that).

Check it took effect:

docker exec <container> php -i | grep session.upload_progress.enabled

It should show Off.

Pin to a full version or a moving tag?

• Full version tag (php:8.2.35-apache): you always know which PHP you run. You have to edit the tag again at the next PHP security release.

• Moving tag (php:8.2-apache): it follows the 8.2 branch, but your server only moves when you pull again (--pull on a build, or docker compose pull). If you never do, you stay on the old version.

Either way, a fix in the official image reaches you only after a pull and redeploy.

If your Dockerfile installs PHP from apt

Some images start FROM debian or FROM ubuntu and install PHP with apt-get install php8.x. The check above shows them: PHP isn't at /usr/local/bin/php and PHP_VERSION is empty. These use the distro's PHP package, which keeps the old upstream number and adds fixes on top. So php -v may show 8.3.6 on a patched Ubuntu 24.04 package, or 8.5.4 on a patched Ubuntu 26.04 package.

For these images, compare the package version against your distro's security tracker, not against php.net's numbers:

docker exec <container> dpkg -l 'php*'

As of 24 October 2026 the trackers list these packages as fixed:

• Ubuntu 26.10: php8.5 8.5.9-0ubuntu2.1

• Ubuntu 26.04 LTS: php8.5 8.5.4-0ubuntu1.5

• Ubuntu 24.04 LTS: php8.3 8.3.6-0ubuntu0.24.04.13

• Ubuntu 22.04 LTS: php8.1 8.1.2-1ubuntu2.28

• Debian 13 (trixie): php8.4 8.4.27-1~deb13u1

• Debian 12 (bookworm): php8.2 8.2.35-1~deb12u1

On Debian, the fix is in the security archive only. Debian's main archive still lists the vulnerable packages: php8.2 8.2.32-1~deb12u1 for bookworm and php8.4 8.4.24-1~deb13u1 for trixie. If dpkg -l shows one of those, the image was built without the security repository or from an old cached layer.

Rebuild with --pull so apt-get installs the current package, then check dpkg -l again. The 23 October setting above applies here too; set it in your distro's PHP config.

The official php image blocks Debian's PHP packages by default, so the two don't get mixed.

PHP 8.1 and older

The PHP project no longer ships updates for PHP 8.1 and older, and the official image's current build list starts at 8.2. A php:8.1-* or php:7.4-* tag you pull today does not carry this fix.

Your options:

• move to a fixed branch (8.2.35 or newer), testing your app first;

• php.net's source backports for 7.4, 8.0 and 8.1, if you build PHP yourself;

• a distro or LTS vendor package with a backported fix, checked against that vendor's tracker.

If you can't rebuild today

php.net lists measures that reduce exposure to specific attack paths, and says only an update is a complete fix. They are in the 21 October advisory. For session.upload_progress.enabled=0, see One more setting, even on a patched tag for where to set it in a container.

A patched image doesn't undo an earlier break-in

Rebuilding gives you a fixed PHP. It doesn't tell you whether someone got in before you rebuilt, and a container that wrote to a mounted volume keeps those files. See Am I affected by PHP2Shell? for what to check next.

Want us to check and patch it?

Our PHP2Shell check & patch covers PHP on shared hosting and on a VPS. We check the PHP your site actually runs, patch, upgrade or backport it, look for signs of compromise, and send you a written report with the final status: checked and patched.

Rebuilding container images isn't in that list. If your app runs in Docker, describe how it's deployed in your request, and we'll confirm whether it's covered before any work starts. On shared hosting, we switch versions only where your panel allows it; otherwise your host owns PHP, and we send your host the exact request.

PHP2Shell check & patch