veilletech.frCe qui se passe
La fiche du 22 octobre rapportait qu'aucune exploitation de PHP2Shell (CVE-2026-109618 et CVE-2026-109619) n'avait été observée. Cette phrase n'est plus vraie. Amazon Threat Intelligence a publié ce que son réseau de pots de miel, MadPot, a enregistré :
- 17 octobre 2026, quatre jours avant la divulgation : une tentative depuis
103.216.220.92, une adresse géolocalisée en Australie et rattachée à un réseau d'anonymisation commercial. Amazon y voit un acteur malveillant, sans savoir comment il a obtenu l'information sous embargo. Un porte-parole parle d'une sonde surtout isolée ; heise relève que ce pouvait aussi être un essai contre une autre faille d'envoi de fichiers. - 21 octobre, de 02:00 à 08:00 UTC : plusieurs preuves de concept, puis
d'autres tentatives depuis
31.223.184.166,37.19.200.5,134.209.159.64,103.114.163.188et95.217.98.37. Les charges et les infrastructures varient : plusieurs acteurs. - Après la sortie coordonnée (21 octobre, 14:00 UTC) : d'autres exploits en quelques heures, et une exploitation désormais large.
Recoupements relevés par The Hacker News : VulnCheck voit un user-agent
php2shell-scan/109618 depuis 85.11.167.243 et 45.198.224.169, et
109.71.252.97 vise les deux failles. Cloudflare compte des millions de
tentatives, dont les premières environ dix heures avant la publication des
détails (d'après Reuters, cité par heise). Selon la PHP Foundation, la première
requête vue par ELLIO date de 08:36 UTC, moins d'une heure après que Chainguard
a publié des images contenant déjà le correctif.
Pourquoi c'est difficile à voir
CrowdStrike décrit une attaque presque sans trace : les workers restent
stables, les réponses sont des 200, et les journaux d'application ne signalent
rien, puisque aucun code de l'application n'a tourné. Le seul indice côté
serveur est une erreur fatale de limite mémoire dans le journal d'erreurs du
serveur web, que l'on prend d'ordinaire pour du bruit.
Comment s'y prendre
- Mettre à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Pour Amazon, c'est la seule remédiation complète : aucun réglage ne couvre les deux failles.
- Enquêter à partir du 17 octobre, pas du 21 : la date de divulgation n'est pas celle de la première exploitation.
- Chercher dans les journaux :
- des erreurs fatales de limite mémoire en rafale (le message habituel de PHP contient « Allowed memory size … exhausted ») ;
- des requêtes
POSTd'envoi de fichier contenantPHP_SESSION_UPLOAD_PROGRESS; - des processus PHP qui lancent un shell ou téléchargent un fichier (conseil du FBI) ;
- des fichiers modifiés sans raison sur les serveurs web.
- Examiner les adresses IP, ne pas les bloquer : Amazon précise qu'elles appartiennent à des infrastructures d'anonymisation partagées.
- Sur un hôte impossible à corriger tout de suite, Amazon suggère de bloquer les envois multipart, après avoir mesuré l'effet sur l'application.
- Pour tester un site ou un binaire PHP local, OpenAI publie un contrôleur, php2shell-checker, sous forme de skill Codex.
Ce que ça change
Amazon tire deux leçons : un embargo ne protège que jusqu'au moment où quelqu'un d'autre trouve le même défaut, et l'analyse assistée par IA transforme un correctif ou un avis en exploit en quelques heures. Sur une faille critique exposée, un délai de correction de 7 ou 30 jours n'a plus de sens ; il se mesure en heures. Les failles ont été trouvées par Calif, OpenAI et Wiz, d'après The Hacker News.
Source : AWS Security Blog, 21 octobre 2026. Source en anglais. Compléments : The Hacker News, PHP Foundation, VulnCheck, heise (en allemand).