PHP2Shell : une vulnérabilité vieille de plusieurs années, une urgence mondiale, et que faire maintenant
Un défaut de mémoire a été détecté pour la première fois dans PHP en 2024. Deux ans passèrent sans solution. Ensuite, la recherche assistée par l’IA en a transformé une faille fonctionnelle. Aujourd’hui, plus de 22,6 millions d’instances exposées à Internet sont potentiellement à risque. Actuellement, les attaquants sondent les serveurs vulnérables, et les sites publics à travers l’Europe sont restés hors service pendant que Teams est mis à jour.
Ce brouillage remonte à deux défauts critiques de PHP, connus ensemble sous le nom de PHP2Shell. Le 21 octobre, les développeurs PHP ont publié des correctifs pour CVE-2026-109618 et CVE-2026-109619, chacun noté 9,2 sur 10 pour la gravité. PHP alimente environ 70 % des sites web utilisant une langue de programmation serveurconnue, y compris les sites construits sur WordPress, Drupal et Joomla. Et comme les défauts résident dans PHP lui-même plutôt que dans un plugin ou une application, les attaquants pourraient exécuter du code malveillant sans se connecter. À partir de là, ils pourraient prendre le contrôle d’un serveur vulnérable ou extraire directement des données sensibles de sa mémoire.
PHP2Shell est bien plus qu’un simple problème de patch. La recherche assistée par l’IA peut transformer d’anciennes failles en exploits fonctionnels plus rapidement que les équipes ne peuvent tester et livrer des correctifs. Et un serveur web public compromis peut offrir aux attaquants un accès aux bases de données, applications internes et charges de travail cloud. Le patching doit venir avec un second plan : voir ces chemins, limiter les mouvements latéraux et contenir une violation avant qu’elle ne se propage.
« C’est presque comme si quelqu’un avait trouvé une clé universelle pour toutes nos portes d’entrée », a déclaré Christer Swartz, directeur des solutions industrielles chez Illumio.
La course au patch a commencé par une fuite. Le 20 octobre, les deux identifiants CVE ont commencé à circuler en ligne. PHP a avancé sa sortie d’un jour. Ce soir-là, la société de sécurité Calif a publié par erreur une vidéo d’une exploitation fonctionnelle. Des copies se sont répandues sur les réseaux sociaux. Le lendemain matin, Chainguard a publié des images logicielles avec la correction plus de six heures avant la sortie coordonnée. Les attaquants pouvaient étudier la correction avant que la plupart des équipes n’aient eu le temps de faire un patch.
Les retombées ont rapidement atteint les services publics. Les agences gouvernementales, universités et autres sites publics à travers l’Europe ont été hors ligne alors que les équipes se précipitaient pour mettre à jour. Les agences de sécurité ont demandé des mises à jour immédiates. Cloudflare a détecté du trafic d’attaque contre ses clients avant la livraison des correctifs. Amazon menace Intelligence affirme avoir repéré une tentative d’exploitation le 17 octobre, quatre jours avant que les failles ne soient rendues publiques. Il rapporte désormais une exploitation massive dans la nature. On ne sait pas encore combien de tentatives ont réussi.
L’avertissement resté sans réponse
Le compte à rebours a commencé bien avant que le public ne connaisse PHP2Shell.
En 2024, un développeur PHP a détecté les premiers signes du problème de mémoire en corrigeant un autre problème issu d’un audit de sécurité. L’équipe a pesé plusieurs corrections. Chacune risquait de casser la compatibilité, de créer de nouveaux risques de déni de service ou de forcer des modifications sur les extensions tierces. Sans voie connue vers l’exécution à distance du code, le travail s’est arrêté.
Puis les enjeux ont changé.
En août, des recherches aidées par l’IA ont montré ce que cette faille pouvait faire. Le 11 août, des chercheurs de Calif et OpenAI ont signalé séparément un chemin d’exécution de code à distance avec la même cause profonde. Quelques jours plus tard, Wiz utilisa des modèles d’IA de frontière pour trouver d’autres voies d’attaque. Son équipe a montré des attaques efficaces sur les sites WordPress, Drupal et Joomla. Le bug était désormais un moyen d’accéder à un serveur web en ligne.
L’équipe PHP et les chercheurs ont commencé à travailler sur des correctifs. Ils visaient à laisser aux propriétaires de sites le temps de se préparer. Mais le plan s’est effondré lorsque des détails ont été échappés avant la sortie.
Le chemin de l’avertissement à la crise
- 2024 : Lors de la correction d’une conclusion d’audit, un développeur PHP repère la faille mémoire. Un fix s’arrête.
- Août 2026 : Californie, OpenAI et Wiz utilisent la recherche assistée par IA pour démontrer l’exécution de code à distance.
- Août à octobre 2026 : Les mainteneurs et chercheurs de PHP travaillent sur une correction pour une version du 22 octobre.
- 17 octobre : Amazon détecte une tentative d’exploitation sur un honeypot.
- 20 octobre : fuite des identifiants CVE. PHP avance la sortie d’un jour. Calif publie par erreur une vidéo d’exploit.
- 21 octobre : Chainguard publie les images corrigées en avance. PHP publie des correctifs lorsque les sites web se mettent hors ligne et que les tentatives d’exploitation augmentent.
Depuis, la PHP Foundation a reconnu des lacunes dans la manière dont elle a géré l’ancien avertissement. Son récit montre aussi à quel point il est difficile de garder une correction secrète une fois que la preuve d’un exploit s’est répandue. Un patch nécessite un test. Les attaquants n’ont besoin que d’un seul serveur qui n’a pas encore été corrigé.
Tous les sites PHP ne présentent pas le même risque. Le risque dépend de la version utilisée, de la configuration du serveur et des contrôles qui l’entourent. Mais la crise a imposé une limite sévère au temps dont disposaient les équipes pour agir.
Un serveur web peut être un chemin d’accès au réseau
Pensez à un portail client. Il peut se connecter à une base de données pour les enregistrements de compte, à une API pour les paiements, et à des applications cloud pour d’autres tâches. Ces liens permettent au site de fonctionner. Ils peuvent aussi donner à un intrus un passage au-delà de la porte d’entrée.
Swartz a averti qu’un attaquant qui prend le contrôle d’un serveur web peut suivre les chemins déjà empruntés par l’application.
« Et si cette menace touche un serveur web orienté client ... et que vous ne pouvez pas la détecter, elle commencera simplement à suivre les mêmes chemins de plus en plus profondément dans votre réseau que vous avez laissés ouverts », a-t-il déclaré.
L’attaquant peut rechercher des clés API ou des jetons de connexion dans la mémoire du serveur. Wiz a montré que ces défauts peuvent divulguer exactement ce genre de données. L’attaquant peut aussi tester quels systèmes le serveur peut atteindre. Si l’accès est trop large, une seule violation pourrait mettre en danger les données clients, les applications internes et les actifs critiques.
Le statut du patch seul ne vous dira pas jusqu’où cela peut aller. Les équipes doivent aussi savoir ce qu’un serveur peut atteindre après une brèche.
Cela inclut tout lien entre l’informatique et la technologie opérationnelle (OT), où un chemin mal sécurisé pourrait exposer les systèmes de l’usine.
L’IA a changé le rythme de la course
L’IA a aidé les chercheurs à découvrir les risques. Cela a donné aux défenseurs une chance de corriger la situation. Mais ces mêmes outils peuvent aider les attaquants à trouver des moyens d’entrer.
Swartz voit un nouveau problème pour les équipes qui dépendent de la réponse manuelle.
« Je dirais que ce que cela signifie pour la fenêtre de vulnérabilité, c’est qu’elle est bien plus courte maintenant que n’importe quel humain ne peut y répondre », dit-il. Il a été plus direct sur le coût du retard : « Si vous comptez sur une personne... un humain qui tape sur un clavier, vous avez perdu. »
Le problème, c’est la vitesse. Les analystes doivent toujours évaluer les risques et enquêter sur les attaques. Mais au moment où quelqu’un repère une connexion inconnue et agit en conséquence, un attaquant peut être passé à autre chose.
Comment limiter les dégâts
1. Commencer par les serveurs exposés
La première étape consiste à trouver les serveurs PHP affectés et à appliquer les mises à jour de sécurité. Si un serveur public ne peut pas être corrigé, restreindre l’accès ou le mettre hors ligne peut être le choix le plus sûr.
Swartz classerait le travail selon l’exposition, pas seulement le nombre de serveurs. Un site lié à une base de données sensible ou à un autre actif critique mérite une attention particulière.
« Il faut mettre des patchs, mais il faut aussi demander ce que ce serveur peut atteindre », dit-il. « Si elle est connectée à des actifs critiques, le risque est bien plus grand que la vulnérabilité de cette seule machine. » Pour les sites équilibrés en charge, il recommande de patcher un groupe de serveurs pendant que les autres maintiennent le site en fonctionnement. Ensuite, les équipes peuvent changer le trafic et corriger le reste.
2. Voir où un attaquant pourrait aller ensuite
La prochaine préoccupation de Swartz concerne les liens du serveur web vers les API, bases de données, applications internes et charges de travail cloud. Ces parcours ont souvent du sens pour l’entreprise. Ils peuvent aussi devenir des voies de mouvement latéral.
« Si vous ne savez pas avec quels systèmes votre serveur web communique, vous ne savez pas jusqu’où un attaquant pourrait aller », a-t-il déclaré. « Cartographie d’abord ces connexions. Vous pourrez alors voir lesquels doivent être là et lesquels mettent en danger des actifs critiques. »
3. Surveillez les changements de trafic
Il chercherait aussi du trafic qui casse le schéma habituel d’un serveur : nouvelles connexions de charge de travail, destinations inhabituelles ou un saut soudain de volume.
Il a donné DNS comme exemple. Un serveur qui envoie généralement de petites requêtes DNS mais commence à déplacer de grandes quantités de données pourrait nécessiter un examen plus approfondi. Ce n’est pas un panneau spécifique à PHP2Shell, et cela ne prouve pas une violation. Pour PHP2Shell, Wiz suggère de surveiller les requêtes d’envoi inhabituelles suivies d’erreurs de limitation mémoire ou de réponses HTTP 500 répétées.
« Vous ne savez peut-être pas quelle vulnérabilité un attaquant a utilisée », a-t-il dit. « Mais tu peux quand même imaginer une charge de travail qui fait quelque chose qu’elle n’a jamais fait auparavant. C’est le genre de changement qu’il faut détecter avant que l’attaque ne se propage. »
4. Couper les chemins inutiles
« La meilleure pratique, je dirais, est de segmenter vos applications indépendamment des segments sous-jacents », a déclaré Swartz. En d’autres termes, réglez les contrôles autour de chaque application, quel que soit le réseau sur lequel elle se trouve.
Il soutient qu’un pare-feu à la périphérie, un VLAN ou une frontière réseau cloud ne contrôlent pas toujours l’accès entre applications. La segmentation au niveau de la charge de travail peut restreindre chaque serveur aux services dont il a besoin.
« Un serveur web peut avoir besoin de communiquer avec une seule base de données », a-t-il dit. « Cela ne veut pas dire qu’il devrait pouvoir accéder à toutes les bases de données. Si le serveur est compromis, ces limites peuvent empêcher l’attaquant de l’utiliser comme pont vers le reste du réseau. »
5. Supposez que le patch n’est peut-être pas la fin
Swartz met également en garde qu’un correctif ferme une vulnérabilité mais ne peut pas éliminer un attaquant qui s’est connecté avant la correction. Les équipes doivent toujours vérifier les journaux, les processus, les jetons d’accès et les nouvelles connexions.
« Une fois qu’un serveur a été exposé, ne supposez pas que le correctif signifie que vous avez terminé », dit-il. « Cherchez des signes indiquant que quelqu’un est entré, vérifiez où il est allé, et isole la charge de travail si vous trouvez une menace. »
L’objectif, dit-il, est de contenir une violation sans couper tous les services dont l’entreprise a besoin.
Contenir ce que tu ne peux pas corriger à temps
PHP2Shell met deux horloges en marche. L’un suit le temps nécessaire aux équipes pour tester et déployer un correctif. L’autre suit la rapidité avec laquelle un attaquant peut trouver un moyen d’entrer.
Swartz comparait PHP2Shell à une clé universelle pour les portes d’entrée. Les équipes ne peuvent pas toujours changer les serrures avant que quelqu’un n’essaie la clé. Mais s’ils connaissent les chemins entre les charges de travail, limitent l’accès et agissent rapidement face à un trafic inhabituel, une porte ouverte n’a pas besoin d’ouvrir toute la maison.
Ne laissez pas une seule vulnérabilité devenir une violation à l’échelle du réseau
Les attaquants n’ont besoin que d’un seul point d’entrée pour compromettre votre environnement.
Illumio vous aide à détecter des mouvements latéraux suspects, à contenir les menaces et à empêcher les attaquants de transformer une seule vulnérabilité en une violation généralisée.
.webp)
