TL;DR : L’essentiel
- Les attaquants ont commencé à cibler les serveurs quatre jours avant la publication des correctifs officiels, en exploitant des données ayant fuité pour lancer des sondages automatisés depuis des réseaux anonymisés.
- Les chercheurs en sécurité ont démontré qu’un exploit pouvait contourner la protection de mémoire sur les configurations de production, ouvrant la voie à une exécution de code arbitraire à distance.
- Plusieurs gouvernements et établissements de santé ont choisi d’éteindre préventivement leurs services web afin de se prémunir contre d’éventuelles intrusions avant l’application complète des mises à jour logicielles.
- La Fondation PHP a signalé une troisième vulnérabilité liée au traitement des téléversements de sessions, nécessitant une désactivation temporaire de ce paramètre avant l’arrivée du prochain cycle de correctifs réguliers.
Les failles critiques PHP2Shell permettent l’exécution de code à distance sur les serveurs web exécutant PHP sans nécessiter d’authentification préalable, exposant des dizaines de millions de services internet à travers le monde. Le moteur PHP alimente près de 80% des sites web mondiaux, des systèmes de gestion de contenu comme WordPress jusqu’aux parcs d’hébergement partagé. L’apparition soudaine de ces brèches de sécurité dans le code source du langage a déclenché une vague d’activité hostile immédiate à l’échelle planétaire.
Les cyberattaquants ciblent les serveurs avant la diffusion des correctifs
Les premières tentatives d’exploitation ont précédé les annonces officielles du projet open source. Selon les données d’Amazon Threat Intelligence relayées par BleepingComputer, des assaillants ont sondé des serveurs pièges dès le 17 octobre 2026, soit quatre jours avant le déploiement des correctifs pour CVE-2026-109618 et CVE-2026-109619. Ces manœuvres provenaient d’un réseau commercial d’anonymisation, suggérant une fuite préalable des détails techniques avant la fin de l’embargo de sécurité.
Dès la levée de l’embargo le 21 octobre 2026, le volume des attaques a connu une accélération fulgurante. Les capteurs de Cloudflare ont comptabilisé des dizaines de milliers de requêtes malveillantes en 45 minutes, avant d’atteindre plusieurs millions le lendemain, comme l’a rapporté SecurityWeek. Pourtant, la majorité des charges utiles observées n’étaient pas fonctionnelles : elles se limitaient à des balayages automatisés, des pannes logicielles provoquées ou des démonstrations de faisabilité défaillantes partagées sur GitHub.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Cette vague d’attaques s’est accompagnée d’une mobilisation immédiate des équipes informatiques. Selon les relevés de Google Trends, l’indice d’intérêt mondial pour le mot-clé « PHP » a bondi jusqu’à la valeur maximale de 100 le 22 octobre 2026, enregistrant une progression de 70% par rapport au mois précédent pendant que les responsables système cherchaient des solutions de remédiation d’urgence.
Le verrouillage de la mémoire complique la prise de contrôle à distance
L’obstacle technique majeur pour les assaillants réside dans la randomisation de l’espace mémoire, une protection intégrée aux systèmes d’exploitation qui change aléatoirement l’emplacement des instructions en mémoire vive. Sans connaître cette adresse précise, un assaillant qui tente d’injecter du code déclenche généralement un simple plantage de l’application. Cette barrière explique pourquoi les firmes de sécurité n’ont constaté aucune exécution de code aboutie lors des premières vagues d’attaques massives, comme le précise SecurityAffairs. Des variantes du réseau de robots Mirai, notamment la souche Potassium, tentent déjà de distribuer des fichiers malveillants sous Linux, mais leurs assauts ont été bloqués par les contre-mesures en place.
Cette défense commence toutefois à vaciller face aux travaux des spécialistes offensifs. L’équipe de VulnCheck a réussi à contourner cette sécurité sur des architectures 64 bits en combinant les deux failles pour provoquer une fuite de mémoire avant d’exécuter du code arbitraire, d’après les détails recueillis par The Register. Même avec les options de production recommandées qui masquent l’affichage des messages d’erreur, leur méthode parvient à ses fins, ce qui démontre qu’une protection résidente en mémoire ne saurait remplacer l’application immédiate du correctif fourni par les développeurs.
Analyse
Dans le monde de la cybersécurité, cette semaine a été rythmée par les vulnérabilités critiques qui ont touché PHP, ce vieux langage de développement intégré dans environ 70% des applications sur le web. Comme un tremblement de terre, il est maintenant possible de s’attendre à de nouvelles répliques, comme les nouvelles failles qui viennent de s’ajouter en fin de semaine. Il est dorénavant établi que des acteurs malveillants ont commencé à sonder les serveurs affectés par deux vulnérabilités critiques d’exécution de code à distance (RCE) dans PHP quatre jours avant les correctifs, mais il faut que l’analyse se poursuive pour comprendre la vraie dangerosité de ces failles et en particulier si des exploitations en masse sont possibles, car le recul manque bien sûr encore aujourd’hui. À suivre donc.
Une nouvelle faille s’ajoute et prolonge l’incertitude sur les serveurs
À peine le déploiement des premiers correctifs amorcé, une nouvelle vulnérabilité distincte est venue compliquer la tâche des administrateurs. Référencée sous le code CVE-2026-115560, cette faille permet également une exécution de code dans des configurations spécifiques et n’est pas corrigée par les mises à jour publiées le 21 octobre 2026, comme l’indique SecurityAffairs. L’équipe du projet recommande de désactiver le suivi de progression des téléversements de session en attendant le cycle normal de révision logicielle.
La gestion de cette crise rappelle les secousses provoquées par Log4Shell, en raison de l’extrême diffusion de PHP et de l’ampleur du parc de serveurs non maintenus. Les recensements spécialisés dénombrent plus d’un million de serveurs encore exposés sous des versions en fin de vie, qui ne recevront aucune mise à jour automatique. Face à ce risque résiduel, plusieurs administrations britanniques ainsi que des hôpitaux ont préféré déconnecter préventivement leurs plateformes publiques plutôt que d’attendre la validation d’un exploit pleinement opérationnel dans la nature.
Cette succession rapide d’alertes met en évidence la sensibilité des fondations logicielles du web face à un composant omniprésent mais ancien. Même si les millions de requêtes malveillantes observées n’ont pas encore débouché sur des intrusions de masse confirmées, la dangerosité réelle de ces failles et leur potentiel d’automatisation criminelle ne se mesureront qu’avec le recul des prochaines semaines (ou jours?) d’observation technique.
Foire aux questions sur la crise PHP2Shell
Qu’est-ce que la vulnérabilité PHP2Shell ?
PHP2Shell désigne un ensemble de deux failles critiques qui touchent directement le moteur PHP et permettent à des tiers non authentifiés d’exécuter du code malveillant à distance par le biais de simples requêtes HTTP. Ces failles affectent la gestion de la mémoire du programme et concernent potentiellement la totalité des versions traitant des requêtes web.
Pourquoi les attaques massives n’ont-elles pas encore abouti à des compromissions vérifiées ?
Les mécanismes de sécurité intégrés aux systèmes d’exploitation, notamment la disposition aléatoire de l’espace mémoire, empêchent les attaques courantes de deviner l’emplacement exact des fonctions à détourner. La plupart des outils diffusés publiquement provoquent des plantages ou des lenteurs de serveur au lieu de réussir une prise de contrôle.
Comment les organisations peuvent-elles se protéger contre PHP2Shell ?
L’action prioritaire consiste à installer immédiatement les versions corrigées de PHP publiées par la Fondation PHP, notamment les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les installations qui ne peuvent pas être mises à niveau sur-le-champ, les équipes doivent restreindre les permissions d’accès au réseau et aux fichiers du processus web, ou couper temporairement les services sensibles.
En quoi consiste la nouvelle faille découverte après les premiers correctifs ?
La vulnérabilité CVE-2026-115560 concerne une configuration rare où une application modifie dynamiquement le gestionnaire de sérialisation avant le démarrage d’une session tout en gardant actif le suivi du téléversement de fichiers. La Fondation PHP recommande de désactiver ce paramètre de progression des téléversements en attendant la parution d’un correctif dédié lors du prochain cycle de maintenance.
Pour approfondir le sujet
Vulnérabilités critiques dans PHP
Vulnérabilités critiques dans PHP Lire la suite
Zéro paywall. Zéro pub.
DCOD reste en accès libre grâce à vos contributions.
