Des attaques PHP2Shell ont exécuté des commandes shell sur trois serveurs honeypots le 24 octobre, a rapporté Adel Karimi, chercheur chez Perplexity. Ses capteurs ont enregistré 35 lancements de shell, ce qui montre que les attaques sont allées au-delà des plantages et des erreurs de mémoire observés lors de sa surveillance précédente.
Cette constatation a un périmètre précis : les serveurs leurres de Karimi faisaient tourner PHP 8.4.26 avec Apache mod_php et un seul processus worker. Il a décrit cette configuration comme délibérément favorable à l'exploitation et a mis en garde : les résultats ne permettent pas d'affirmer leur fiabilité sur d'autres builds PHP, d'autres applications ou d'autres nombres de workers.
Les deux vulnérabilités critiques connues sous le nom de PHP2Shell, CVE-2026-109618 et CVE-2026-109619, permettent l'exécution de code à distance sans authentification. Selon SecurityWeek, PHP a publié des correctifs le 21 octobre, après la fuite en ligne d'informations sur les failles. Les tentatives d'exploitation ont précédé les correctifs, et des millions ont depuis été recensées. Avant les constats de Karimi, les entreprises de sécurité n'avaient pas confirmé que ces tentatives avaient réussi à exécuter du code, même si des chercheurs avaient mis au point des exploits contournant les protections ASLR.
Ce que les honeypots ont capturé
Les serveurs de Karimi affichaient des pages ordinaires propulsées par PHP. Lors de sa première période d'observation, d'une durée d'un peu plus de 26 heures, il a compté 30 erreurs de mémoire épuisée (out-of-memory) et 11 plantages de workers, sans détecter d'exécution de code.
L'activité du 24 octobre a donné un résultat différent. Le trafic provenant d'une même adresse IP a lancé trois shells sur un seul serveur ; une seconde adresse est à l'origine de 32 lancements de shell répartis sur les trois honeypots.
Karimi a suivi l'activité à travers quatre étapes de requêtes HTTP : épuisement de la mémoire, divulgation du contenu de la mémoire et, enfin, exécution d'une commande shell. Il a indiqué que le schéma des requêtes ressemblait fortement à un exploit de preuve de concept accessible publiquement et était compatible avec CVE-2026-109618. Cette observation n'établit donc pas l'exploitation réussie des deux vulnérabilités PHP2Shell.
Karimi qualifie ces éléments d'exécution de code à distance confirmée, accompagnée d'une divulgation de mémoire exploitable. Aucun téléchargement de charge utile de second étage n'a été observé. Marcus Hutchins, chercheur principal en menaces chez Expel, y voit la confirmation la plus solide de l'exploitation de PHP2Shell dans la nature qu'il ait observée jusqu'ici.
Exposition plus large et recommandations de correctifs
La configuration démontrée est plus restreinte que le périmètre touché décrit dans l’alerte de la CISA. Selon l'agence, les vulnérabilités touchent toutes les installations PHP traitant des requêtes web, y compris Apache avec mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. Elle désigne Apache avec mod_php comme la configuration que PHP considère comme la plus à risque.
La CISA indique que les versions corrigées pour leurs branches respectives sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elle demande d'appliquer les correctifs immédiatement, en priorisant les systèmes exposés sur Internet, ainsi que de dresser un inventaire tenant compte de PHP intégré dans d'autres logiciels.
Pour les organisations qui ne peuvent pas mettre à jour immédiatement, y compris celles qui utilisent PHP 8.1 ou une version antérieure non prise en charge, la CISA recommande de mettre hors ligne les systèmes reposant sur PHP jusqu'à ce qu'ils puissent être corrigés ou mis à jour. Un pare-feu applicatif web peut offrir une protection provisoire, selon l'agence. Ses recommandations de surveillance incluent la détection de processus workers PHP qui lancent des shells ou téléchargent des outils.
La mise à jour de l'alerte de la CISA du 23 octobre a ajouté une règle de détection Sigma et indiquait que l'agence n'avait pas observé d'exploitation réussie à ce moment-là, soit avant les observations de Karimi du 24 octobre. SecurityWeek a indiqué qu'au matin du 26 octobre, aucune des deux vulnérabilités n'avait été ajoutée au catalogue Known Exploited Vulnerabilities de la CISA.
