AWS a rapporté le 21 octobre que la télémétrie de son réseau de honeypots MadPot avait enregistré, le 17 octobre 2026, une tentative visant PHP2Shell, quatre jours avant la divulgation publique des deux vulnérabilités. La requête visait un honeypot, un serveur leurre destiné à observer les attaques. AWS indique ne pas savoir si la tentative aurait réussi sur un système réel. Son compte rendu ne fait état d’aucune compromission de serveur de production.

Ce que corrigent les deux failles PHP

PHP2Shell regroupe deux vulnérabilités critiques du cœur de PHP, référencées CVE-2026-109618 et CVE-2026-109619. Elles peuvent permettre l’exécution de code à distance sans authentification, mais reposent sur deux défauts distincts.

  • CVE-2026-109618 concerne la gestion d’une mémoire insuffisante. PHP peut être interrompu alors que des données internes de la requête ne sont que partiellement initialisées ; le nettoyage ultérieur peut alors les traiter comme valides.
  • CVE-2026-109619 concerne un état interne associé à une requête qui persiste après la libération de la mémoire correspondante. Une requête suivante, traitée par le même processus de travail, peut réutiliser cet état avant sa réinitialisation.

L’avis de PHP sur les deux failles et leurs correctifs cite les installations qui servent des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP estime le risque le plus élevé avec mod_php : une requête non authentifiée peut déclencher le problème avant l’exécution du code de l’application.

Les versions corrigées indiquées par PHP sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Certaines distributions et certains fournisseurs à support long peuvent rétroporter les correctifs dans leurs propres paquets, avec des numéros de version différents. Une mise à jour de l’application ou du CMS ne remplace donc pas celle du runtime PHP utilisé par le serveur.

Ce que les autres capteurs ont observé

Telekom Security rapporte que ses propres honeypots n’ont pas reçu de charge ressemblant à un exploit avant que les avis de sécurité apparaissent dans sa chronologie, le 21 octobre. Ses premières charges sérialisées de ce type sont arrivées à 14 h 18 UTC. Ces observations concernent un réseau de capteurs distinct de MadPot et ne tranchent pas le cas observé par AWS le 17 octobre.

Les vérifications utiles pour les opérateurs PHP

PHP indique qu’une mise à jour du runtime est la correction complète ; les réglages de configuration ne font que réduire l’exposition à certaines voies d’attaque. Pour les serveurs qui ne peuvent pas être mis à jour immédiatement, AWS recommande d’examiner les requêtes POST contenant PHP_SESSION_UPLOAD_PROGRESS, les journaux du serveur web et les signes d’exécution de processus ou de modification de fichiers inattendus. AWS conseille aussi d’envisager une restriction temporaire des téléversements multiparties, après avoir évalué ses effets sur l’application.

AWS a associé six adresses IP à ses observations : 103.216.220.92 le 17 octobre ; 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 et 95.217.98.37 le 21 octobre. Elles appartiennent notamment à des infrastructures d’anonymisation partagées et ne sont pas propres à cette activité. AWS recommande d’enquêter sur une correspondance plutôt que de bloquer automatiquement ces adresses.