Failles de sécurité PHP : Pourquoi de nombreux sites web ont été mis hors ligne de manière si soudaine

Sites officiels des préfectures, de la Commission nationale de l’informatique et des libertés (Cnil), de la Banque de France… À l’heure où nous écrivons ces lignes, de nombreux sites web affichent un message d’erreur ou de maintenance. En cause, la détection de deux vulnérabilités critiques affectant le langage de programmation PHP, contraignant les administrateurs à mettre leurs sites temporairement hors ligne afin de se protéger des attaques et d’appliquer un correctif. Ce dernier a été publié par la PHP Foundation le 21 octobre à 16 h.

Deux vulnérabilités d’exécution de code à distance…

Servant principalement à créer des pages web dynamiques et des applications côté serveur, le langage open source PHP alimente près de 70% des sites web dans le monde. Les systèmes de gestion de contenu (CMS) WordPress, Drupal ou Joomla tournent notamment sur PHP.

Baptisées PHP2Shell, ces deux vulnérabilités se caractérisent en premier lieu par une échelle de sévérité particulièrement élevée : 9,2 sur 10 (le seuil de criticité est atteint à partir de 9). La première (CVE-2026-109618) peut théoriquement permettre à un acteur malveillant d’exécuter du code à distance lorsqu’une requête atteint la limite mémoire de PHP au mauvais moment. Des données internes restent partiellement initialisées et peuvent être traitées comme valides, provoquant une corruption de mémoire insuffisante (OOM).

La seconde (CVE-2026-109619) est liée à une erreur fatale qui pourrait laisser l’état interne pointant vers une zone mémoire ayant appartenu à une requête précédente. De fait, une requête ultérieure traitée par le même processus pourrait utiliser cette mémoire libérée et permettre à un cybercriminel d’exécuter du code à distance sur Apache avec le module mod_php.

… découvertes à l’aide de l’intelligence artificielle

Ensuite, ces vulnérabilités ont été découvertes à l’aide de… l’intelligence artificielle. Le 11 août, la société de cybersécurité américaine Calif signale une première faille en utilisant GPT-5.6 Sol d’OpenAI. La découverte a été faite dans le cadre de l’initiative Patch the Planet de l’entreprise de Sam Altman, visant notamment à débusquer les vulnérabilités présentes dans les logiciels libres. Wiz a signalé de son côté la seconde faille une dizaine de jours plus tard, en utilisant GPT-5.6 Sol mais aussi Gemini 4 Argon de Google. Selon Abstract Security, les versions affectées remontent à PHP 5.4, traduisant une présence du code vulnérable depuis plus d’une décennie.

“La divulgation coordonnée de ces vulnérabilités a bien fonctionné jusqu’à deux jours avant la date de publication prévue”, dénonce la PHP Foundation dans un communiqué publié le 21 octobre. Elle explique que la veille vers 17 h, les identifiants CVE ont commencé à circuler avec un score CVSS erroné de 10 sans détails techniques, la contraignant à avancer la publication du correctif au 21 octobre à 16 h, soit 24 heures en avance. “Les distributeurs étaient encore en train de distribuer le correctif, précise la PHP Foundation. Une publication immédiate aurait empêché de nombreux utilisateurs de mettre à jour facilement.”

Sans détails sur les composants affectés et sur le chemin d’attaque, cette fuite pourrait sembler anecdotique : elle a néanmoins suffi à provoquer un emballement mondial en quelques heures et à donner aux cybercriminels des raisons de “chercher” la faille. D’autant que dans les heures qui ont suivi, de nouvelles fuites ont été repérées.

Des détails sur les vulnérabilités mis en ligne avant la publication des correctifs

Calif a ainsi publié par erreur une vidéo mardi soir sur un PoC fonctionnant contre plusieurs cibles avec des détails limités sur les vulnérabilités. Bien qu’elle ait été supprimée, des extraits ont circulé sur les réseaux sociaux. “Le 21 octobre à 9 h 41, soit plus de six heures avant la publication coordonnée, Chainguard a unilatéralement enfreint l’embargo et publié des images compilées contenant le correctif, charge aussi la PHP Foundation. Un attaquant pouvait désormais étudier le correctif sous forme binaire (…). Cette action a bafoué des semaines de travail en vue d’une divulgation coordonnée.”

Chainguard, spécialisée dans la sécurisation de la supply chain, a nié toute divulgation précoce via le canal coordonné. “Nous avons appris que quelque chose se passait dans PHP vendredi par l’un des chercheurs qui avait découvert le problème, écrit sur LinkedIn Dan Lorenc, CEO de Chainguard. Ce soir-là, nous avons pu découvrir indépendamment le même problème en utilisant notre harnais et un frontier model avec le prompt basique ‘Trouver de mauvaises vulnérabilités dans PHP’”.

La PHP Foundation a aussi sa part de responsabilité : un audit de sécurité réalisé par Quarkslab en 2024 a fait ressortir de premiers signes de la vulnérabilité à l’origine de la faille CVE-2026-109618. “En 2024, une exploitation potentielle de cette vulnérabilité a été envisagée, mais aucun vecteur concret n’a été trouvé et d’autres problèmes plus importants ont éclipsé ces préoccupations”, justifie-t-elle.

Amazon et Cloudflare ont observé de nombreuses tentatives d’exploitation

Quelques heures avant la publication des correctifs, Amazon Threat Intelligence dit avoir observé plusieurs tentatives d’exploitation de PHP2Shell, avec des charges utiles et choix d’infrastructure d’anonymisation différents suggérant l’implication de plusieurs acteurs. “Au cours des 10 heures qui ont précédé l’annonce, nous avons constaté sur l’ensemble du réseau des milliers de tentatives d’exploitation de cette faille, a déclaré sur X Matthew Prince, CEO de Cloudflare. Ce chiffre est passé à plusieurs dizaines de milliers dans les 45 minutes qui ont suivi l’annonce et s’élève désormais à plusieurs millions.” Pour l’heure, aucune compromission n’a été confirmée.

Il est donc recommandé de mettre à jour au plus vite les équipements et logiciels concernés. Le support n’est cependant plus assuré pour les versions de PHP antérieures à 8.2. Dans son alerte publiée le 21 octobre, le CERT-FR recommande donc d’isoler les équipements affectés puis de procéder à la migration vers une version maintenue et avec les derniers correctifs de sécurité.

Prudence, également, à appliquer les correctifs de manière exhaustive. “Une entreprise peut corriger son application web principale et se sentir protégée tout en passant à côté d’une application éditeur ou d’une image conteneur livrée avec une version vulnérable de PHP, appuie Matt Psencik, Threat Research Engineer chez Tanium. (…) Les équipes doivent identifier les binaires et versions de PHP réellement présents plutôt que de supposer qu’une mise à jour du système d’exploitation couvre tout.”