En bref : une mise à jour de l'image Docker PHP est obligatoire contre PHP2Shell, et elle ne se fait pas toute seule. Vous devez reconstruire ou retirer l'image avec une version corrigée de PHP, recréer chaque conteneur à partir de celle-ci et vérifier que 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 tourne dans le conteneur en cours d'exécution. Un simple redémarrage du conteneur ne suffit pas.
Pourquoi les conteneurs ne sont pas automatiquement sûrs
Une image Docker est un instantané figé. Le PHP qu'elle contient reste dans l'état qu'il avait lors de la construction, même si des mises à jour sont depuis longtemps installées sur l'hôte. Une mise à jour de paquet sur le système hôte ne change rien au PHP dans le conteneur.
S'y ajoutent des pièges typiques : des images construites il y a des mois et non retouchées depuis, des images de base avec une étiquette fixe comme php:8.3.35-fpm, des caches locaux qui réutilisent l'ancienne image de base lors de la construction, et des conteneurs qui ont été redémarrés, mais jamais recréés. Tous les modes d'exécution courants en conteneur sont concernés : PHP-FPM, Apache avec mod_php et FrankenPHP.
S'y ajoute une question de responsabilité. Dans de nombreuses entreprises, une agence ou un développeur a construit l'image une fois, mais elle est exploitée par le service informatique interne ou un hébergeur. Personne ne se sent alors responsable de la version de PHP dans l'image. Clarifiez donc d'abord qui construit l'image, où se trouve le Dockerfile et qui a le droit de déployer de nouvelles images.
Vérifier la version de PHP dans le conteneur
Vérifiez le conteneur en cours d'exécution, pas seulement le Dockerfile. Les commandes sont en lecture seule.
docker ps --format "table {{.Names}}\t{{.Image}}\t{{.CreatedAt}}"
docker exec <container> php -v
docker exec <container> php -i | grep -E "^PHP Version|Server API"
docker image inspect <image> --format "{{.Created}}"
Si l'image utilise des paquets de distribution plutôt que les builds PHP officiels, vérifiez l'état des paquets dans le conteneur. Les noms de paquets varient selon la distribution de base :
docker exec <container> sh -c "apt policy php8.3-fpm 2>/dev/null || apk info -v 2>/dev/null | grep php"
Avec des paquets de distribution, un backport peut être appliqué alors que le numéro de version reste ancien. C'est alors le journal des modifications du paquet qui compte. Les images PHP officielles apportent en revanche généralement un PHP compilé par elles-mêmes ; là, le numéro de version affiché par php -v est la valeur déterminante. Comment reconnaître les backports, Bien vérifier la version de PHP et l'état des correctifs le décrit.
Mettre à jour l'image Docker PHP : reconstruire et déployer
Image propre fondée sur une image PHP : retirer à nouveau l'image de base et construire sans cache.
docker build --pull --no-cache -t meine-app:2026-10-25 .
docker run --rm meine-app:2026-10-25 php -v # vérifier la version avant le déploiement
Avec Docker Compose : retirer ou construire les images et recréer les conteneurs.
docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Vérifiez ensuite de nouveau avec docker exec <container> php -v que la nouvelle version tourne. Si le conteneur a une étiquette de version fixe dans le Dockerfile, par exemple FROM php:8.3.35-fpm, vous devez relever l'étiquette. Une étiquette sur la branche comme php:8.3-fpm reçoit de nouveaux états de correctifs, mais seulement si vous la retirez à nouveau.
Gardez l'image précédente à disposition jusqu'à ce que la nouvelle version soit testée. En cas d'erreur, vous pouvez ainsi revenir en arrière sans laisser l'application longtemps hors ligne. L'ancienne image contient toutefois de nouveau le PHP vulnérable ; un retour arrière n'est donc défendable que brièvement et avec les mesures transitoires.
Qui utilise Kubernetes déploie la nouvelle image via le Deployment. Les détails figurent sous Corriger PHP dans Kubernetes. Pour les images FrankenPHP, la même démarche s'applique ; des indications sur le mode d'exécution figurent sous Sécuriser FrankenPHP.
N'oubliez aucun conteneur annexe : les workers cron et de file d'attente, outils d'administration ou environnements de préproduction utilisent souvent la même image PHP, mais tournent dans leurs propres conteneurs. Chacun d'eux doit être recréé.
Mesures transitoires en conteneur
Si la mise à jour n'est pas encore possible, les mesures transitoires de php.net valent aussi en conteneur. Elles ne sont pas une protection complète. La limite de mémoire doit être placée au niveau du conteneur, car php.net la recommande via conteneur ou cgroup, et non via RLIMIT_AS ou RLIMIT_DATA :
; p. ex. fichier dans l'image : /usr/local/etc/php/conf.d/zz-uebergang.ini
memory_limit = -1
post_max_size = 8M
upload_max_filesize = 6M
session.upload_progress.enabled = 0
docker run --memory=1g ... # ou dans Compose : deploy.resources.limits.memory
Vous adaptez la valeur à votre application. Veillez à ce que l'application ne puisse pas écraser memory_limit elle-même ; avec PHP-FPM, définissez pour cela les valeurs dans le pool avec php_admin_value. La nouvelle configuration ne s'applique que lorsque le conteneur est recréé ou redémarré ; le contexte sur le redémarrage figure sous Redémarrer PHP-FPM et tous les workers.
Pour que ce soit plus rapide la prochaine fois
- Reconstruire les images régulièrement et automatiquement, pas seulement lors de modifications du code.
- Utiliser des images de base avec étiquette de branche et versionner l'état construit par une date ou un digest.
- Faire vérifier les images avant déploiement pour détecter les failles connues et exploiter les conteneurs sans droits root.
- Tenir un inventaire indiquant quels conteneurs utilisent quelle image.
Comment PHP SOS aide-t-il concrètement ?
- Recenser l'existant : nous vérifions tous les conteneurs en cours d'exécution, leurs images et leurs versions de PHP, y compris les conteneurs annexes et la préproduction.
- Reconstruire et déployer : via le service de correctifs PHP, nous construisons les images avec la version corrigée et recréons les conteneurs de façon contrôlée.
- Sécuriser la transition, là où la mise à jour dépend de l'application : valeurs de php.net, limite de mémoire sur le conteneur.
- Surveiller durablement : avec la supervision de sécurité, nous gardons à l'œil les états des images et le comportement inhabituel des conteneurs.
Questions fréquentes
docker restart suffit-il après la mise à jour ?
Non. docker restart redémarre le conteneur avec la même ancienne image. Vous devez construire ou retirer la nouvelle image et en recréer le conteneur, par exemple avec docker compose up -d --force-recreate.
L'image PHP officielle contient-elle déjà la version corrigée ?
Le mieux est de le vérifier directement : retirez à nouveau l'image et lancez php -v dedans. On attend 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Si l'image affiche un numéro plus ancien, elle n'est pas encore à jour ou provient d'un cache.
PHP en conteneur est-il moins exposé que sur l'hôte ?
La faille agit de la même façon dans le conteneur. Un conteneur bien construit peut limiter les conséquences d'une intrusion, par exemple avec un utilisateur sans droits root et un système de fichiers en lecture seule. Cela ne remplace pas le correctif.