Quicky : PHP2shell sur Docker, patcher PHP-FPM sans perdre ses modules

La licorne rose de Geekeries remplace un conteneur PHP provisoire par une image officielle validée.

Salut à tous, petite séance de maintenance imprévue avec PHP2shell sur Docker. Le 21 octobre 2026, les correctifs PHP ont été annoncés à 2pm UTC (16h en France), mais l’image docker officielle dont j’ai besoin n’était pas encore dispo. Voici la méthode suivie pour protéger Geekeries, conserver mes extensions PHP et revenir sur la base officielle dès sa disponibilité.

Les deux failles, CVE-2026-109618 et CVE-2026-109619, permettent une exécution de code à distance. L’avis officiel PHP inclut PHP-FPM et indique les versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

PHP2shell sur Docker : vérifier l’image, pas seulement le tag

Premier piège : le tag peut apparaître alors que la liste des images disponibles est encore vide. Pour vérifier la variante FPM utilisée ici, Docker avec son plugin Buildx suffit :

docker buildx imagetools inspect php:8.5.12-fpm-bookworm

Cette commande consulte le registre sans déployer de conteneur. Cherchez votre plateforme, par exemple linux/amd64, et son digest, l’identifiant précis de l’image. Un tag seul ne suffit pas.

En attendant, j’ai placé le site derrière une page statique de maintenance (sans PHP évidement). Puis j’ai construit une image provisoire depuis les sources officielles corrigées. Un dépannage temporaire pas une invitation à maintenir ma propre image PHP indéfiniment. Mais le temporaire avait déjà son ticket de sortie, pour une fois.

Revenir sur l’officiel sans perdre les modules

Une fois l’image publiée sur le dockerhub, j’ai repris mon Dockerfile personnalisé, comme dans le tutoriel PHP-FPM de la série Docker et Portainer. La base change, mais les extensions et réglages restent nécessaires. Voici l’ordre à reprendre sur votre stack :

  1. Sauvegardez la recette déployée, les configurations et la base. Conservez l’image précédente et son tag.
  2. Remplacez le FROM par l’image officielle corrigée, figée par digest. Gardez les instructions d’installation des modules, puis construisez sous un nouveau tag.
  3. Comparez php -m avant/après, vérifiez la version avec php -v, puis testez FPM et les fonctions utilisées : base, cache, images, compression, etc.
  4. Activez une page de maintenance, modifiez la référence PHP dans la source de votre stack et redéployez depuis Portainer. Prévoyez que l’opération puisse recréer les autres conteneurs de la stack.
  5. Testez les pages et l’application avant de rouvrir. En cas d’échec, remettez l’ancienne référence dans la même source et redéployez. Si cette image est vulnérable, gardez la maintenance active.

Bref, rien de très ésotérique et Pwny s’en est sortie comme un chef, Patchez bien vos php, genre… ASAP !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. Découvrez comment les données de vos commentaires sont traitées.