Morocco Next Technologies (MNT) · 21/10/2026 · PHP2Shell · CVE-2026-109618 · CVE-2026-109619
Le 21 octobre 2026, deux vulnérabilités critiques du moteur PHP, identifiées sous les références CVE-2026-109618 et CVE-2026-109619, ont conduit à la publication de correctifs de sécurité. Elles peuvent, dans certaines conditions, exposer des applications web à une exécution de code à distance sans authentification.
Chez Morocco Next Technologies (MNT), nous privilégions une réponse structurée : identifier les environnements exposés, appliquer les mises à jour adaptées et vérifier que les applications en production utilisent réellement les composants corrigés. Voici notre démarche recommandée, applicable aux VPS Linux comme aux plateformes conteneurisées.
Comprendre les risques
Les vulnérabilités concernent la gestion interne de la mémoire de PHP. Un code Laravel, Symfony ou WordPress à jour ne suffit pas à neutraliser une faille située dans le moteur PHP utilisé par le serveur.
Les premières versions corrigées publiées par le projet PHP sont : 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les paquets de distributions Linux, il faut vérifier les bulletins de sécurité du fournisseur, qui peut rétroporter les correctifs sans reprendre les mêmes numéros.
1. Corriger les applications sur VPS Linux
Sur Ubuntu ou Debian, nous commençons par vérifier la version CLI, les services PHP-FPM réellement actifs et la configuration du serveur web. Une machine peut héberger plusieurs versions de PHP.
Après sauvegarde et vérification que les dépôts configurés proposent les correctifs, les paquets concernés peuvent être mis à jour puis PHP-FPM redémarré. Contrôlez également les extensions, la réponse HTTP et les journaux.
- php -v
- systemctl list-units --type=service --all | grep php
- sudo apt update
- apt-cache policy php8.3-fpm php8.3-cli
- sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
- sudo systemctl restart php8.3-fpm
- sudo systemctl status php8.3-fpm
2. Corriger les images Docker et Docker Compose
Le PHP du conteneur est distinct de celui de l’hôte. Une mise à jour du VPS ne corrige donc pas une ancienne image Docker. Nous vérifions la version dans le conteneur, reconstruisons l’image avec une base corrigée, puis redéployons les services.
La directive FROM ci-dessous est un exemple de base PHP corrigée et non un Dockerfile complet. Vérifiez la disponibilité de l’étiquette, les extensions et la compatibilité applicative avant le déploiement.
- docker ps
- docker exec NOM_CONTENEUR php -v
- FROM php:8.3.36-fpm-alpine
- docker build --pull --no-cache -t mon-application:php2shell-fixed .
- docker run --rm mon-application:php2shell-fixed php -v
- docker compose build --pull
- docker compose up -d
3. Déployer les corrections sur Docker Swarm
Sur Docker Swarm, l’image corrigée doit être publiée dans un registre accessible aux nœuds et propagée à toutes les tâches du service. La mise à jour progressive aide à limiter les interruptions lorsque l’architecture le permet.
Il faut contrôler chaque réplica, les journaux et les tests de santé. Un retour arrière peut réactiver une image vulnérable : c’est une mesure de disponibilité exceptionnelle, pas une correction de sécurité.
- docker service ls
- docker service ps NOM_SERVICE --no-trunc
- docker service update --image registry.example.com/app:php2shell-fixed --update-parallelism 1 --update-delay 10s --update-order start-first --update-failure-action rollback NOM_SERVICE
- docker service ps NOM_SERVICE --no-trunc
4. Corriger Kubernetes
Sur Kubernetes, nous repérons les workloads PHP, publions l’image corrigée puis mettons à jour les Deployments. Les commandes d’exemple utilisent le namespace production et un conteneur nommé php : adaptez-les à votre environnement.
Si Helm, Argo CD ou Flux gère le déploiement, actualisez aussi la configuration déclarative afin d’éviter la restauration automatique d’une ancienne image. Vérifiez tous les Pods et les versions réellement exécutées.
- kubectl get pods -A
- kubectl -n production set image deployment/mon-application php=registry.example.com/php-app:php2shell-fixed
- kubectl -n production rollout status deployment/mon-application
- kubectl -n production get pods -o wide
Après le correctif : valider et surveiller
Une commande exécutée sans erreur ne suffit pas. Nous recommandons de vérifier les versions réellement actives, la disponibilité applicative, les erreurs HTTP, les journaux système et les comportements anormaux.
Si une compromission est suspectée, isolez l’environnement, préservez les preuves, analysez les accès et renouvelez les secrets exposés. Les mesures temporaires de filtrage ne remplacent pas le correctif officiel.
Notre engagement chez MNT
Face à PHP2Shell, nous encourageons les organisations à agir sans délai, mais avec méthode. Un inventaire fiable des runtimes, des images et des dépendances, associé à des pipelines CI/CD intégrant des contrôles de sécurité, réduit durablement les délais d’intervention.
Notre recommandation : identifiez immédiatement les systèmes exposés, déployez les correctifs adaptés et documentez la vérification de chaque instance en production.
Morocco Next Technologies — Des solutions numériques pensées pour vos enjeux, conçues pour inspirer confiance et durer.