Deux failles critiques menacent PHP, le langage de programmation qui fait tourner environ 70 % des sites web. Par-delà l’alerte, quelles leçons en tirer ?

C’est l’une des alertes de sécurité les plus sérieuses de ces dernières années. En cause, PHP2Shell, un duo de failles débusquées dans le cœur de PHP. Les deux failles sont jugées « critiques ». Par-delà l’alerte, des mesures à long terme s’imposent.

« La vulnérabilité logicielle de PHP montre à quel point il est important pour les organisations d’être capables d’identifier très rapidement les vulnérabilités, de savoir où elles se trouvent et comment y réagir, commente Maxime Thiebaut, Digital Forensics & Incident Response Expert, NVISO. Nous l’avons précédemment constaté avec les vulnérabilités Log4Shell et React2Shell… »

Aujourd’hui PHP2Shell. Même scénario ? Oui. L’alerte a été donnée mardi 20 octobre par l’équipe de sécurité de PHP. Les failles, identifiées sous les références CVE-2026-109618 et CVE-2026-109619, ont chacune écopé d’un score CVSS de 9,2 sur 10.

PHP garde le mode opératoire sous scellés. D’après watchTowr, les deux brèches, référencées CVE-2026-109618 et CVE-2026-109619, permettraient d’exécuter du code à distance. Un pirate pourrait donc prendre la main sur un serveur sans le moindre identifiant. WordPress, Drupal, Joomla, Magento et PrestaShop reposent tous sur ce langage, présent sur 69,3 % des sites dont la technologie serveur est identifiée, selon W3Techs.

Des centaines de tentatives d’exploitation

La publication des correctifs de sécurité dans l’après-midi a permis aux administrateurs de commencer à sécuriser les systèmes concernés. Plusieurs versions corrigées de PHP ont été mises à disposition afin de supprimer les vulnérabilités identifiées. Cependant, estiment les spécialistes, le retour à la normale tardera.

Une affaire de plusieurs jours. « Les correctifs sont disponibles, mais la surveillance reste nécessaire », insiste Maxime Thiebaut. La publication des versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 constitue une étape majeure dans la réponse.

Pour autant, l’installation des mises à jour ne permet pas de déterminer si un serveur a été compromis avant leur déploiement. Cloudflare et ESET affirment avoir observé des centaines de tentatives d’exploitation, sans que cela permette de conclure à une campagne de compromission généralisée.

Le défi ne consiste pas simplement à installer un correctif mais à identifier tous les environnements dans lesquels PHP est utilisé, parfois à l’insu même des organisations, prévient Sophos. Les équipes de sécurité doivent prioriser les systèmes exposés à Internet, identifier les versions vulnérables et appliquer les correctifs sans délai. Les systèmes ne pouvant être corrigés doivent être isolés. Les cybercriminels agissent rapidement, notamment avec l’aide de l’IA. Une surveillance renforcée des serveurs web est donc essentielle pour détecter toute activité suspecte ou signe de compromission.

Un changement de mentalité s’impose

La priorité est désormais claire : mettre à jour PHP immédiatement, vérifier que les nouvelles versions sont réellement utilisées par les serveurs web et surveiller les éventuels signes d’exploitation antérieure.

Un changement de mentalité s’impose de toute urgence au sein des entreprises, conseille Maxime Thiebaut. « On ne peut plus se permettre aujourd’hui de ne pas savoir ce qui s’exécute dans son environnement ni où se situent ses principales dépendances sur le plan technologique. »

Et de conseiller aux entreprises de mettre en place un Vulnerability Program afin de d’identifier quels logiciels fonctionnent, où et sous quelle version ; un EASM (External Attack Software Management) afin d’identifier d’anciens systèmes qui, autrement, passeraient plus facilement inaperçus et enfin, un SBM (Software Bill of Materials), soit un inventaire de tous les logiciels et de leurs composants internes. En effet, il arrive souvent que des logiciels fonctionnent au sein des entreprises à leur insu, même de manière indirecte. C’est le cas de PHP. Or, il est indispensable d’en avoir une visibilité à tout moment.

Cette alerte illustre l’ampleur des conséquences possibles lorsqu’une vulnérabilité critique touche directement un composant aussi largement déployé que PHP. Deux failles permettant potentiellement une exécution de code à distance, des informations divulguées prématurément et un très grand nombre de serveurs potentiellement concernés imposent une réaction rapide des équipes techniques.

Le message de l’équipe officielle de PHP est sans ambiguïté : les protections temporaires peuvent limiter l’exposition, mais seule l’installation d’une version corrigée, ou d’un correctif de sécurité équivalent, permet de résoudre complètement ces deux vulnérabilités. Reste les enseignements à en tirer. PHP2Shell démontre violemment et grandeur nature ce que l’IA change en sécurité : les modèles qui débusquent des failles vieilles de quatorze ans ramènent aussi à quelques heures (voire moins) le délai entre divulgation et exploitation par les attaquants. « Des urgences comme celle-ci ne testent pas la rapidité avec laquelle les organisations lisent les avis de sécurité ; elles testent leur capacité à savoir, avant même l’alerte, où elles sont exposées », conclut Maxime Thiebaut.