Amazon a vu des tentatives d'attaque PHP2Shell quatre jours avant la divulgation

Quelqu'un a tenté d'exploiter PHP2Shell quatre jours avant que la plupart des défenseurs en connaissent l'existence. Selon Amazon, son réseau de honeypots MadPot a enregistré une tentative contre les deux failles de PHP le 17 octobre 2026. Les correctifs et la divulgation publique ne sont arrivés que le 21 octobre à 14 h UTC. Amazon affirme désormais que les failles sont largement exploitées.

PHP a corrigé les deux failles, CVE-2026-109618 et CVE-2026-109619, dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 mercredi. Toutes deux sont notées 9.2 et peuvent permettre à un attaquant d'exécuter du code sur un serveur web sans se connecter. Selon la chronologie d'Amazon, un serveur corrigé mercredi a pu être attaqué avant.

Ce qu'Amazon a vu

MadPot est le réseau de honeypots d'Amazon, des serveurs leurres conçus pour attirer les attaquants et enregistrer ce qu'ils font. Dans son billet sur l'AWS Security Blog, Amazon détaille ce que ses capteurs ont relevé.

Heure (UTC)	Ce qui s'est passé
17 octobre	MadPot enregistre la première tentative, depuis une adresse liée à un réseau d'anonymisation commercial
20 octobre	Les numéros CVE circulent sur Hacker News et les réseaux sociaux, selon Tenable
21 octobre, vers 02 h	Le premier exploit de démonstration apparaît, environ 12 heures avant les correctifs
21 octobre, de 02 h à 08 h	D'autres tentatives arrivent depuis une autre infrastructure anonymisée
21 octobre, 14 h	L'embargo est levé et les correctifs sont publiés

Les tentatives du 21 octobre utilisaient des charges et des infrastructures variées, ce qui, selon Amazon, suggère plusieurs attaquants. Après la publication, d'autres exploits sont apparus en quelques heures et ont atteint les capteurs d'Amazon presque aussitôt.

Amazon reste prudent sur ce qu'il ignore. Ses capteurs sont des leurres, il ne peut donc pas dire si les premières tentatives auraient réussi sur de vrais systèmes. Amazon écrit aussi qu'il « reste difficile de savoir comment l'acteur a obtenu des informations sur l'exploit avant la divulgation ». La tentative du 17 octobre a eu lieu trois jours avant la fuite des numéros CVE.

Comment l'embargo s'est effondré

Un embargo est la période discrète pendant laquelle un projet et ses partenaires préparent des correctifs avant d'annoncer un bug. Celui de PHP2Shell n'a pas tenu.

D'après Tenable et The Hacker News, la PHP Foundation avait d'abord prévu la publication pour le 22 octobre. Elle l'a avancée d'un jour après la fuite des numéros CVE. The Register rapporte que la fondation a aussi accusé Chainguard, qui publie des images de conteneurs, d'avoir diffusé des builds corrigés avant l'échéance convenue. « N'importe quel attaquant pouvait désormais étudier le correctif sous forme binaire pendant que tous les autres utilisateurs de PHP attendaient encore la publication », a déclaré la fondation, citée par The Hacker News. Les articles ne contiennent pas de réponse de Chainguard.

L'ampleur de la vague d'attaques

Matthew Prince, PDG de Cloudflare, a publié des chiffres sur X. Cloudflare a vu des milliers de tentatives dans les 10 heures précédant l'annonce. Le nombre est passé à des dizaines de milliers dans les 45 minutes suivantes, puis à des centaines de milliers en deux heures. Prince parle désormais de « millions ».

L'hébergeur Pantheon a bloqué plus de 60 000 requêtes suspectes, rapporte The Hacker News. Cloudflare indique que les attaquants modifient sans cesse leurs charges pour contourner ses règles de pare-feu. Aucun de ces chiffres ne confirme une intrusion réussie. Ils montrent des tentatives bloquées ou enregistrées.

The Hacker News cite CJ Moses, CISO d'Amazon Integrated Security, sur la raison pour laquelle cela se répète : « L'analyse assistée par l'IA rend moins coûteux le passage d'un diff de correctif ou d'un avis à un exploit fonctionnel. »

Ce que cela signifie pour les développeurs

Si vous exploitez PHP, votre enquête commence le 17 octobre, pas le jour où vous avez appliqué le correctif. Amazon le dit clairement : « Commencez les enquêtes à partir de la première exploitation connue, pas à partir de la date de divulgation. »

• Corrigez d'abord. Installez 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrez chaque worker PHP pour que le nouveau code tourne vraiment. Selon Amazon, seule une mise à niveau corrige entièrement les deux failles.
• Cherchez le motif connu dans vos journaux. Amazon conseille de rechercher les requêtes POST contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS dans les envois de formulaires. L'entreprise de sécurité Hadrian dit que la plupart des attaques qu'elle observe abusent de ce chemin de suivi d'envoi des sessions.
• Cherchez des signes d'exécution de code. Vérifiez les serveurs à la recherche de processus inattendus et de fichiers modifiés. Le FBI conseille de surveiller les processus PHP qui lancent des shells ou téléchargent des fichiers.
• N'utilisez les solutions d'appoint que le temps de corriger. La liste de PHP inclut le réglage session.upload_progress.enabled=0 et le redémarrage des workers. Amazon suggère aussi de bloquer les envois de fichiers multipart si votre application peut s'en passer.
• Ne faites pas confiance au code d'exploit public. JFrog signale de faux exploits PHP2Shell et des logiciels malveillants farceurs sur GitHub. Tenable prévient que le code qui circule peut cacher un logiciel malveillant.
• Examinez les adresses IP publiées, sans compter sur leur blocage. Amazon en publie six, mais conseille d'enquêter plutôt que de bloquer, car elles appartiennent à des services d'anonymisation partagés.