PHP2Shell and Docker: rebuild your PHP and WordPress images

A WordPress update, a composer update or a new Nextcloud release replaces application files. The PHP interpreter is a program installed in the Docker image, just like the Debian or Alpine system around it. As long as the image does not change, PHP does not change, however many times the application is updated.

The second trap is the restart. docker restart restarts the existing container, so the same image. docker compose up -d does not look for a newer version when an image with that name already exists on the server: it reuses the local copy. Only a pull or a build --pull, followed by recreating the container, changes the interpreter.

The two flaws and the apt or dnf commands are covered in our PHP update guide. Here the subject is the Docker image and the proof that it is the right one.

php -v queries the command-line program, not the process that answers requests. The PHP_SAPI constant tells which one is speaking: cli on the command line, fpm-fcgi for PHP-FPM, apache2handler for Apache with mod_php. In a single image the two versions almost always match. The gap appears in three common Docker situations: a docker compose run starts a fresh container, so from the latest local image, while the web service still runs the old one; a maintenance cli container is built on a different tag than the web service; a reverse proxy forwards to a different container than the one you inspect.

The most reliable proof remains the HTTP request: it follows a visitor's path and reads PHP_VERSION in the process that answers. Check the FPM binary as a complement with docker exec <container> php-fpm -v.

A branch tag such as php:8.3-fpm advances at the next pull: it then points to the fixed version. An exact tag such as php:8.3.36-fpm stays on its version, and a digest reference (@sha256:…) never moves. The docker image pull documentation is explicit: with a digest, Docker fetches no rebuild, security fixes included, until you change the digest yourself.

The fixed tags of the official php image reached Docker Hub during the day and evening of October 21, 2026 (UTC), for the FPM variants of branches 8.5, 8.4, 8.3 and 8.2. The official WordPress images php8.3-fpm, php8.4-fpm and php8.3-apache were republished on October 22, 2026 in the early morning (UTC), and Nextcloud's the same day. An image pulled before those moments is therefore the old one, even with an identical name. Check these dates on each tag's page. Branch 8.2 gets its fix but reaches end of life on December 31, 2026: plan its replacement.

For an image built in-house from FROM php:8.3-fpm, the sequence takes three commands: docker compose build --pull --no-cache, then docker compose up -d --force-recreate, then a check of the served version. Each answers a specific trap.

--pull is the option that changes the PHP version: it tells Docker to look for a newer version of the base image instead of reusing the server's. Without it, the FROM is resolved with the local copy, and the build succeeds with the old interpreter, without a single message.

--no-cache replays every layer, including apt-get and composer install, which also renews system libraries and dependencies. It is not needed to change PHP, because when the base image changes the following layers are rebuilt on their own. It is useful when a cached layer freezes a package you want renewed.

--force-recreate recreates containers even if Compose considers their configuration and image unchanged. That removes the doubt about what is running.

Rebuilding your images at each fix is a schedule to keep, not a one-off action. On a VPS with root access, that schedule is yours, and our guide to installing Docker on a VPS lays the groundwork.

A WordPress tag combines a WordPress version, a PHP version and a variant, for example php8.3-apache or php8.3-fpm. The PHP branch is chosen by the tag name. Changing the WordPress version, or letting automatic updates act in the data volume, does not touch that branch. To get the fixed PHP, re-pull the tag with docker compose pull, then recreate the service. The Apache variant is the default one, and it loads PHP as mod_php: the PHP project considers it the most exposed, with an exploit demonstrated before any application code runs. Treat it as a priority.

Nextcloud follows the same principle, in two variants: apache ships a full Apache, fpm needs a web server in front of it. The image documentation describes the update as a replacement: pull the image, throw away the old container, start the new one. Nextcloud's code and your data live in the /var/www/html volume, which recreating the container does not erase. See also our WordPress on VPS guide and the Nextcloud one.

With Octane and FrankenPHP there is no PHP-FPM: the application server embeds the interpreter. The official FrankenPHP images are built on the official PHP images, and their tag combines the FrankenPHP version, the PHP version and the system, in the form dunglas/frankenphp:<version>-php8.4-trixie. The project rebuilds them at each release and, every day at 4 am UTC, if new official PHP images exist. Your FROM dunglas/frankenphp only gets the fix if you rebuild your image with --pull.

The trap specific to Octane is the worker. Octane boots the application once and keeps it in memory: php artisan octane:reload gracefully restarts the workers to load the deployed code. It is the right move after a code deployment, but it does not replace the interpreter, which remains that of the running image. The same goes for a kill -USR2 or a PHP-FPM reload run in the old container: they restart the same files, those of the old image. To change PHP, recreate the container, including those of queue workers and the scheduler. See our Laravel Octane on VPS guide.

The sources: PHP security and release announcements, docker compose up, docker compose build, the pull_policy attribute, docker image pull, the php image, the wordpress image, the Nextcloud image, FrankenPHP with Docker and Laravel Octane.