PHP2Shell et Docker : reconstruire vos images PHP et WordPress

Une mise à jour de WordPress, un composer update ou une nouvelle version de Nextcloud remplacent des fichiers de l'application. L'interpréteur PHP, lui, est un programme installé dans l'image Docker, au même titre que le système Debian ou Alpine qui l'entoure. Tant que l'image ne change pas, le PHP ne change pas, quel que soit le nombre de mises à jour de l'application.

Le second piège est le redémarrage. docker restart relance le conteneur existant, donc la même image. docker compose up -d ne va pas chercher une version plus récente quand une image portant ce nom existe déjà sur le serveur : il réutilise la copie locale. Seul un pull ou un build --pull, suivi d'une recréation du conteneur, change l'interpréteur.

Les deux failles et les commandes apt ou dnf sont détaillées dans notre guide de mise à jour de PHP. Ici, il s'agit de l'image Docker et de la preuve qu'elle est la bonne.

php -v interroge le programme en ligne de commande, pas le processus qui répond aux requêtes. La constante PHP_SAPI dit lequel parle : cli en ligne de commande, fpm-fcgi pour PHP-FPM, apache2handler pour Apache avec mod_php. Dans une image unique, les deux versions coïncident presque toujours. L'écart apparaît dans trois situations courantes avec Docker : un docker compose run démarre un conteneur neuf, donc depuis l'image locale la plus récente, alors que le service web tourne toujours sur l'ancienne ; un conteneur cli de maintenance est bâti sur une autre étiquette que le service web ; un reverse proxy renvoie vers un autre conteneur que celui que vous inspectez.

La preuve la plus fiable reste la requête HTTP : elle suit le chemin d'un visiteur et lit PHP_VERSION dans le processus qui répond. Le binaire FPM se contrôle en complément avec docker exec <conteneur> php-fpm -v.

Une étiquette de branche comme php:8.3-fpm avance au prochain pull : elle pointe alors vers la version corrigée. Une étiquette exacte comme php:8.3.36-fpm reste sur sa version, et une référence par empreinte (@sha256:…) ne bouge jamais. La documentation de docker image pull est explicite : avec une empreinte, Docker ne récupère aucune reconstruction, correctifs de sécurité compris, tant que vous ne changez pas l'empreinte vous-même.

Les étiquettes corrigées de l'image officielle php sont arrivées sur Docker Hub dans la journée et la soirée du 21 octobre 2026 (UTC), pour les variantes FPM des branches 8.5, 8.4, 8.3 et 8.2. Les images WordPress officielles php8.3-fpm, php8.4-fpm et php8.3-apache ont été republiées le 22 octobre 2026 au petit matin (UTC), et celles de Nextcloud le même jour. Une image tirée avant ces moments est donc l'ancienne, même si son nom est identique. Relisez ces dates sur la page de chaque étiquette. La branche 8.2 reçoit son correctif mais atteint sa fin de vie le 31 décembre 2026 : planifiez son remplacement.

Pour une image construite chez vous à partir de FROM php:8.3-fpm, la séquence tient en trois commandes : docker compose build --pull --no-cache, puis docker compose up -d --force-recreate, puis le contrôle de la version servie. Chacune répond à un piège précis.

--pull est l'option qui change la version de PHP : elle demande à Docker de chercher une version plus récente de l'image de base au lieu de réutiliser celle du serveur. Sans elle, le FROM est résolu avec la copie locale, et la construction réussit avec l'ancien interpréteur, sans le moindre message.

--no-cache rejoue toutes les couches, y compris apt-get et composer install, ce qui renouvelle aussi les bibliothèques système et les dépendances. Il n'est pas nécessaire pour changer de PHP, car quand l'image de base change, les couches suivantes sont reconstruites d'elles-mêmes. Il sert quand une couche en cache fige un paquet à renouveler.

--force-recreate recrée les conteneurs même si Compose estime que leur configuration et leur image n'ont pas changé. C'est ce qui supprime le doute sur ce qui tourne.

Reconstruire ses images à chaque correctif est un calendrier à tenir, pas un geste unique. Sur un VPS en accès root, ce calendrier est le vôtre, et notre guide d'installation de Docker sur VPS pose la base de travail.

Une étiquette WordPress combine une version de WordPress, une version de PHP et une variante, par exemple php8.3-apache ou php8.3-fpm. La branche PHP est choisie par le nom de l'étiquette. Changer de version de WordPress, ou laisser les mises à jour automatiques agir dans le volume de données, ne touche pas à cette branche. Pour obtenir le PHP corrigé, il faut re-tirer l'étiquette avec docker compose pull, puis recréer le service. La variante Apache est la variante par défaut, et elle charge PHP en mod_php : c'est celle que le projet PHP juge la plus exposée, avec un exploit démontré avant l'exécution du moindre code applicatif. Traitez-la en priorité.

Nextcloud suit le même principe, en deux variantes : apache embarque un Apache complet, fpm demande un serveur web devant lui. La documentation de l'image décrit la mise à jour comme un remplacement : tirer l'image, jeter l'ancien conteneur, démarrer le nouveau. Le code de Nextcloud et vos données vivent dans le volume /var/www/html, que la recréation du conteneur n'efface pas. Voir notre guide WordPress sur VPS et celui de Nextcloud.

Avec Octane et FrankenPHP, il n'y a pas de PHP-FPM : le serveur d'application embarque l'interpréteur. Les images officielles de FrankenPHP reposent sur les images PHP officielles, et leur étiquette combine la version de FrankenPHP, celle de PHP et le système, sous la forme dunglas/frankenphp:<version>-php8.4-trixie. Le projet les reconstruit à chaque version et, chaque jour à 4 h UTC, si de nouvelles images PHP officielles existent. Votre FROM dunglas/frankenphp ne reçoit le correctif que si vous reconstruisez votre image avec --pull.

Le piège propre à Octane est le worker. Octane démarre l'application une fois et la garde en mémoire : php artisan octane:reload relance proprement les workers pour charger le code déployé. C'est le bon geste après un déploiement de code, mais il ne remplace pas l'interpréteur, qui reste celui de l'image en cours. Il en va de même pour un kill -USR2 ou un rechargement de PHP-FPM lancé dans l'ancien conteneur : ils relancent les mêmes fichiers, ceux de l'ancienne image. Pour changer de PHP, recréez le conteneur, y compris ceux des workers de file et du planificateur. Voir notre guide Laravel Octane sur VPS.

Les sources : les annonces de sécurité et de versions de PHP, docker compose up, docker compose build, l'attribut pull_policy, docker image pull, l'image php, l'image wordpress, l'image Nextcloud, FrankenPHP avec Docker et Laravel Octane.