PHP2Shell : la correction de Unit 42 rappelle ce qu’il faut prouver avant d’attribuer une attaque
Le 25 octobre, Unit 42 a retiré une précédente mise à jour : le lien entre une intrusion et deux failles PHP précises n’est pas confirmé. Une leçon de méthode dans une actualité cyber dominée par l’IA.
Prêt à lire l’article.
Dans cet article
Le récit d’une cyberattaque peut évoluer après sa publication. Le 25 octobre 2026, Unit 42, l’équipe de recherche de Palo Alto Networks, a corrigé son bulletin consacré à PHP2Shell. Ses chercheurs avaient observé une attaque contre une administration européenne dans un environnement utilisant une application PHP vulnérable. Ils indiquent désormais ne pas pouvoir confirmer que l’accès initial provenait des deux vulnérabilités précisément désignées par ce surnom. Leur mise à jour du 23 octobre a été retirée. Bulletin Unit 42, correction du 25 octobre.
Une observation n’établit pas toute la chaîne
Cette rectification ne permet ni de conclure que l’attaque n’a pas existé, ni de conserver comme établi le scénario initial. Elle réduit le périmètre de ce qui est publiquement confirmé. C’est particulièrement important lorsque des commentaires ajoutent à une intrusion un récit spectaculaire sur l’autonomie de l’intelligence artificielle.
Notre analyse : identifier un logiciel vulnérable, constater une activité malveillante et démontrer la porte d’entrée sont trois étapes différentes. Pour relier les événements, il faut une chronologie et des traces cohérentes. Une proximité dans le temps ne suffit pas. De même, le vocabulaire d’un outil automatisé ne prouve pas, à lui seul, qui l’a piloté ni le degré d’intervention humaine.
L’urgence technique reste documentée
L’avis officiel de PHP du 21 octobre demeure indépendant de cette attribution. Il demande de mettre à jour les installations concernées et fournit les versions corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les responsables doivent aussi vérifier les paquets proposés par leur fournisseur, qui peuvent intégrer des correctifs adaptés. Avis officiel PHP.
Une rectification sur un incident ne doit donc pas devenir une raison de différer les corrections. Inversement, une alerte technique urgente n’autorise pas à transformer chaque serveur exposé en victime certaine.
Ce que les rédactions et les organisations peuvent retenir
Pour un média, une PME ou une administration en Afrique comme ailleurs, la démarche utile consiste à séparer trois dossiers : les versions à corriger, les indices d’une éventuelle compromission et les conclusions réellement démontrées. Cette organisation facilite le dialogue avec l’hébergeur et évite qu’une hypothèse provisoire se transforme en certitude dans un compte rendu.
Il faut aussi dater les sources. Un article repris le lundi peut reposer sur un bulletin corrigé le dimanche. Dans une crise accélérée par l’IA, la fiabilité dépend autant de cette vérification éditoriale que de la vitesse de publication. Reconnaître ce qui reste inconnu améliore la réponse ; cela ne diminue pas la gravité des risques confirmés.