Une alerte mondiale, mais pas une apocalypse confirmée
La formule « 70 % des sites web » renvoie à PHP, le langage côté serveur qui fait fonctionner une immense partie du web, notamment de nombreux sites WordPress, applications métiers anciennes, boutiques en ligne et outils internes. Dans son analyse du 23 octobre, CrowdStrike rappelle que PHP alimente environ 70 % des sites web, ce qui explique pourquoi deux failles dans son moteur d’exécution ont immédiatement pris une dimension mondiale .
Ces vulnérabilités sont suivies sous les identifiants CVE-2026-109618 et CVE-2026-109619. Ensemble, elles sont surnommées PHP2Shell. Le 23 octobre, l’équipe sécurité de Salesforce a résumé l’enjeu: le projet PHP a publié des versions corrigées le 21 octobre, et les deux failles peuvent permettre l’exécution de code à distance sans authentification dans les déploiements affectés, avec des scores CVSS v4.0 annoncés à 9,2 .
Autrement dit, dans certaines configurations vulnérables, un attaquant n’a pas nécessairement besoin d’un mot de passe, d’un compte utilisateur ou d’une extension compromise pour tenter d’exécuter du code sur un serveur web. C’est précisément ce type de faille qui fait réagir brutalement les équipes de défense.
Il faut toutefois distinguer exposition et compromission. Dire que PHP est extrêmement répandu ne signifie pas que 70 % des sites ont été piratés. Cela signifie que le composant touché n’est pas un module isolé, un thème, une extension ou un fournisseur précis, mais une couche d’exécution utilisée par des millions de services. CrowdStrike indique que les failles touchent plusieurs versions de PHP et peuvent être exploitées dans des produits utilisant des versions vulnérables, sous certaines conditions .
Pourquoi PHP2Shell est jugé si grave
La gravité tient d’abord à la possibilité d’exécution de code à distance. Dans la sécurité des systèmes exposés à Internet, c’est l’une des catégories de vulnérabilités les plus redoutées, car elle peut ouvrir la voie à la prise de contrôle du serveur, à l’installation d’un web shell, au vol de données ou à un mouvement latéral dans l’infrastructure.
Salesforce précise aussi que CVE-2026-109619 peut exposer de la mémoire, ce qui ajoute un risque de fuite d’informations sensibles traitées par le processus PHP, même si l’attaquant ne parvient pas à obtenir une exécution de code fiable .
L’état actuel de l’exploitation reste cependant nuancé. The Record a rapporté le 23 octobre que de grandes entreprises observaient une forte hausse des tentatives d’exploitation, mais que de nombreux experts considéraient que beaucoup de preuves de concept publiques ne fonctionnaient que dans des conditions de laboratoire idéales . Il y a donc une différence majeure entre détecter des scans massifs et constater des compromissions massives.
CrowdStrike arrive à une conclusion comparable. Son équipe Counter Adversary Operations indique ne pas avoir observé, au moment de sa publication, d’exploitation réussie dans la nature ni dans ses environnements de leurres, et souligne que de nombreuses preuves de concept analysées provoquent des crashs plutôt qu’une exécution de code fiable . L’entreprise ajoute que transformer un crash en exploit stable n’est ni trivial ni garanti, notamment parce que l’attaquant doit souvent s’adapter à la version précise de PHP, aux paquets, aux conteneurs et à l’application ciblée .
C’est le point rassurant. Le point inquiétant est que « difficile à exploiter » ne veut pas dire « sans danger ». The Record cite des spécialistes qui avertissent que les attaquants sont déjà en train de collecter des informations sur les serveurs exposés, afin de disposer de listes de cibles si une technique plus fiable devient disponible .
Ce qu’il faut corriger concrètement
Les versions corrigées citées par Salesforce sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 . Les organisations qui exploitent des sites, applications ou logiciels tiers basés sur PHP doivent identifier ces environnements et appliquer les mises à jour adaptées au plus vite .
Il serait dangereux de réduire l’affaire à WordPress. WordPress est très répandu, mais la couche vulnérable est PHP lui-même. Cela peut donc concerner Drupal, Joomla, Magento, des applications PHP maison, des interfaces d’administration, de vieux intranets, des images de conteneurs oubliées ou des appliances qui embarquent PHP. Des contributeurs de SANS recommandent de commencer par les systèmes exposés à Internet, puis de rechercher le PHP « hérité » que l’organisation ne pense pas toujours posséder, notamment dans les interfaces de gestion, les produits fournisseurs et les images obsolètes .
SANS insiste également sur la difficulté des environnements anciens. Les organisations qui utilisent encore PHP 7 peuvent devoir mettre à jour ou désactiver certains composants incompatibles afin de rejoindre une version supportée . C’est pourquoi PHP2Shell est devenu autant un test d’inventaire qu’un test de rapidité de patch. Beaucoup d’équipes découvrent que la question la plus difficile n’est pas « comment corriger? », mais « où PHP est-il réellement installé? ».
Où en est l’exploitation?
Les signaux disponibles sont contradictoires, mais pas incohérents. The Record rapporte que plusieurs grandes entreprises ont observé une explosion des tentatives d’exploitation, tout en notant que des dizaines d’experts n’ont pas vu d’exploitation massive réussie . Le même article indique que Sophos a retiré une première affirmation d’exploitation réussie et a ensuite décrit seulement un petit nombre de tentatives échouées .
Des activités liées à des botnets ont également été signalées, notamment autour de Potassium et de botnets de type Mirai, mais ces observations s’inscrivent encore dans le schéma général des scans, essais et exploitations inabouties plutôt que dans la preuve d’une compromission à grande échelle . CrowdStrike parle, lui aussi, de tests, de sondes et de tentatives infructueuses, sans exploit public pleinement industrialisé permettant une exploitation massive .
Il ne faut pourtant pas attendre une preuve spectaculaire pour agir. Dans de nombreux incidents, la phase la plus dangereuse commence lorsque les défenseurs relâchent leur attention. The Record indique que des chercheurs de VulnCheck ont développé une technique permettant de contourner l’ASLR, une protection mémoire importante, ce qui montre qu’un obstacle majeur peut être dépassé même si cette capacité n’est pas largement publique .
Les pare-feu applicatifs aident, mais ne remplacent pas les correctifs
Plusieurs fournisseurs de cloud et de sécurité ont réagi avec des règles de protection temporaires, parfois qualifiées de correctifs virtuels. AWS a indiqué dans une mise à jour du 23 octobre que son groupe de règles managées pour les applications PHP inclut des protections pour CVE-2026-109619 et CVE-2026-109618, et que les clients utilisant la version par défaut bénéficient de ces règles sans action supplémentaire .
Mais AWS insiste sur un point essentiel: l’application du correctif PHP reste la seule correction complète, les règles WAF n’étant qu’une défense en profondeur pendant la fenêtre de mise à jour . Un pare-feu applicatif voit des requêtes HTTP; il ne comprend pas toute la mémoire interne d’un worker PHP, l’état du processus ou les subtilités de configuration côté serveur.
AWS décrit les vulnérabilités comme atteignant PHP avant même l’exécution du code applicatif, ce qui explique pourquoi un simple contrôle dans le CMS ou une extension de sécurité ne suffit pas . Si le moteur PHP sous-jacent reste vulnérable, la base technique demeure fragile.
Pour les systèmes qui ne peuvent pas être corrigés immédiatement, des mesures temporaires peuvent réduire le risque. AWS met l’accent sur les requêtes multipart, certains motifs dans le corps des requêtes et le champ PHP_SESSION_UPLOAD_PROGRESS . SANS conseille aussi de restreindre l’accès aux systèmes non corrigés et d’obtenir des fournisseurs des dates précises de correction pour les produits qui embarquent PHP .
Pourquoi les équipes cyber sont sous pression
L’inquiétude ne vient pas seulement de PHP2Shell. Elle vient de la vitesse à laquelle l’écosystème des vulnérabilités évolue. CrowdStrike note que PHP2Shell a attiré une forte attention médiatique et industrielle avant et juste après sa divulgation, en raison de la portée de PHP et de la sévérité des failles . Les experts cités par SANS décrivent une course contre la montre, les acteurs malveillants pouvant analyser les correctifs publiés pour développer leurs propres exploits .
La charge opérationnelle est énorme. Les équipes doivent inventorier PHP, mettre à jour les versions supportées, isoler les systèmes impossibles à corriger, vérifier les journaux, surveiller les comportements anormaux des processus PHP, interroger les fournisseurs et répondre à des dirigeants inquiets par les gros titres. SANS conseille même aux responsables de réduire le bruit, de formaliser les décisions de risque et d’organiser des rotations, plutôt que d’épuiser les équipes avec des points de situation permanents .
L’incident rappelle une réalité inconfortable: une infrastructure open source très utilisée peut être à la fois robuste, mature et fragile. PHP est partout parce qu’il fonctionne, parce qu’il est simple à déployer et parce que des écosystèmes entiers en dépendent. Mais cette ubiquité transforme une faille de runtime en problème mondial de coordination.
Ce que les entreprises et les utilisateurs doivent faire
Pour les propriétaires de sites, la première question est précise: quelle version de PHP sert réellement chaque point d’entrée public? Un tableau de bord WordPress, Drupal ou Magento à jour ne prouve pas que le moteur PHP soit corrigé. Il faut vérifier la version d’exécution ou le correctif rétroporté par le fournisseur.
Pour les entreprises, les priorités sont claires: corriger d’abord les systèmes PHP exposés à Internet, isoler ceux qui ne peuvent pas l’être, exiger des fournisseurs une position écrite sur PHP2Shell, et examiner les journaux avant et après la divulgation. The Record rapporte que les experts s’attendent à ce que les attaquants améliorent leurs outils; les défenseurs doivent donc considérer la période actuelle comme une fenêtre de répit limitée, non comme une fin d’alerte .
Pour les utilisateurs ordinaires, les gestes utiles restent indirects: se méfier des redirections suspectes, des demandes de connexion inhabituelles, des courriels de réinitialisation inattendus et des changements soudains sur les sites utilisés. Mais la responsabilité principale incombe aux opérateurs de sites, hébergeurs et fournisseurs de logiciels, car PHP2Shell est une vulnérabilité côté serveur.
Le titre est alarmant parce qu’il reflète un risque réel: une faille dans une technologie au cœur d’une grande partie du web a placé la cybersécurité mondiale en état d’urgence. La lecture la plus juste n’est toutefois pas que l’Internet est déjà tombé. C’est que les défenseurs disposent d’un délai court et incertain pour consolider les fondations avant que les scans d’aujourd’hui ne deviennent les compromissions de demain.