En bref : l'image PHP officielle sur Docker Hub existe sous de nombreux tags, qui combinent version, variante (par exemple cli, fpm, apache) et système de base. Un tag est un pointeur qui se déplace vers de nouveaux états après des reconstructions ; seul le digest désigne exactement un état. Contre PHP2Shell, il vous faut une image avec PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, vérifiée avec php -v, et une reconstruction de vos propres images sur cette base.
Pourquoi le tag seul en dit peu
De nombreuses équipes écrivent dans leur Dockerfile une ligne comme FROM php:8.3-fpm et l'oublient ensuite. Cela fonctionne tant que personne ne demande quelle version de PHP tourne réellement. Depuis PHP2Shell, tout le monde le demande.
La réponse ne figure pas dans le Dockerfile. Un tag comme 8.3-fpm pointe, au moment du téléchargement, vers l'état le plus récent de cette branche. Si l'image a été téléchargée avant le 21 octobre et n'a pas été renouvelée depuis, elle contient une version vulnérable, bien que le tag pointe aujourd'hui vers un état corrigé. Selon les lignes directrices des Docker Official Images, les images sont activement reconstruites, y compris pour des corrections de sécurité. Votre état local n'en est toutefois pas affecté.
Le déroulement complet, de la reconstruction au conteneur recréé, est décrit dans Corriger PHP dans les conteneurs Docker. Il s'agit ici de la question préalable : quelle est la bonne image, et comment prouver son état ?
Tags d'image Docker PHP : leur structure
Les tags se composent d'au plus trois parties. Docker Hub montre des exemples comme php:8.2-cli, php:8.2-fpm-alpine ou php:8.4.27-zts-alpine3.24.
| Composant | Exemple | Signification |
|---|---|---|
| Indication de version | 8.4.27 ou 8.4 |
la version complète reste à cet état, l'indication de branche se déplace avec les nouveaux correctifs |
| Variante | cli, fpm, apache, zts |
mode d'exécution de PHP dans le conteneur |
| Système de base | alpine3.24, bookworm, trixie |
version d'Alpine ou de Debian sous-jacente |
Les variantes ne sont pas équivalentes face à PHP2Shell. fpm exploite PHP-FPM, apache exploite PHP comme module Apache, donc mod_php. L'équipe PHP classe ce mode d'exécution au plus haut niveau, parce qu'un exploit y a été démontré avant même que le code de l'application ne s'exécute. Plus de détails sous Pourquoi mod_php est particulièrement exposé. La variante cli est destinée aux tâches en ligne de commande.
Le système de base a aussi des conséquences. Les images Alpine sont petites, mais utilisent une autre bibliothèque C que les images Debian ; certaines extensions ou bibliothèques précompilées s'y comportent différemment. Ne changez donc pas le système de base au passage avec la mise à jour de sécurité, mais restez d'abord sur ce que connaît votre application.
Important pour la compréhension : dans l'image officielle, PHP ne provient pas des paquets de la distribution de base. Docker Hub décrit que les sources de PHP se trouvent dans l'image et que les extensions sont intégrées par des scripts auxiliaires comme docker-php-ext-install. Une mise à jour de paquets du système de base dans votre propre Dockerfile ne change donc rien à la version de PHP. Seul compte l'état de l'image officielle sur lequel vous construisez.
Tag ou digest : ce qui change et quand
Un digest est une somme de contrôle sur le contenu d'une image, écrite sous la forme sha256: suivie d'une longue chaîne de caractères. Il change à chaque reconstruction. Il se prête ainsi comme preuve : qui connaît le digest sait exactement quel état tourne.
En pratique, une répartition des rôles a fait ses preuves :
- Dans le Dockerfile, utiliser le tag de branche, par exemple
php:8.4-fpm, afin qu'une reconstruction reçoive automatiquement le dernier correctif de cette branche. - Dans le déploiement, utiliser le digest de votre propre image finalisée, afin que ce qui est livré soit sans ambiguïté.
- Dans la documentation, consigner les deux : tag, digest et la version vérifiée avec
php -v.
Qui fige au contraire un tag de version complet comme 8.3.35-fpm ne reçoit jamais de correctif automatiquement. Cela peut être voulu, mais exige un processus qui relève le tag à chaque avis de sécurité.
PHP2Shell : vérifier une image avant usage
Les commandes suivantes téléchargent une image et en lisent des informations. Elles ne modifient aucun conteneur en cours.
# Télécharger l'état actuel du tag de branche
docker pull php:8.4-fpm
# Quelle version de PHP contient l'image ?
docker run --rm php:8.4-fpm php -v
# Afficher le digest de l'image téléchargée
docker image inspect php:8.4-fpm --format '{{index .RepoDigests 0}}'
# Interroger le digest et les plateformes directement dans le registre
docker buildx imagetools inspect php:8.4-fpm
Pour les images multi-plateformes, l'interrogation avec imagetools montre un digest de niveau supérieur et, en dessous, un digest propre par plateforme, par exemple linux/amd64 ou linux/arm64. Documentez le digest que vos serveurs téléchargent réellement, et notez que les postes de développement d'une autre architecture reçoivent un autre digest de plateforme.
Si php -v n'affiche pas au moins la version corrigée de la branche, l'image est obsolète ou provient d'un cache. Vérifiez alors si votre environnement utilise un miroir de registre qui sert d'anciens états.
Pour PHP 8.1 et antérieur, le projet PHP ne fournit plus de versions officielles. Une image officielle de ces branches ne peut donc pas contenir de version corrigée régulière. Selon les lignes directrices de Docker, les tags qui ne sont plus entretenus restent consultables, mais ne sont plus mis à jour.
L'image fournit, selon Docker Hub, php.ini-development et php.ini-production et recommande vivement la version production pour l'exploitation en production. Placez vos propres réglages sous forme de fichier dans $PHP_INI_DIR/conf.d/, y compris les valeurs transitoires de php.net.
Erreurs typiques dans le choix de l'image
- Variante par habitude : la variante apache est choisie parce qu'elle démarre simplement, alors que fpm avec un serveur web séparé serait possible.
- Pas de reconstruction de vos propres images : l'image de base est à jour, l'image d'application construite à partir d'elle ne l'est pas.
- Builds multi-étapes négligés : dans un Dockerfile avec plusieurs lignes
FROM, une seule est adaptée. - Images annexes oubliées : workers, conteneurs cron et outils d'administration utilisent leurs propres tags.
- Ne miser que sur
latest: le tag ne dit rien de la branche ni de la variante et peut sauter de façon inattendue lors d'une nouvelle branche principale.
La façon d'automatiser les reconstructions pour qu'une image obsolète ne tourne pas longtemps est décrite dans CI/CD : reconstruire automatiquement les images PHP. Les bases de PHP dans les conteneurs sont expliquées dans PHP dans les conteneurs.
Comment PHP SOS aide-t-il concrètement ?
- Contrôler l'existant : nous relevons quels tags, digests et versions de PHP se trouvent dans vos images et conteneurs en cours.
- Évaluer la variante : nous vérifions si mod_php est nécessaire ou si fpm avec un serveur web séparé réduit le risque.
- Reconstruire et prouver : avec le service de correctifs PHP, nous reconstruisons les images sur une base corrigée et documentons tag, digest et version.
- Ancrer le processus : nous organisons Dockerfiles et déploiements de sorte que le prochain correctif arrive de façon planifiable.
Questions fréquentes
Quelle est la différence entre un tag et un digest ?
Un tag comme php:8.4-fpm est un nom qui peut pointer vers un nouvel état après chaque reconstruction. Un digest est une somme de contrôle qui désigne exactement un état immuable. Pour les preuves et les déploiements reproductibles, le digest est l'indication la plus fiable.
Quel tag contient la correction de PHP2Shell ?
Sont corrigées les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Un tag avec le numéro de version complet indique directement l'état. Avec des tags plus courts comme 8.4-fpm, vérifiez après le téléchargement avec php -v quelle version est réellement contenue.
Existe-t-il une image officielle corrigée pour PHP 8.1 ?
Le projet PHP ne fournit plus de versions officielles pour 8.1 et antérieur. Une image officielle de ces branches ne peut donc pas contenir de version corrigée régulière. Planifiez le passage à une branche prise en charge.
La variante apache est-elle plus risquée que fpm ?
La variante apache exploite PHP comme module Apache, donc mod_php. L'équipe PHP classe ce mode d'exécution au plus haut niveau pour PHP2Shell. Les deux variantes ont besoin de la mise à jour ; avec mod_php, la hâte est particulièrement de mise.