L’industrie de la cybersécurité repose depuis longtemps sur une règle non écrite : lorsqu’une vulnérabilité est découverte, les parties prenantes signent des accords de confidentialité, les défenseurs élaborent discrètement des correctifs, l’annonce est faite de manière coordonnée à une date fixée, et les administrateurs déploient les mises à jour de manière échelonnée. Cette mécanique bien huilée a garanti la stabilité de l’écosystème pendant des décennies.
Le 21 octobre 2026, cette mécanique s’est brisée. Plusieurs heures avant l’heure prévue pour la publication des correctifs officiels, les systèmes de surveillance de Cloudflare ont enregistré d’importantes vagues d’attaques bien réelles sur le réseau public. Les assaillants n’ont pas attendu que les défenseurs changent les serrures.
Environ 21 heures auparavant, les détails techniques de deux failles majeures avaient fuité sur des forums de discussion informatique. Baptisée « PHP2Shell », la tourmente a plongé les administrateurs de serveurs du monde entier dans le désarroi. Bien que la publication initiale ait été supprimée dans la foulée, plusieurs cabinets de sécurité ont promptement vérifié l’efficacité de l’exploit. Les équipes de défense n’ont accédé aux détails qu’après que les attaquants avaient déjà commencé à s’en servir sur le terrain.
Des assauts déclenchés avant l’arrivée des correctifs
Les deux vulnérabilités portent les références officielles CVE-2026-109618 et CVE-2026-109619. Le projet PHP leur a attribué une sévérité CVSS v4.0 de 9.2, tandis que l’institut de recherche watchTowr a frappé un grand coup en leur accordant le score maximal de 10.0. À ce niveau de criticité, tout serveur exposé sur Internet encourt un risque immédiat de prise de contrôle totale.
La fuite s’est produite le 20 octobre à 15 h 20 UTC, lorsqu’un utilisateur dénommé petecooper a partagé sur un forum communautaire l’annonce anticipée des correctifs. Dans les heures qui ont suivi, des outils de test signés Calif Research ont circulé sur les réseaux techniques, les ingénieurs confirmant que le code d’exploitation fonctionnait parfaitement en environnement réel. Le 21 octobre à 07 h 43 UTC, Cloudflare a confirmé avoir intercepté les premières tentatives d’exploitation sur Internet — soit plus de six heures avant la fenêtre officielle de publication. Les correctifs n’ont finalement été diffusés comme prévu qu’à 14 h 00 UTC (22 h 00 heure de Pékin).
Un intervalle de vulnérabilité de seize heures s’est donc creusé entre la divulgation de la méthode d’attaque et les premières offensives massives, laissant les administrateurs totalement démunis.
Un simple envoi de fichier suffit à compromettre le serveur
Cette vulnérabilité sommeillait au cœur d’un mécanisme fondamental du Web : le téléversement de fichiers. Dès qu’un internaute modifie sa photo de profil, transmet une pièce jointe ou valide un formulaire contenant un fichier, le navigateur formate les données au standard multipart/form-data et les confie directement au moteur d’exécution en arrière-plan.
Le problème réside précisément dans la routine bas niveau de PHP chargée de décortiquer ces requêtes multipart. En forgeant un paquet délibérément malformé, un assaillant provoque une corruption de mémoire qui lui permet d’exécuter des commandes système arbitraires sur la machine cible. La société de sécurité Sansec a résumé l’attaque sans détour : une simple requête POST non authentifiée suffit amplement — aucun compte utilisateur, aucun privilège et aucun prérequis ne sont nécessaires.
Le facteur le plus redoutable concerne l’étape à laquelle l’incident se produit. La corruption intervient avant même que le code applicatif du site ne commence à s’exécuter. Que WordPress, WooCommerce ou Magento aient implémenté les meilleures pratiques de sécurité n’y change rien. Alors que près de 40 % des sites web mondiaux s’appuient sur WordPress, tout serveur exécutant PHP avec le téléversement de fichiers activé se trouve directement sous le feu de l’attaque.
Figure : FAQ officielle publiée par l’entreprise de cybersécurité Tenable au sujet des deux failles critiques d’exécution de code à distance. Source : Tenable
Les pages de maintenance ne constituent aucun rempart
Face à une urgence sécuritaire, les administrateurs ont pour réflexe de basculer leur site en mode maintenance, en affichant une page d’indisponibilité temporaire pour filtrer les visiteurs. Face à PHP2Shell, ce bouclier est inopérant. La page de maintenance étant elle-même générée et servie par le moteur applicatif PHP, la requête malveillante atteint le parseur de l’interpréteur avant que la logique applicative n’intervienne. Dès lors que le processus de service PHP reste actif, l’attaque porte ses fruits.
Pour espérer survivre en attendant les correctifs, les organisations ont dû accepter de lourds sacrifices opérationnels. Les parades immédiates étaient très restreintes : bloquer purement et simplement toutes les requêtes de téléversement au niveau de Nginx ou d’Apache — au prix de neutraliser le changement d’avatars ou l’ajout de fiches produits pour les commerçants ; verrouiller le pare-feu du serveur d’origine pour n’autoriser que les adresses IP sortantes de Cloudflare et contraindre le trafic à passer par le WAF — une parade inefficace si l’adresse IP publique réelle du serveur a déjà fuité par le passé ; ou bien stopper purement et simplement le service PHP et le remplacer par des pages HTML statiques de secours.
Au niveau de la configuration php.ini, deux leviers de mitigation temporaires ont été préconisés : désactiver session.upload_progress.enabled et activer session.use_strict_mode. L’équipe de publication de PHP a toutefois insisté sur le fait que ces réglages ne font que restreindre certaines surfaces d’attaque et ne sauraient en aucun cas remplacer la mise à jour du moteur PHP.
Quelques heures avant la parution des correctifs, le Parlement néerlandais, le Centre national de cybersécurité des Pays-Bas (NCSC-NL) et le média technologique Tweakers ont choisi la mesure la plus radicale : couper totalement l’accès à leurs sites web. Comme le résumait Dane Knecht, directeur technique de Cloudflare, les règles de filtrage d’un WAF ne constituent qu’un garrot de fortune.
Des millions de machines anciennes privées de correctifs
Si une mise à jour logicielle suffisait à régler le problème, la situation ne serait pas aussi alarmante. L’expert en sécurité Silas Cutler a estimé à environ 1,3 million le nombre d’instances PHP directement accessibles depuis l’Internet public, constituant autant de cibles immédiates pour les scanners automatisés.
La véritable impasse tient au fait qu’une part considérable de ce parc ne recevra jamais le moindre correctif officiel. La politique de maintenance du projet PHP ne couvre que les branches en cours de support actif : les correctifs n’ont ainsi été publiés que pour PHP 8.2 et ses versions ultérieures. Des branches historiques comme 5.x, 7.x, 8.0 et 8.1 sont en fin de vie (EOL) depuis plusieurs années. Pourtant, elles font encore tourner en toute discrétion d’innombrables applications d’entreprise au sein d’images de conteneurs figées que personne n’ose toucher.
Dans les couches applicatives supérieures, la mobilisation a été exemplaire : WordPress est passé en 7.1.3, Drupal a publié la 11.4.10, Laravel la 13.36.0, et MediaWiki, phpBB, Magento ou Symfony ont tous proposé des correctifs dans la journée. Mais tant que l’interpréteur sous-jacent demeure vulnérable, les pansements appliqués aux étages supérieurs ne peuvent colmater la brèche.
L’écosystème Linux d’entreprise a également subi des frictions notables. Le dépôt tiers très populaire Remi’s RPM repository a fait savoir qu’il ne fournirait pas de paquets le jour même. Les utilisateurs de distributions de la famille RHEL ont dû choisir entre attendre les rétroportages des distributions ou compiler les sources directement sur leurs serveurs de production.
Figure : Pilier de 40 % des sites web depuis trente ans, PHP a vu les fondations de son analyseur de requêtes ébranlées par deux failles critiques. Source : BleepingComputer
La capacité de déploiement devient la nouvelle frontière de sécurité
Le modèle de sécurité de l’open source s’est toujours appuyé sur une vision idéale : une concertation étroite, des correctifs délivrés à l’heure convenue et des administrateurs appliquant les correctifs avec méthode. L’affaire PHP2Shell a pulvérisé cet équilibre précaire.
Sansec et les autorités de sécurité néerlandaises avaient alerté dès avant la parution : dès la publication des sources, les assaillants mettraient moins de 15 minutes pour rétroconcevoir le correctif et lancer des balayages à grande échelle. La réalité s’est avérée pire encore : la fuite technique préalable a permis aux premières attaques de frapper six heures avant la parution des correctifs officiels.
À l’autre extrémité de la chaîne, les rouages de la distribution logicielle sont d’une lenteur désespérante. Une fois le code disponible, il faut encore que les distributions assemblent et testent les paquets binaires, puis que les entreprises planifient des plages de maintenance nocturnes — un processus qui demande fréquemment plusieurs jours voire des semaines. Quant aux versions obsolètes délaissées, aucun code correctif n’existera jamais.
La véritable fracture entre assaillants et défenseurs ne réside plus dans l’aptitude à concevoir un correctif de sécurité, mais dans la capacité logistique à l’acheminer sur chaque machine en production. Tant que la dette technique des versions périmées et l’inertie opérationnelle perdureront, même le correctif le plus prompt ne fera que constater les dégâts causés par la première vague d’attaques.
Liens de référence :
- Annonce officielle de sécurité du projet PHP
- Rapport d’analyse technique de Sansec
- FAQ sur la vulnérabilité par Tenable
- Rapport de recherche en renseignement sur les menaces par watchTowr
- Bulletin d’alerte sur les menaces réseau par Cloudflare
