PHP2Shell : 35 exécutions de commandes confirmées sur des serveurs-pièges

Les failles PHP2Shell commencent à montrer leur véritable danger ! Quelques jours après la publication des correctifs d'urgence, des attaquants sont parvenus à exécuter des commandes directement sur des serveurs PHP vulnérables. Jusqu'à présent, les chercheurs observaient surtout des tentatives d'exploitation, des plantages ou des requêtes suspectes, sans preuve suffisamment solide de prise de contrôle. Cette fois, les traces techniques confirment que l'attaque a réellement fonctionné.

La découverte provient d'Adel Karimi, responsable de la détection et de la réponse aux incidents chez Perplexity. Dans un rapport technique publié après les événements du 24 octobre, le chercheur détaille 35 exécutions de commandes enregistrées sur trois serveurs-pièges, appelés honeypots, spécialement conçus pour observer les cyberattaques.

35 commandes exécutées sur trois serveurs vulnérables

Les machines utilisées fonctionnaient avec PHP 8.4.26, associé au serveur Apache et à son module mod_php. Une configuration volontairement favorable à l'exploitation de la vulnérabilité CVE-2026-109618, l'une des deux failles critiques regroupées sous le nom PHP2Shell.

Le 24 octobre, deux adresses IP ont été associées à des tentatives réussies. La première a provoqué trois exécutions de commandes sur un serveur, tandis que la seconde en a déclenché 32 sur les trois machines surveillées.

Pour parvenir à leurs fins, les attaquants ont utilisé une succession de requêtes HTTP destinées à perturber la gestion de la mémoire de PHP, à récupérer certaines informations internes, puis à exécuter une commande système. Le chercheur a pu établir une correspondance entre les requêtes reçues et le lancement effectif de processus sur les serveurs.

Les commandes observées cherchaient principalement à vérifier les droits obtenus, à identifier les machines ou à contacter des adresses distantes. Aucun téléchargement confirmé d'un second programme malveillant n'a été constaté dans les traces analysées.

Attention, il ne s'agit pas de 35 sites piratés

C'est une distinction essentielle. Les trois serveurs étaient des honeypots, c'est-à-dire des machines volontairement exposées et surveillées pour attirer les attaquants. Les 35 exécutions ne correspondent donc pas à 35 entreprises compromises.

Les résultats montrent néanmoins que l'exploitation est techniquement possible en conditions réelles de trafic Internet. Marcus Hutchins, chercheur chez Expel, considère ces éléments comme les preuves les plus convaincantes observées jusqu'à présent concernant PHP2Shell.

Le rapport précise également que les tests concernent une configuration Apache particulière utilisant un seul processus de traitement. Il serait donc incorrect d'en déduire que toutes les installations PHP sont aussi faciles à compromettre.

Autre élément invitant à la prudence : Palo Alto Networks a retiré le 25 octobre une précédente affirmation concernant une attaque contre une administration européenne, faute de pouvoir confirmer que l'intrusion provenait bien de PHP2Shell. Les serveurs-pièges constituent donc un élément nouveau et solide, mais ne démontrent pas à eux seuls une vague de compromissions de sites de production.

Quelles versions de PHP faut-il installer ?

Pour rappel, les deux failles critiques CVE-2026-109618 et CVE-2026-109619 ont reçu une gravité de 9,2 sur 10. Elles peuvent permettre l'exécution de code à distance sans authentification, sous certaines conditions.

L'équipe PHP a publié les correctifs le 21 octobre. Les versions protégées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les administrateurs peuvent consulter les annonces officielles de PHP pour vérifier les versions disponibles.

Les branches PHP 8.1 et antérieures ne bénéficient plus de correctifs directement publiés par le projet PHP. Certains fournisseurs de distributions Linux ou d'hébergement proposent néanmoins leurs propres correctifs de sécurité pour ces anciennes versions.

Si vous gérez un site WordPress, un forum ou une application PHP, vérifiez donc la version réellement utilisée par votre hébergement. Mettre à jour WordPress ou ses extensions ne suffit pas à corriger une vulnérabilité située directement dans le moteur PHP.

Pour les utilisateurs d'un hébergement mutualisé, la disponibilité des correctifs dépend également du fournisseur. En cas de doute, mieux vaut demander confirmation à son hébergeur plutôt que supposer que tout est protégé. Les serveurs exposés utilisant encore une version vulnérable doivent être mis à jour en priorité.