Si vous utilisez PHP à n'importe quel niveau de votre pile et que vous n'avez pas effectué la mise à jour, arrêtez de lire ceci et procurez-vous vers une version corrigée. Vous trouverez plus d'informations à ce sujet sur notre blog d'avis de sécurité, et consultez php2shell.aikido.io pour vérifier si votre service est potentiellement vulnérable.
La semaine dernière a été marquée par ce qui pourrait bien être les journées les plus intenses de tous les temps en matière de cybersécurité, et je ne pense pas exagérer. Les vulnérabilités se sont succédé à un rythme effréné, mais c’est PHP2shell qui a fait la une.
De nombreux sites ont été mis hors ligne pour être mis à jour, ce qui en a surpris plus d'un quant à la part encore importante du Web fonctionnant sous PHP (70 % selon certaines sources !). Le sujet a fait la une de l'actualité.
PHP2Shell est resté caché dans le moteur d'exécution de PHP pendant une vingtaine d'années, mais cette année, plusieurs groupes ont découvert cette même vulnérabilité en l'espace de peu de temps. Ce mois-ci, des pirates ont tenté de l'exploiter plusieurs jours avant même que PHP n'annonce la sortie prochaine d'un correctif. L'intelligence artificielle a changé la donne, et toute fuite d'informations concernant une vulnérabilité ou ses correctifs est désormais plus dangereuse qu'auparavant. Cela signifie que la prochaine vulnérabilité majeure pourrait survenir sans préavis, et les équipes chargées de la gestion des incidents doivent être prêtes à réagir et à appliquer des correctifs rapidement.
Comment les révélations concernant PHP2Shell se sont déroulées
Un récapitulatif de la chronologie des révélations concernant PHP2Shell, pour planter le décor.
Le problème de dépassement de mémoire à l’origine de la première des deux vulnérabilités PHP2Shell avait déjà été mis en évidence lors d’un audit réalisé en 2024 par OSTIF et Quarkslab, mais il n’avait pas été corrigé car personne n’avait démontré qu’il pouvait être exploité. Il a été redécouvert en 2026, lorsque Calif et Wiz ont découvert ces failles indépendamment l’un de l’autre, en apportant la preuve de leur exploitation (Calif les a signalées dans le cadre de l’initiative « Patch the Planet » d’OpenAI). L’équipe de sécurité de PHP a confirmé ces signalements et a passé les semaines suivantes à élaborer des correctifs pour chaque branche prise en charge. Les détails ont été gardés sous embargo en attendant une publication coordonnée.
À l'origine, PHP prévoyait de publier ces correctifs le 22 octobre. Lorsque les identifiants CVE, CVE-2026-109618 et CVE-2026-109619, ont été divulgués le 20 octobre, PHP a publié son avant-annonce à 19 h 30 UTC ce soir-là et a avancé la date de publication d'un jour, à 14 h 00 UTC le 21 octobre.
Aikido Nous faisions partie d'un groupe d'organisations ayant reçu des informations en avant-première, et la période précédant la publication du correctif a été chaotique. Chaque nouvelle fuite augmentait le risque que des pirates passent à l'action avant la publication des correctifs, et les membres du groupe ont débattu pour savoir s'il fallait partager les mesures d'atténuation plus tôt ou adapter leurs propres calendriers. Nous estimons que la divulgation coordonnée mérite d'être soutenue ; c'est pourquoi nos images corrigées ont été diffusées après l'annonce de PHP, le 21 octobre.
Avant la publication et dans les heures qui ont suivi, une grande partie d’Internet est passée en mode maintenance, les utilisateurs s’empressant d’appliquer les correctifs. Censys suit l’exposition à PHP2Shell depuis le 21 octobre. Au 27 octobre, environ 11,2 millions de services PHP étaient passés à une version corrigée, soit environ un quart de ceux qui indiquaient une version, tandis que 32,5 millions fonctionnaient toujours avec une version vulnérable. Plus de 60 millions de services PHP ne communiquent aucune version ; l'ampleur réelle de la vulnérabilité est donc probablement plus importante. Suivez les chiffres en temps réel sur la page PHP2Shell de Censys.
Les tentatives d'exploitation sont désormais monnaie courante, et quelques-unes ont même abouti. Lors d'un test public, le chercheur en sécurité James Pavur a mis en place un serveur PHP 8.4.26 non corrigé, avec une récompense d'environ 2 000 dollars en bitcoins à la clé, et un participant a réussi à s'introduire dans le système environ trois heures après que le serveur a commencé à servir une page exécutant du code PHP.
Le compte rendu de la Fondation PHP et l'article de Calif présentent la chronologie complète, depuis la découverte du problème jusqu'à la publication du correctif.
L'IA détecte davantage de vulnérabilités plus rapidement
PHP est au cœur d'une grande partie du Web depuis trois décennies ; ses utilisateurs pensaient donc avoir déjà identifié tous ses bugs majeurs. « Nous ne savons pas d'où viendra le prochain CVE. Et il pourrait provenir d'un logiciel dont personne n'aurait même songé à créer au cours des 20 dernières années », explique Benji Kalman, vice-président senior de l'ingénierie chez Aikido.
La vulnérabilité PHP2shell existait elle aussi depuis une vingtaine d'années, mais elle était restée cachée, comme un fantôme. Le fait que Calif et Wiz l'aient découverte à quelques semaines d'intervalle nous rappelle que l'IA va désormais les repérer plus rapidement.
AikidoNous avons testé à quelle vitesse nous pouvions détecter nous-mêmes ces vulnérabilités PHP. Après la divulgation, nous avons orienté l'outil analyse de code par IA ( ) vers PHP, et il a redécouvert PHP2Shell en quelques heures. Nous l'avions déjà utilisé sur des bibliothèques open source, mais nous n'avions pas encore testé les langages sous-jacents.
Mettre au jour davantage de ces vulnérabilités pourrait être considéré comme risqué, si cela revient à attirer l’attention sur une faille dont personne n’avait connaissance depuis des décennies. Mais si l’outil d’un défenseur est capable de détecter un bug de ce type en un après-midi, les outils des attaquants ne tarderont pas à en faire autant. On se trouve donc face à une sorte de dilemme du prisonnier : les attaquants vont se mettre à rechercher des failles partout où ils le peuvent et leurs outils ne cesseront de s’améliorer ; les défenseurs ne peuvent donc pas rester dans l’ignorance. Les « bons » hackers devront eux aussi continuer à rechercher des failles dans les bibliothèques et les langages open source. Les équipes de sécurité doivent s’attendre à ce que le prochain correctif d’urgence soit publié du jour au lendemain.
La publication coordonnée des informations doit s'accélérer
Grâce à l'IA, les pirates peuvent se lancer à partir d'un minimum d'informations, ce qui rend difficile la gestion d'une divulgation d'une telle gravité. « Même une simple allusion suffit. Il suffit de dire qu’il existe une vulnérabilité dans PHP pour que j’entende déjà tous les GPU s’activer dans le centre de données », explique Charlie Eriksen, chercheur principal en logiciels malveillants chez Aikido. « Nous sommes confrontés à des situations où les délais entre la découverte et l’exploitation sont considérablement réduits, et où de nombreuses personnes sont capables de découvrir ces vulnérabilités très rapidement. »
Cette rapidité rend la divulgation coordonnée plus utile que jamais, mais aussi plus difficile à mener à bien. Les alertes et les préavis, s’ils aident les utilisateurs à se préparer à installer des correctifs ou à mettre des services hors ligne, indiquent également aux pirates où chercher. « L’alerte peut aussi vous causer du tort. C’est une dynamique vraiment complexe », explique Charlie.
En ce qui concerne PHP2Shell, l'annonce préalable a peut-être été programmée trop longtemps avant la publication initiale. L'équipe de PHP a avancé la date de publication d'un jour dès que les identifiants CVE et les POC ont commencé à apparaître. Mais Amazon affirme que les premières tentatives d'exploitation ont débuté le samedi 17 octobre, soit trois jours avant l'annonce préalable de PHP prévue le 20 octobre (nous ne pouvons pas spéculer sur les raisons de ce phénomène).
Une fois qu'un correctif est rendu public, les pirates disposent de bien plus de ressources qu'auparavant. En s'appuyant sur ces correctifs, Charlie estime qu'une personne expérimentée pourrait créer un exploit à l'aide d'un modèle de langage de grande capacité (LLM) en quelques heures. Pour PHP2Shell, Trail of Bits a mis au point un exploit fonctionnel en une journée à l'aide de Codex.
Pour les vulnérabilités nécessitant une divulgation coordonnée, le processus doit être accéléré et renforcé. Les délais d'embargo devraient être raccourcis, et les détails techniques ne devraient être communiqués qu'à un nombre aussi restreint que possible de personnes, car chaque jour supplémentaire et chaque intervenant supplémentaire augmentent le risque de fuite.
Ce que la réduction des délais d'embargo signifie pour la majorité
Des embargos plus courts et plus stricts aident les équipes en réduisant la période pendant laquelle des fuites et des attaques précoces peuvent se produire, mais ils laissent également moins de temps à tous les acteurs en aval pour se préparer.
Le correctif officiel et celui qu’une équipe peut réellement installer ne sont pas toujours disponibles en même temps. L’après-midi où PHP a publié son correctif, les mises à jour de SUSE et Fedora étaient encore en phase de test, et la branche « unstable » de Debian proposait toujours la version 8.4.26, qui présentait une faille. Sur les hébergements mutualisés, les propriétaires de sites ne peuvent pas appliquer eux-mêmes le correctif PHP ; ils doivent donc attendre que leur hébergeur le fasse.
Les couches de protection dépendent également d’une alerte précoce. Les fournisseurs de CDN et de WAF qui sont informés à l’avance peuvent déployer des règles de blocage dès le premier jour, comme l’a fait Cloudflare en étendant ses règles WAF à toutes les formules, y compris la version gratuite, avant même la sortie du correctif. Lorsque moins de fournisseurs sont informés, le dispositif de sécurité se met en place plus tardivement. Les alertes peuvent également devenir plus brèves et plus vagues afin de ralentir les pirates, ce qui laisse moins de temps aux équipes pour planifier la maintenance.
Si les délais d'alerte doivent être raccourcis, les équipes de sécurité doivent s'assurer qu'elles sont en mesure de recevoir les alertes à temps et d'être prêtes à déployer rapidement les correctifs, ou disposer d'outils de sécurité capables de le faire automatiquement.
Ce que les équipes peuvent faire avant la prochaine édition d'internetbreaks2shell
Commençons par les bases. Tout d’abord, il faut savoir ce que vous exécutez. « La première chose que vous devez évidemment savoir, c’est : quelle est mon exposition potentielle ? Faites l’inventaire de vos composants », explique Charlie. Cet inventaire doit couvrir tous les environnements d’exécution et toutes les dépendances que vous utilisez, y compris celles que vous n’avez pas installées vous-même. PHP2Shell en est un bon exemple, car PHP est souvent présent dans les images de base des conteneurs, les images CI, les panneaux d’hébergement et les logiciels de fournisseurs.
Ensuite, choisissez soigneusement vos sources d'information. Dans les premières heures suivant un incident, les sources les plus utiles actualisent leurs informations au fur et à mesure que la situation évolue, et ne se contentent pas de décrire le problème, mais vous proposent également des mesures d'atténuation et, surtout, des solutions que vous pouvez mettre en œuvre.
Renseignez-vous auprès de vos prestataires de sécurité actuels ou potentiels pour savoir comment ils vous aident et communiquent sur ce genre de problèmes :
- Mettent-ils à jour leurs recommandations au fur et à mesure que l'exploitation progresse ?
- Envoient-ils des alertes en temps réel sur les incidents afin que la personne concernée en soit informée sans avoir à consulter Twitter sans arrêt ?
- Vous informent-ils uniquement des incidents les plus importants, ou vous inondent-ils d'une avalanche d'informations sans intérêt sur les failles de sécurité liées à l'IA ?
- Expliquent-ils comment réduire l'exposition en attendant la sortie d'un correctif ?
- Est-ce qu'ils vous fournissent les correctifs ?
Au cours de l'incident PHP2Shell, nous avons mis à jour notre avis de sécurité au fur et à mesure de l'évolution de la situation et envoyé des alertes en temps réel. Nous avons mis en ligne un outil de vérification gratuit sur php2shell.aikido.io afin que les propriétaires de sites Web puissent vérifier si leurs sites présentaient le comportement d'épuisement de la mémoire lié à PHP2Shell.
Nous avons également intégré des correctifs rétroportés pour PHP2Shell dans les images Aikido . Les images gratuites disponibles sur l'ECR public de Aikido couvrent les versions PHP 5.5, 5.6, la série 7.x ainsi que les versions 8.2 à 8.5, et elles ont été mises à disposition peu après la sortie officielle de PHP. Les équipes pouvaient (et peuvent toujours !) se procurer une image corrigée sans avoir à effectuer elles-mêmes une mise à niveau majeure de PHP.
« Nous voulons nous assurer que nous effectuons ce que nous appelons une “mise à jour sur place”. Cela signifie donc que nous ne vous demandons pas de passer à un système d’exploitation totalement différent ou à quelque chose de particulier », explique Benji. « Il suffit simplement de récupérer l’image depuis l’ECR et de la remplacer dans votre Dockerfile. »
Nous déconseillons le comportement de type « bot » de Renovate, qui met automatiquement tout à jour vers les dernières versions. Cela provoque des dysfonctionnements constants dans votre application, ce qui pousse finalement les équipes à désactiver cette fonctionnalité. Les équipes doivent être protégées sans pour autant introduire de vulnérabilités; il convient donc de verrouiller les fichiers à l’aide de fichiers de verrouillage et de ne procéder à des mises à jour qu’à mesure que des CVE apparaissent.
« Le réseau est vaste et infini »
Même si PHP2Shell a été une épreuve stressante et quelque peu chaotique, les défenseurs peuvent tout de même s'en sortir gagnants.
« Je pense que les défenseurs ont encore l'avantage pour l'instant. Il faut bien sûr y mettre du sien », a déclaré Willem Debare, PDG d'Aikido, à propos de ces failles la semaine dernière.
Si vous commencez dès maintenant à renforcer votre résilience, vous ferez partie de ceux qui seront encore debout lorsque la poussière et les tampons de code se seront tassés.
P.S. Une partie du Web ne survivra pas à cette crise. Une grande partie fonctionne encore avec d’anciennes versions de PHP qui ne sont plus mises à jour. Le magazine The Atlantic prévient que de nombreux sites seront mis hors ligne ou piratés, et que certains pourraient ne jamais revenir. Repose en paix, magnifique Internet du début des années 2000.
