Mise à jour concernant PHP2Shell : aucun cas avéré de compromission de sites WordPress, et réponses aux questions les plus fréquentes

À la date du 28 octobre 2026, Wordfence n’a connaissance d’aucun site WordPress ayant été compromis via PHP2Shell (CVE-2026-109618 et CVE-2026-109619).

Nous continuons d’observer des requêtes liées à PHP2Shell sur les plus de 5 millions de sites que nous protégeons. Ces requêtes témoignent d’opérations de scan et de tentatives d’exploitation en cours ; elles ne permettent toutefois pas de déterminer si une tentative a abouti. Nos équipes chargées du nettoyage de sites et de la réponse aux incidents n’ont eu à traiter aucune compromission de site WordPress attribuable à ces vulnérabilités.

Cela ne signifie pas pour autant qu’un serveur non corrigé est sécurisé. La solution consiste toujours à mettre à jour PHP sur votre serveur vers les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou vers un paquet fourni par votre éditeur qui intègre bien ces correctifs), puis à redémarrer PHP. La mise à jour de WordPress n’entraîne pas la mise à jour de PHP.

SOURCE WORDFENCE.COM

Cela fait sept jours que l’équipe du projet PHP a publié des correctifs d’urgence pour « PHP2Shell » — deux vulnérabilités critiques affectant PHP, le langage de programmation sur lequel repose WordPress. Depuis, nous analysons les données de sécurité issues des plus de 5 millions de sites WordPress que Wordfence contribue à protéger ; nous testons ces vulnérabilités dans notre laboratoire et examinons les nouveaux rapports transmis par des chercheurs et des fournisseurs de solutions de sécurité.

Cet article fait le point sur la situation actuelle en des termes simples, et propose des réponses courtes et directes aux questions qui nous sont le plus fréquemment posées.

État des lieux concernant PHP2Shell : aucun cas avéré de compromission de sites WordPress
À la date du 28 octobre 2026, nous n’avons connaissance d’aucun site WordPress ayant été compromis via PHP2Shell. Nos équipes chargées du nettoyage de sites et de la réponse aux incidents n’ont eu à traiter aucune compromission de site WordPress attribuable à ces vulnérabilités.

Entre le 23 et le 27 octobre, une règle de surveillance dédiée a enregistré environ 77 600 requêtes associées, provenant de plus de 2 000 adresses IP. Notre analyse n’a révélé aucun trafic correspondant à une utilisation normale par un visiteur ou à une fonctionnalité légitime d’un site web. Les requêtes détectées présentaient des signes d’attaque, s’identifiaient comme des outils d’analyse (scanners) ou affichaient d’autres indicateurs de tests automatisés.

Des rapports récents illustrent pourquoi nous distinguons les tentatives d’exploitation des compromissions avérées. Le 26 octobre, Dream a rapporté qu’un attaquant a utilisé un exploit PHP2Shell — adapté à une plateforme de pare-feu non nommée — combiné à une vulnérabilité d’élévation de privilèges dans le noyau Linux, afin de prendre le contrôle total de 24 pare-feu exposés sur Internet ainsi que d’un serveur interne de gestion de pare-feu. Selon Dream, l’attaquant a ensuite extrait le mot de passe d’un compte de service LDAP et a énuméré les utilisateurs et les groupes au sein d’un environnement décrit comme étant lié au gouvernement américain. Le rapport public ne précise pas quel fournisseur est concerné et ne publie pas les éléments techniques (« artefacts ») récupérés ; par ailleurs, nous n’avons pas vérifié cet incident de manière indépendante. Ce rapport ne fait aucune mention de WordPress.

Par ailleurs, Palo Alto Networks indique avoir observé des tentatives d’exploitation actives ciblant des interfaces de gestion PAN-OS exposées sur Internet. Leur avis technique n’établit aucun lien entre cette activité et le rapport de Dream.

Le 27 octobre, Wiz a rapporté qu’aucune des tentatives observées n’avait abouti. Le 28 octobre, Morphisec a fait état d’une exécution de code sur un serveur Windows appartenant à l’un de ses clients, lequel utilisait IIS et PHP-CGI. La publication de Morphisec ne lie pas cet incident à WordPress et ne fournit pas suffisamment de détails techniques pour nous permettre de confirmer, de manière indépendante, que PHP2Shell en était bien la cause.

Nos tests en laboratoire suggèrent qu’un exploit fonctionnel doit souvent être adapté au serveur ciblé. Lors de nos tests, le même code a permis une exécution dans une configuration donnée, alors qu’il a simplement provoqué un plantage de PHP dans une autre. Wiz a fait état de différences similaires selon les configurations des serveurs, et Hacktron a constaté que même un exploit fonctionnel devait être adapté à chaque nouvelle cible. Nous détaillons les principaux facteurs dans la FAQ ci-dessous.

Les attaquants continuent de faire évoluer leurs outils. Une attaque réussie pourrait leur donner accès aux fichiers, à la base de données et aux mots de passe de votre site ; il est donc essentiel de mettre à jour PHP.

Voici le déroulement des événements la semaine dernière :

20 octobre : Le projet PHP a annoncé la publication prochaine d’une mise à jour de sécurité critique ; nous avons alors alerté les propriétaires de sites.
21 octobre : Le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 incluant les correctifs ; nous avons diffusé un appel urgent à effectuer la mise à jour.
21 octobre : Nous avons publié l’article « Pourquoi il est urgent de mettre à jour PHP sur votre site WordPress : deux vulnérabilités critiques et les résultats de nos tests ». Nous y révélions qu’un exploit utilisé lors de nos tests parvenait à exécuter du code sur une version de PHP configurée de manière spécifique, mais provoquait simplement un plantage sur une version standard.
22 octobre : Nous avons publié une première analyse de l’activité liée à « PHP2Shell », portant sur plus de 74 000 requêtes, sans qu’aucun cas de compromission de site WordPress ne soit identifié.
23 octobre : Le projet PHP a révélé l’existence d’une autre vulnérabilité, non corrigée (CVE-2026-115560), tout en proposant une solution de contournement via la configuration. Plus de détails à ce sujet dans la FAQ ci-dessous.
26 octobre : Dream a rapporté qu’un attaquant a utilisé PHP2Shell, combiné à une vulnérabilité du noyau Linux, pour prendre le contrôle total de 24 pare-feux exposés sur Internet ainsi que d’un serveur de gestion interne. Dream n’a pas précisé le fournisseur concerné ni publié les éléments techniques associés ; ce rapport ne concerne pas WordPress.
27 octobre : Wiz a indiqué que les tentatives observées avaient échoué, précisant que les preuves les plus probantes examinées correspondaient à des exploitations réussies sur des « honeypots » (systèmes leurres).
28 octobre : Morphisec a fait état d’un incident chez un client utilisant Windows/IIS, qu’il attribue à PHP2Shell. Le rapport public ne concerne pas WordPress et ne fournit pas suffisamment de détails techniques pour confirmer, de manière indépendante, que PHP2Shell en est bien la cause. 28 octobre : Dans une note d’information mise à jour, Palo Alto Networks a indiqué avoir constaté une exploitation active ciblant des interfaces de gestion PAN-OS exposées sur Internet. Cette note ne fait pas le lien entre cette activité et le rapport de Dream.