Le 20 octobre, des informations concernant deux failles critiques de PHP ont fuité sur Internet avant même que les correctifs ne soient prêts. PHP, le langage de script utilisé par une grande partie du Web, a avancé d'un jour la publication de son correctif et l'a diffusé le 21 octobre. Ces failles, CVE-2026-109618 et CVE-2026-109619 (surnommées « php2shell »), permettaient à un attaquant d'exécuter des commandes sur un serveur Web via PHP lui-même, sans avoir besoin de se connecter.
Installez le correctif dès maintenant. Ce conseil est judicieux, mais il laisse une lacune. Cet article porte justement sur cette lacune.
Les pirates testaient cette faille avant même que le correctif n'existe
Des correctifs sont disponibles pour les versions PHP 8.2 à 8.5, et PHP indique que les versions PHP 8.1 et antérieures ne bénéficieront pas de mises à jour. Selon une estimation, environ 884 000 serveurs de ce type seraient encore en ligne ; il s'agit d'un chiffre approximatif provenant d'une seule source.
Les « honeypots » d’Amazon ( des serveurs leurres conçus pour attirer les attaquants) ont enregistré la première tentative le 17 octobre, quatre jours avant la divulgation, et dès le 21 octobre, Amazon a qualifié ces failles d’« largement exploitées ». Cloudflare a détecté les premières attaques, et le Centre national de cybersécurité britannique a averti les organisations de procéder immédiatement à une mise à jour ou de mettre leurs systèmes hors ligne. On ignore encore combien de serveurs réels ont été piratés. Amazon affirme ne pas savoir si les tentatives qu’elle a observées auraient abouti en dehors d’un honeypot.
Chaque faille existe depuis un certain temps avant que quelqu'un ne la rende publique.
Une faille fait la une le jour où elle est annoncée, et non celui où elle apparaît. Ce sont les responsables de la maintenance de PHP qui ont détecté les premiers signes de ce problème lors d'un audit réalisé en 2024, et les pirates ont exploité cette faille avant le grand public.
Nous avons déjà observé ce schéma par le passé. Lorsque la faille Log4j a fait surface en décembre 2021, Vectra avait indiqué que les premiers signes d’une attaque étaient difficiles à détecter et que l’hypothèse la plus prudente était de partir du principe qu’au moins un serveur du parc informatique était déjà compromis. D’autres failles présentes dans les logiciels utilisés par votre entreprise se trouvent très probablement dans la même situation aujourd’hui : connues de certains, mais non divulguées. L’application de correctifs permet de remédier à celles dont vous avez connaissance. Elle ne peut toutefois rien faire pour les autres.
Ce sont les serveurs PHP qui vous manquent le plus qui comptent le plus
PHP fait fonctionner les sites WordPress, Drupal, Joomla et Magento, les panneaux de contrôle d'hébergement, ainsi que de nombreux logiciels qui ne mentionnent jamais PHP. Les serveurs que vous connaissez recevront des correctifs. Ceux que vous ne connaissez pas sont ceux que les pirates trouvent en premier, car personne ne les surveille.
Aucune équipe ne corrige tous les problèmes le jour même de la publication d'un correctif. Savoir quels serveurs sont exposés à Internet et lesquels contiennent les données les plus précieuses permet de réduire la liste des tâches en attente à une série de décisions ciblées, notamment celle de désactiver certains services jusqu'à ce qu'ils soient réparés. Sur tout serveur que vous soupçonnez d'avoir été affecté, enregistrez les journaux et une capture d'écran de la mémoire avant de le redémarrer, car un redémarrage efface toutes les traces.
Que se passe-t-il lorsqu'un serveur PHP tombe en panne ?
Un attaquant qui parvient à exécuter du code via PHP n'a généralement pas besoin d'malware. Le serveur web dispose déjà d'un shell, d'une connexion réseau et d'un accès aux fichiers ; il peut donc utiliser les outils déjà installés sur la machine pour explorer le système, trouver des identifiants et passer d'un système à l'autre. Rien ne semble anormal, car le serveur web continue de fonctionner normalement, à la seule différence qu'il utilise des commandes légèrement différentes. C'est là la première des trois lacunes de détection dont je parle : rien ne semble anormal.
Ce qui change, c'est la destination des communications du serveur. Un serveur web qui a diffusé les mêmes pages pendant des années se met soudain à atteindre des destinations qu'il n'avait jamais contactées auparavant, à envoyer des requêtes vers des adresses inconnues ou à communiquer avec des systèmes internes. Ce comportement se manifeste dans le trafic réseau, et non dans l'état des correctifs. Une vue d'ensemble du réseau permet de voir à quoi un serveur se connecte réellement, que quelqu'un surveille ou non le serveur lui-même.
Ce que « Vectra AI » peut et ne peut pas voir
Vectra AI ne s'intéresse pas vraiment à la nature du vecteur d'attaque initial. Ce qui nous importe, c'est ce qui se passe ensuite.
Aujourd'hui, c'est PHP qui fait l'actualité. La semaine prochaine, ce sera autre chose : une nouvelle faille, un appel au service d'assistance, un initié. Ce qui nous intéresse ne dépend pas de la « porte » par laquelle l'intrusion a eu lieu. Nous observons ce que fait un système une fois qu'un attaquant s'y est introduit ; nous n'avons donc pas besoin de connaître le moyen d'accès ni que la faille ait été rendue publique. C'est particulièrement important lorsque le point d'entrée est inconnu ou que la vulnérabilité n'a pas encore été annoncée.
Identification des serveurs PHP potentiels et de l'informatique fantôme
L'un des défis liés à la sécurisation d'une infrastructure PHP consiste avant tout à savoir où elle se trouve. Les applications oubliées, les serveurs non gérés et l'informatique parallèle peuvent créer des angles morts en matière de sécurité, même après la correction des vulnérabilités connues.
Vectra AITableau de bord « PHP Server Visibility » offre un outil d'investigation supplémentaire destiné à aider les équipes de sécurité à identifier les serveurs PHP susceptibles d'avoir été négligés, à l'aide d'indicateurs observés dans le trafic HTTP non chiffré, tels que .php points d'extrémité et PHPSESSID cookies. Les analystes peuvent alors vérifier si ces hôtes reçoivent également du trafic chiffré provenant de l'extérieur, ce qui permet de hiérarchiser les systèmes potentiellement exposés en vue d'une analyse plus approfondie.
Le tableau de bord n'a pas pour objectif de fournir un inventaire exhaustif des serveurs PHP. Il permet uniquement d'identifier les systèmes présentant des indicateurs observables liés à PHP ; le trafic chiffré ou une visibilité réseau limitée peuvent empêcher la détection de certains serveurs. Il sert plutôt d'outil d'aide aux workflows existants de découverte des actifs et de recherche de menaces, en aidant les analystes à mettre au jour d'éventuels systèmes informatiques non déclarés, à évaluer les risques d'exposition et à identifier les systèmes nécessitant un examen plus approfondi, même après l'application de correctifs.
Ce qu'un serveur PHP piraté révèle sur votre résilience
Autrefois, on mesurait le succès en fonction de la capacité des attaquants à s'introduire dans le système. Aujourd'hui, on évalue plutôt jusqu'où ils parviennent à aller. L'application de correctifs, une conception réseau rigoureuse, le cloisonnement du réseau en zones, le principe du « privilège minimal » et la connaissance des systèmes qui hébergent vos processus métier les plus importants permettent tous de limiter cette progression. L'historique du réseau permet de déterminer si quelqu'un a franchi la porte avant qu'elle ne se referme, et où cette personne s'est rendue ensuite.
Ces trois lacunes sont passées en revue dans le livre blanc intitulé « Mind Your Gaps in the Age of AI-Powered Attacks ».