DevOps 4 min de lecture
PHP2Shell : deux failles critiques au cœur de PHP
CVE-2026-109618 et CVE-2026-109619 permettent de prendre le contrôle d'un serveur PHP sans authentification. Ce que sont ces failles, qui est concerné et ce que disent les chiffres.
Le 21 octobre 2026, l'équipe de PHP a publié en urgence des correctifs pour deux failles critiques baptisées PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Notées 9,2 sur 10 (CVSS 4.0), elles permettent l'exécution de code à distance sans authentification. Et elles ne touchent pas un CMS ou un framework en particulier, mais le moteur PHP lui-même : potentiellement, tout site écrit en PHP.
Deux bugs de mémoire dans le cycle de vie d'une requête
Pour servir une page, PHP prépare un état propre à chaque requête, puis le nettoie à la fin. Les deux failles se logent dans ce cycle :
CVE-2026-109618 — quand une erreur de mémoire insuffisante interrompt une requête, PHP peut abandonner des données à moitié initialisées ; la phase de nettoyage les traite ensuite comme si elles étaient valides ;
CVE-2026-109619 — PHP peut garder un état lié à une requête alors que la mémoire correspondante a déjà été libérée. Si le même processus traite la requête suivante, cet état périmé peut être lu avant d'être réinitialisé. L'avis officiel signale aussi une possible fuite d'informations en mémoire.
Dans les deux cas, il s'agit d'utilisation de mémoire libérée (use-after-free) : un attaquant capable de provoquer ces situations peut corrompre la mémoire du processus et y faire exécuter son propre code.
Qui est concerné ?
Tous les modes d'exécution qui servent des pages web sont dans le périmètre : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP considère mod_php comme le plus exposé. Aucune option de configuration ne supprime complètement le risque : seule la mise à jour corrige.
BrancheVersion corrigéePHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35PHP 8.1 et antérieuresaucune version officielle
Pour 8.1, 8.0 et 7.4, il n'existe que des correctifs source non publiés en version officielle, et les builds patchés de certaines distributions ou de certains hébergeurs.
Une divulgation précipitée
11 août : la cause du problème est signalée à l'équipe sécurité de PHP, d'autres vecteurs d'attaque suivent le 24 août ;
22 octobre : date prévue de divulgation coordonnée, sous embargo ;
20 octobre : un message anonyme annonce les failles publiquement ; PHP avance la publication ;
21 octobre, 14 h UTC : sortie des versions corrigées.
La PHP Foundation a reconnu que le problème de fond avait été relevé lors d'un audit dès 2024, et a parlé d'une défaillance structurelle de son processus de sécurité.
Les chiffres
PHP, c'est (presque) tout le web
~70 % des sites dont le langage serveur est connu tournent en PHP (W3Techs, août 2026) ;
parmi eux, 62,5 % sont en PHP 8, 29,4 % encore en PHP 7 et 8 % en PHP 5 ;
au sein de PHP 8, 8.0 et 8.1 représentent encore près d'un quart des installations (17,8 % + 7 %).
Autrement dit, en recoupant ces chiffres, plus de la moitié des sites PHP tournent sur une branche qui ne recevra pas de correctif officiel.
Des millions de serveurs exposés
Censys a compté 2,58 millions d'hôtes PHP accessibles sur Internet le 21 octobre, dont ~1,57 million annonçant une version non corrigée ; le lendemain, il en suivait près de 3 millions ;
Black Kite, via Shodan, recense ~1,9 million d'hôtes PHP exposés ; parmi ceux qui affichent leur version, 72,5 % sont sur des branches en fin de vie.
Des attaques en millions, aucune réussite confirmée
Selon Cloudflare, les tentatives sont passées de quelques milliers dans les 10 heures précédant l'annonce à des dizaines de milliers dans les 45 minutes suivantes, des centaines de milliers en 2 heures, puis des millions le 22 octobre ;
une partie de ces tentatives vise à enrôler les serveurs dans une variante du botnet Mirai ;
au 22 octobre, aucune exploitation réussie n'était confirmée : la CISA n'avait rien observé et n'avait pas inscrit les failles à son catalogue des vulnérabilités activement exploitées. Les preuves de concept publiques ne fonctionnent que sur des combinaisons très précises de système, de version et de serveur web.
Des millions de tentatives, aucune réussite confirmée… pour l'instant. Les exploits s'améliorent vite : la seule réponse fiable reste de passer en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
Sources
Julien DechavanneDéveloppeur web