Alerte sécurité · PHP
Faille critique PHP2Shell : votre site est-il vraiment corrigé ?
Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques qui permettent de prendre la main sur un serveur web, sans mot de passe. La DGSSI a publié un bulletin critique le jour même, puis un second, le lendemain, sur les correctifs mal appliqués. Les versions à installer, les pièges, et comment prouver que votre site est vraiment protégé.
- Publié le 27 octobre 2026
- Par Mehdi Najeddine
- Lecture : 9 min
L'essentiel
Deux failles de PHP, notées 9,2 sur 10, permettent d'exécuter du code à distance sans authentification. La DGSSI les classe critiques et signale un code d'attaque public.
Installez 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou plus récent : aucun réglage ne protège complètement.
Une mise à jour ne compte qu'après le redémarrage de PHP-FPM ou d'Apache, et la recréation des conteneurs.
PHP 8.1 et plus ancien n'ont pas de version officielle corrigée : correctif de la distribution, puis migration.
Un pare-feu applicatif réduit le risque, mais ne remplace jamais la mise à jour.
- la note de gravité (CVSS v4, sur 10) de chacune des deux failles
- 9,2
- branches de PHP corrigées le 21 octobre 2026, de 8.2 à 8.5
- 4
- failles (CVE) publiées par le projet PHP depuis le 1er juillet 2026
- 15
- la fin du support de sécurité de PHP 8.2, en 2026
- 31 déc.
Chronologie
Deux failles critiques, corrigées dans l'urgence
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. La première corrompt la mémoire lorsqu'une requête épuise la mémoire allouée ; la seconde réutilise un état libéré par la requête précédente. Les bulletins de sécurité, dont ceux de la DGSSI, les désignent sous le nom « PHP2Shell » : prendre le contrôle du serveur depuis une simple requête web.
La publication a été avancée. Selon la PHP Foundation, les identifiants ont fuité la veille avec une note erronée, et une vidéo de démonstration a été publiée par erreur. Les détails ayant circulé avant le correctif, il faut traiter le sujet cette semaine.
11 août – 18 sept.
Signalements de Calif, de Wiz puis d'OpenAI à l'équipe sécurité de PHP
20 oct.
Annonce d'une version de sécurité critique ; les identifiants des failles circulent avant le correctif
21 oct., 3 h 02 UTC
Cloudflare active des règles de protection sur toutes ses offres, gratuite comprise
21 oct., 14 h UTC
Versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 : les deux failles sont corrigées
21 oct.
Bulletin critique de la DGSSI (69782110/26)
22 oct.
Second bulletin de la DGSSI (69832210/26) : les risques de correctif mal appliqué
23 oct.
Avis sur une troisième faille (CVE-2026-115560), avec un contournement en attendant son correctif
26 oct.
Nouvelles versions Windows pour une faille de la bibliothèque Brotli (CVE-2026-111497)
Sources : php.net, PHP Foundation, DGSSI, Cloudflare.
Périmètre
Tout serveur qui exécute PHP pour le web
Tous les modes d'exécution sont concernés : PHP-FPM derrière Nginx ou Apache, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed (avis de php.net).
Apache avec mod_php : le risque maximal
L'avis officiel décrit une attaque démontrée sans authentification, avec les réglages par défaut, avant même que le code de l'application ne s'exécute (GHSA-w8hw-w9fx-j79w).PHP-FPM : concerné aussi
La PHP Foundation indique qu'une exécution de code y a été confirmée en passant par le code de l'application.Tous les CMS et frameworks PHP
WordPress, Drupal, Joomla, PrestaShop, Magento, Laravel, Symfony. Mettre à jour le CMS ou ses extensions ne suffit pas : la faille est dans PHP.Les sites en JavaScript, sauf back-office PHP
Un site Next.js n’est pas concerné, sauf si WordPress, Drupal ou une API Laravel ou Symfony tourne derrière lui.
Versions
Une seule protection complète : la mise à jour
Le projet PHP est catégorique : aucun contournement n'est complet. Installez la version corrigée de votre branche, ou le paquet de sécurité de votre distribution.
| Branche | Version corrigée | Fin du support | Action |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 31 décembre 2029 | Mettre à jour |
| PHP 8.4 | 8.4.27 | 31 décembre 2028 | Mettre à jour |
| PHP 8.3 | 8.3.36 | 31 décembre 2027 | Mettre à jour |
| PHP 8.2 | 8.2.35 | 31 décembre 2026 | Mettre à jour, puis passer en 8.3 ou 8.4 avant la fin de l’année |
| PHP 8.1 et avant | Aucune | Terminé | Correctif de la distribution ou d’un éditeur de support, puis migration |
Source : php.net, Supported Versions et avis du 21 octobre 2026.
Pièges
Trois erreurs qui laissent un serveur vulnérable
Le lendemain de son alerte, la DGSSI a publié un second bulletin (69832210/26) sur les erreurs qui laissent un serveur vulnérable alors que l'équipe pense l'avoir corrigé.
1. Installer le paquet sans redémarrer les services. Le fichier sur le disque est à jour, mais les processus en mémoire exécutent toujours l'ancien moteur : workers PHP-FPM, Apache avec mod_php, CGI, conteneurs en cours d'exécution. Avec Docker, télécharger la nouvelle image ne suffit pas : il faut recréer les conteneurs.
2. Prendre un contournement pour un correctif. Désactiver un réglage de PHP ou filtrer les envois de formulaires (multipart/form-data) sur un pare-feu ou un proxy limite le risque, mais seulement en attendant : ces protections peuvent être contournées.
Cloudflare le rappelle lui-même : ses règles s'ajoutent à la mise à jour, elles ne la remplacent pas (Cloudflare).
3. Appliquer un correctif non officiel ou mal validé. Pour PHP 8.1 et plus ancien, il n'y a pas de version officielle. Recompiler soi-même ou installer un paquet d'origine incertaine expose à des régressions, ou à l'oubli d'un module dont le site a besoin. Passez par votre distribution ou un éditeur de support reconnu.
Plan d'action
7 vérifications pour être vraiment protégé
Faire l'inventaire
Production, préproduction, tâches planifiées, workers, images Docker, anciens sites oubliés : tout ce qui exécute PHP.Mettre à jour PHP
Version corrigée de votre branche, ou paquet de sécurité de votre distribution. En mutualisé, demandez à l'hébergeur la version en service.Redémarrer les services
PHP-FPM, et Apache s’il utilise mod_php : sinon, l’ancien moteur reste en mémoire.Recréer les conteneurs
Docker ou Kubernetes : reconstruire l’image depuis une base corrigée, puis recréer les conteneurs.Vérifier la version vue par le site
WordPress : Outils, Santé du site, rubrique Serveur. Drupal : Rapports, Rapport d'état. La commande php -v ne prouve rien pour le site.Garder le pare-feu actif
Sur Cloudflare, l'offre gratuite est protégée d'office ; sur les offres payantes, vérifiez que les règles gérées sont en mode blocage.Chercher des traces si la mise à jour a tardé
Comptes administrateurs récents, fichiers PHP inconnus dans les dossiers d’envoi et de cache, tâches planifiées ajoutées, connexions sortantes inhabituelles.
Les commandes utiles, pour Debian et Ubuntu avec PHP 8.3 : remplacez 8.3 par votre branche. Sur Red Hat, AlmaLinux ou Rocky Linux, les services s'appellent php-fpm et httpd.
# Redémarrer les services (Debian, Ubuntu)
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
# Version du binaire PHP-FPM installé
php-fpm8.3 -v
# Date de démarrage du service : postérieure à la mise à jour ?
systemctl status php8.3-fpm | grep Active
# Date de la mise à jour du paquet
zgrep -h " upgrade php8.3-fpm" /var/log/dpkg.log* | sort | tail -1# Image officielle : récupérer l'image corrigée et recréer les conteneurs
docker compose pull
docker compose up -d --force-recreate
# Image construite par vos soins : reconstruire depuis une base corrigée
docker compose build --pull --no-cache
docker compose up -d --force-recreate
# Version dans le conteneur (remplacer « php » par le nom du service)
docker compose exec php php -v
# Kubernetes, après avoir changé l'image du déploiement
kubectl rollout restart deployment/mon-appSuites
Deux autres avis à suivre
CVE-2026-115560 touche aussi les versions corrigées le 21 octobre. Signalée le 23 octobre, elle ne se déclenche que dans une configuration précise : l'application change de format de sérialisation des sessions pendant l'exécution, alors que la progression d'envoi est active. En attendant le correctif, php.net recommande de désactiver ce réglage dans php.ini ou dans le pool PHP-FPM, puis de redémarrer. Un réglage par ini_set() ou par fichier .user.ini ne suffit pas.
; Dans php.ini
session.upload_progress.enabled = 0
; Ou dans le pool PHP-FPM (par exemple /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_flag[session.upload_progress.enabled] = offPeu de sites utilisent cette fonction : vérifiez-le avant de la désactiver, notamment sur les formulaires d'envoi de fichiers avec barre de progression.
CVE-2026-111497 ne concerne que PHP sous Windows. Le 26 octobre, php.net a publié de nouvelles versions Windows (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) pour une faille de la bibliothèque de décompression Brotli. Elle n'est atteignable que par cURL, avec la décompression automatique des réponses HTTP, qui n'est pas activée par défaut.
Tendance
Pourquoi les failles PHP se multiplient
15 failles publiées depuis le 1er juillet 2026. Selon la PHP Foundation, les chercheurs utilisent désormais l'IA pour trouver et valider des failles : la fondation cite un scan mené par Alpha-Omega avec Claude Mythos d'Anthropic plus tôt dans l'année, et l'outil Daybreak Red d'OpenAI pour valider les rapports. Elle a aussi reçu plus de 100 signalements invalides, redondants ou non reproductibles, et renforce son équipe sécurité.
Maroc
DGSSI et loi 09-08 : ce qui s'applique
Les bulletins de la DGSSI font référence. Via son centre de veille maCERT, la DGSSI publie les failles critiques : ceux du 21 et du 22 octobre s'adressent à toutes les organisations marocaines.
La loi 09-08 impose de protéger les données personnelles par des mesures techniques adaptées (voir notre guide CNDP). Laisser un serveur sans correctif après une alerte critique publique est difficile à justifier en cas de fuite.
Calendrier
Et après : PHP 8.2, PHP 8.6 et Drupal
PHP 8.2 s’arrête le 31 décembre
Plus aucun correctif de sécurité ensuite. Si vous venez de passer en 8.2.35, planifiez dès maintenant la 8.3 ou la 8.4.PHP 8.6 arrive
En version candidate : RC4 le 21 octobre, avec les deux correctifs, RC5 prévue le 5 novembre (php.net). Pas en production avant sa sortie officielle.Drupal 10 s’arrête le 9 décembre
Drupal 11 exige PHP 8.3, Drupal 12 demandera PHP 8.5 : voir notre guide sur la fin de vie de Drupal 10.
FAQ
Questions fréquentes
Mon site WordPress ou Drupal est à jour : suis-je protégé ?
Non. Les failles sont dans le moteur PHP lui-même, pas dans le CMS ni dans ses extensions. Il faut mettre à jour PHP sur le serveur, puis redémarrer les services qui l'exécutent.
Comment savoir quelle version de PHP exécute mon site ?
Dans WordPress : Outils, Santé du site, onglet Informations, rubrique Serveur. Dans Drupal : Rapports, Rapport d'état. Ces pages affichent la version utilisée par le serveur web lui-même : elles permettent aussi de vérifier que le redémarrage a bien eu lieu.
Mon site est sur un hébergement mutualisé : que dois-je faire ?
Demandez à votre hébergeur la version de PHP en service et la date de sa mise à jour, puis contrôlez-la depuis votre CMS. Si l'hébergeur propose plusieurs versions de PHP, choisissez une branche maintenue : 8.3 ou plus.
Cloudflare ou mon pare-feu applicatif suffit-il ?
Non. Cloudflare a activé des règles de protection le 21 octobre, y compris sur son offre gratuite, mais rappelle lui-même qu'elles ne remplacent pas la mise à jour. La DGSSI fait la même mise en garde : un filtrage peut être contourné.
J'utilise PHP 7.4, 8.0 ou 8.1 : que faire ?
Le projet PHP ne publie plus de version pour ces branches. Des correctifs existent pour 7.4, 8.0 et 8.1, mais ils passent par votre distribution Linux ou un éditeur de support. Il faut ensuite migrer vers une version maintenue : Drupal 11, par exemple, exige déjà PHP 8.3.
Faut-il redémarrer le serveur entier ?
Non. Il suffit de redémarrer les services qui exécutent PHP (PHP-FPM, Apache s'il utilise mod_php) et de recréer les conteneurs. Un redémarrage complet du serveur fonctionne aussi, mais n'est pas nécessaire.
La version affichée est plus ancienne que 8.3.36, mais ma distribution dit que la faille est corrigée. Qui croire ?
Votre distribution, si elle a publié un avis de sécurité pour ces CVE : les distributions appliquent souvent le correctif à leur propre version de PHP, sans changer le numéro principal. Vérifiez l'avis de sécurité de Debian, Ubuntu ou Red Hat qui correspond à votre paquet.
Que faire si je pense que mon site a été compromis ?
Isolez le serveur, conservez les journaux, changez les mots de passe et les clés d'API, puis faites appel à un spécialiste de la réponse à incident. Au Maroc, l'incident peut être signalé à la DGSSI. Si des données personnelles sont concernées, la loi 09-08 s'applique.
Sources
Sources officielles
Consultées le 27 octobre 2026
- php.net, News Archive 2026 (avis du 20, 21, 23 et 26 octobre 2026)
- GitHub, php-src : GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- GitHub, php-src : GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- php.net, Supported Versions
- PHP Foundation, « Today's PHP security release and how we're strengthening PHP security » (21 octobre 2026)
- DGSSI, bulletin 69782110/26 : vulnérabilités critiques affectant PHP (21 octobre 2026)
- DGSSI, bulletin 69832210/26 : risques de mauvaise application du patch (22 octobre 2026)
- Cloudflare, protection WAF contre les failles PHP (21 octobre 2026)
Journal des modifications
- : Publication. Faits vérifiés sur php.net, GitHub, le blog de la PHP Foundation, la DGSSI et Cloudflare.
Prochaine vérification : correctif de CVE-2026-115560 dans la prochaine version de PHP.
L'auteur
Fondateur & Directeur de VOID
Faire vérifier vos serveurs PHP ?
Nous contrôlons vos serveurs (inventaire, version réellement exécutée, redémarrages, conteneurs, réglages de contournement), puis nous appliquons la mise à jour avec un test du site avant et après.