PHP2Shell : deux failles critiques dans PHP menacent des millions de sites, dont WordPress

Baptisées PHP2Shell, deux vulnérabilités critiques découvertes dans le moteur PHP permettent à un attaquant d’exécuter du code à distance sur un serveur web, sans identifiant ni mot de passe. Des correctifs d’urgence sont disponibles depuis le 21 octobre 2026, et des tentatives d’exploitation ont déjà été observées. Tous les sites qui tournent sous PHP, WordPress en tête, sont concernés.

PHP2Shell : ce que l’on sait des deux failles

Les deux vulnérabilités portent les identifiants CVE-2026-109618 et CVE-2026-109619. Elles sont chacune notées 9,2 sur l’échelle CVSS v4.0, soit le niveau « critique ». Les chercheurs de Wiz les décrivent comme parmi les plus graves de l’histoire du langage.

Sur le plan technique, les deux failles touchent la gestion de la mémoire entre les requêtes :

• CVE-2026-109618 : une corruption liée à un manque de mémoire. Une interruption pendant le traitement peut laisser des données de requête à moitié initialisées, que PHP traite ensuite comme valides au moment du nettoyage.
• CVE-2026-109619 : un « état global périmé ». Des données internes appartenant à une requête survivent après la libération de leur mémoire, et une requête suivante traitée par le même processus peut les réutiliser.

Dans les deux cas, le résultat est le même : une exécution de code à distance (RCE) sans authentification. Une seule requête suffit, et l’attaque peut aboutir avant même que le code de l’application (WordPress, un CMS, un framework) ne s’exécute. Autrement dit, la sécurité de votre site ne vous protège pas : c’est le moteur PHP lui-même qui est vulnérable.

Quelles versions de PHP sont touchées ?

Selon la FAQ publiée par watchTowr, toutes les branches sont concernées :

• PHP 8.5 avant la version 8.5.12 ;
• PHP 8.4 avant la version 8.4.27 ;
• PHP 8.3 avant la version 8.3.36 ;
• PHP 8.2 avant la version 8.2.35 ;
• PHP 7.4, 8.0 et 8.1 : toutes les versions. Ces branches ne sont plus maintenues officiellement, mais l’équipe PHP a publié des correctifs minimaux à compiler, et certaines distributions Linux proposent des paquets corrigés ;
• PHP 7.3 et antérieures (y compris PHP 5) : aucun correctif. La seule solution est de migrer vers une branche supportée.

Tous les modes d’exécution sont dans le périmètre : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les configurations mod_php sont jugées les plus exposées. Et point important : selon l’équipe PHP, aucun réglage de configuration ne suffit à neutraliser la faille. Seule la mise à jour protège.

Une exploitation déjà en cours

La chronologie de PHP2Shell montre à quel point la fenêtre de réaction a été courte :

• 17 octobre 2026 : le pot de miel MadPot d’Amazon enregistre une première tentative d’exploitation, quatre jours avant la divulgation publique. On ignore comment l’attaquant a obtenu les détails ;
• 20 octobre : des détails fuitent sur les réseaux sociaux, avant la date de divulgation prévue au 22 octobre ;
• 21 octobre : l’équipe PHP publie les versions corrigées. watchTowr observe des exploitations dans la nature via son réseau de leurres ;
• 22 octobre : Palo Alto Networks confirme que toutes les versions de PAN-OS et Panorama sont touchées. Fortinet et Cisco analysent encore leurs produits. Searchlight Cyber publie un outil de détection open source, php2shell-scanner.

Les chercheurs de Wiz soulignent un point inquiétant : les modèles d’IA de pointe ont nettement abaissé la difficulté de transformer ces bugs en exploit fonctionnel. Le délai entre la publication d’un correctif et les premières attaques se compte désormais en heures.

WordPress et hébergement mutualisé : faut-il s’inquiéter ?

Oui. PHP fait tourner environ 70 % des sites web dans le monde, dont l’immense majorité des sites WordPress. Comme la faille se situe dans le moteur et non dans le CMS, mettre à jour WordPress ou ses extensions ne change rien : c’est la version de PHP du serveur qui compte.

Sur un hébergement mutualisé, c’est généralement l’hébergeur qui applique les correctifs. Mais beaucoup de panneaux d’administration laissent le client choisir sa version de PHP, et des sites restent bloqués sur des branches anciennes (7.4, 8.0, 8.1) pour des raisons de compatibilité. Ce sont eux les plus exposés.

Que faire maintenant : la marche à suivre

1. Vérifiez votre version de PHP. Sous WordPress, allez dans Outils → Santé du site → Informations → Serveur. Chez la plupart des hébergeurs, l’information figure aussi dans le panneau de contrôle.
2. Mettez à jour vers une version corrigée de votre branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12). Sur un serveur Linux, privilégiez les paquets de votre distribution, qui ont reçu les correctifs avant la publication publique.
3. Redémarrez les processus PHP (PHP-FPM, Apache, LiteSpeed) pour que le correctif prenne effet.
4. Si vous ne pouvez pas mettre à jour tout de suite, le NCSC britannique recommande de retirer le système d’Internet. À défaut, un pare-feu applicatif (WAF) peut servir de rempart provisoire : Cloudflare a déployé des règles contre les vecteurs connus.
5. Contrôlez vos journaux depuis le 17 octobre à la recherche de requêtes suspectes, et testez votre exposition avec php2shell-scanner.
6. Sur un hébergement mutualisé, contactez votre hébergeur pour confirmer que le correctif est appliqué, et sélectionnez une branche récente de PHP dans votre panneau.

Les utilisateurs du dépôt communautaire rpms.remirepo.net doivent être particulièrement vigilants : au moment de la divulgation, il ne proposait pas encore de mise à jour. Il est conseillé de basculer vers les paquets de la distribution ou de compiler depuis les sources.

Notre analyse

PHP2Shell rappelle une réalité souvent oubliée : la sécurité d’un site ne s’arrête pas à ses extensions. Le moteur qui l’exécute est une brique tout aussi critique, et beaucoup de sites tournent sur des versions de PHP vieilles de plusieurs années. Avec une exploitation observée avant même la divulgation et des outils d’IA qui accélèrent la création d’exploits, la règle est simple : mettre à jour PHP doit devenir un réflexe, au même titre que WordPress.

FAQ PHP2Shell

Mon site WordPress est-il vulnérable ?

Il l’est si votre serveur utilise une version de PHP antérieure aux versions corrigées. La version de WordPress n’a aucune incidence.

Un plugin de sécurité suffit-il ?

Non. L’attaque peut réussir avant que WordPress et ses plugins ne s’exécutent. Seule la mise à jour de PHP, ou à défaut un WAF en amont, protège.

Faut-il changer ses mots de passe ?

Si vos journaux montrent des signes de compromission depuis le 17 octobre, oui : changez les mots de passe, les clés d’API et les clés de sécurité de WordPress (wp-config.php), et vérifiez l’absence de fichiers suspects.

Sources : Help Net Security, watchTowr, Ubuntu. Photo : Yuri Samoilov / Wikimedia Commons (CC BY 2.0).