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.
Appliquez la mise à jour dès maintenant. Le 26 octobre, la CISA a ajouté ces deux failles à sa liste des vulnérabilités exploitées. Ce conseil est judicieux, mais il laisse une lacune. Cet article traite justement de 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 de la faille, et dès le 21 octobre, Amazon constatait de nombreuses tentatives d’exploitation dans la nature. 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é compromis. Amazon affirme ne pas savoir si les tentatives qu’elle a observées auraient abouti en dehors d’un honeypot.
Le 23 octobre, CrowdStrike et Flare ne signalaient encore que des tentatives de reconnaissance et des tentatives infructueuses, dont beaucoup provoquaient le plantage de PHP plutôt que de donner le contrôle à un attaquant. Le lendemain, Adel Karimi, de Perplexity, a réussi à exécuter du code à distance sur un honeypot, et le 26 octobre , la CISA a ajouté ces deux failles à sa liste de vulnérabilités connues pour avoir été exploitées, avec une date limite fédérale de correction fixée au 29 octobre. Le test de Karimi utilisait une configuration délibérément favorable ; il démontre donc que la faille fonctionne, mais ne précise pas à quelle fréquence ce type d’attaque aboutit.
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.
Les appareils et les interfaces d'administration intégrant PHP constituent les cibles les plus susceptibles d'être compromises, et ils font rarement l'objet d'une surveillance aussi rigoureuse que les serveurs web. Flare, se faisant l'écho du rapport d'un chercheur, indique que certains intègrent PHP sans randomisation des adresses, ce qui élimine le principal obstacle pour un attaquant. Demandez à vos fournisseurs lesquels de leurs produits intègrent PHP.
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 » (accessible aux clients disposant d'une période de conservation des métadonnées d'au moins 14 jours) offre un outil d'investigation supplémentaire destiné à aider les équipes de sécurité à identifier les serveurs PHP qui auraient pu passer inaperçus, à 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.
Règles de détection des tentatives d'exploitation connues de php2shell
Vectra Match propose désormais des règles permettant de détecter les comportements des attaquants utilisant PHP2Shell, à condition que le trafic de l'attaquant soit correctement visible. Ces règles signalent les tentatives d'exploitation connues dans le trafic réseau lorsque ce dernier est visible pour nous ; elles interceptent ainsi les tentatives dès leur apparition, tandis que les détections mentionnées ci-dessus identifient les étapes suivantes. Une tentative ne signifie pas nécessairement une compromission. Une correspondance est une raison d'examiner ce serveur, mais ne constitue pas une preuve qu'il a été piraté. Cette fonctionnalité est disponible pour tous les clients de Vectra Match .
Les règles, par numéro de règle ET :
- 2072548 : ET EXPLOIT PHP php2shell — Injection de session due à une incompatibilité entre les gestionnaires (CVE-2026-109619)
- 2072549 : Vulnérabilité PHP « ET EXPLOIT » php2shell : amplification via un en-tête multipart provoquant un dépassement de mémoire (OOM) (CVE-2026-109618)
- 2072550 : Exploit ET PHP « php2shell » : contrôle de fichiers vides imbriqués provoquant un dépassement de mémoire (OOM) (CVE-2026-109618)
- 2072551 : Vulnérabilité PHP « ET EXPLOIT » (php2shell) liée à une requête multipart fragmentée sans en-tête « Content-Length » (CVE-2026-109618)
- 2072552 : ET EXPLOIT PHP php2shell - Requête POST binaire encodée en URL pour corruption de $_POST (CVE-2026-109618), commentée dans l'ensemble de règles, donc désactivée par défaut
- 2072553: Vulnérabilité PHP « ET EXPLOIT PHP php2shell » liée à une requête multipart sans en-tête « Content-Length » (CVE-2026-109618)
- 2072554 : ET EXPLOIT PHP php2shell – Injection de code dans le nom de fichier (CVE-2026-109619)
- 2072555 : ET HUNTING PHP – Manipulation de la session de progression du téléchargement générique. Il s'agit d'une règle de recherche, et non d'une règle d'exploitation ; considérez donc toute correspondance comme une piste.
- 2072556 : Exploit ET PHP php2shell : nombre excessif de parties dans une requête multipart (CVE-2026-109618)
- 2072557 : Exploit ET PHP php2shell : contrôles insuffisants sur les fichiers multipart vides (CVE-2026-109618)
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 ».