PHP2Shell : deux failles critiques dans PHP permettent d'exécuter du code sur le serveur ; que faire dès aujourd'hui

Publié le 21 octobre 2026 · L'équipe mitza.es

Le 21 octobre 2026, l'équipe de PHP a publié une mise à jour de sécurité d'urgence pour corriger deux vulnérabilités critiques d'exécution de code à distance, identifiées comme CVE-2026-109618 et CVE-2026-109619 et connues sous le nom de « PHP2Shell ». Le Centre national de cybersécurité du Royaume-Uni (NCSC) a averti qu'elles pouvaient permettre à un attaquant d'exécuter des commandes sur n'importe quel serveur web utilisant PHP. Si votre site tourne sous WordPress, PrestaShop, Joomla, Magento ou n'importe quel développement en PHP, vous êtes concerné.

Ce qui s'est passé

Le 20 octobre, les détails des deux vulnérabilités ont fuité sur internet avant la divulgation coordonnée, et la société de sécurité watchTowr a confirmé que les failles étaient bien réelles. Après cette fuite, l'équipe de PHP a avancé la publication des correctifs au mercredi 21 octobre. Sur son site, php.net affiche désormais un avis de sécurité sur des vulnérabilités critiques d'exécution de code à distance et demande de mettre à jour.

Les deux failles, en termes simples

• CVE-2026-109618 : une faille de corruption de mémoire qui se produit lorsque PHP manque de mémoire alors que les données internes d'une requête ne sont préparées que partiellement. Le nettoyage qui suit traite ces données comme valides et, dans certaines conditions, cela peut être exploité.
• CVE-2026-109619 : l'état interne d'une requête peut survivre à la libération de sa mémoire, et une requête ultérieure traitée par le même processus peut parfois l'utiliser avant qu'il ne soit réinitialisé.

L'équipe de sécurité de PHP leur attribue un score de 9,2 sur 10 en CVSS v4.0. Selon le NCSC, la corruption de mémoire permettrait d'exécuter du code sans authentification. Autrement dit, il n'y a besoin ni de mot de passe ni de plugin vulnérable : la faille se trouve dans le moteur de PHP lui-même.

Qui est concerné

Le NCSC affirme que les organisations qui utilisent n'importe quelle version de PHP sont touchées, les anciennes versions étant les plus préoccupantes. PHP indique que toutes les installations qui servent des requêtes web sont à risque, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Selon Huntress, il existe un exploit pour mod_php dans lequel une seule requête non authentifiée peut déclencher l'attaque avant même que le code de l'application ne s'exécute.

Cela inclut WordPress, Drupal, Joomla, Magento, PrestaShop et tout développement sur mesure en PHP, car la faille se situe en dessous d'eux. Mettre à jour WordPress ou ses plugins ne la résout pas : il faut mettre à jour PHP.

Versions corrigées et sort des versions anciennes

• PHP 8.5 : version 8.5.12.
• PHP 8.4 : version 8.4.27.
• PHP 8.3 : version 8.3.36.
• PHP 8.2 : version 8.2.35.

Pour les versions 7.4, 8.0 et 8.1, l'équipe de PHP n'a publié que des correctifs minimaux du code source : ce sont des branches qui ne bénéficient plus d'un support officiel. Si vous utilisez l'une d'elles, interrogez votre prestataire ou, mieux, passez à une branche encore supportée. Les distributions Linux et les fournisseurs de support à long terme ont reçu les correctifs avant la publication, il est donc utile de consulter leurs paquets. Sur un hébergement mutualisé, c'est votre hébergeur qui doit les appliquer.

Est-elle déjà exploitée ?

Les sources ne concordent pas, aussi la prudence veut que l'on parte du principe que oui. Huntress a déclaré que, jusqu'au matin du 21 octobre, elle n'avait pas observé d'exploitation active chez ses clients. Pourtant, le directeur technique de Cloudflare a affirmé que l'on constatait des attaques précoces, watchTowr dit avoir reproduit l'une des failles et du code d'exploitation public circule, même s'il n'a pas été vérifié. Lorsqu'une vulnérabilité critique devient publique et qu'un exploit existe, les tentatives d'attaque automatisées démarrent généralement en quelques heures.

Que faire dès aujourd'hui : la liste pour une PME avec un site en PHP

1. Trouvez votre version de PHP. Elle figure dans le panneau de votre hébergeur et, sous WordPress, dans « Outils, Santé du site, onglet Infos, section Serveur ».
2. Demandez à votre hébergeur s'il a déjà appliqué les correctifs, ou passez vous-même à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 depuis le panneau si celui-ci le permet. Demandez-le par écrit.
3. Faites une sauvegarde avant de toucher à quoi que ce soit et testez le site ensuite : un changement de version peut casser d'anciens plugins. Si vous n'avez pas de système de sauvegarde fiable, consultez notre guide de la sauvegarde en entreprise.
4. Si vous utilisez PHP 8.1 ou une version antérieure, planifiez la migration vers une branche supportée ; en attendant, ne laissez pas ce serveur exposé sans protection supplémentaire.
5. Envisagez un pare-feu d'applications web (WAF). Cloudflare a déployé des règles pour les vecteurs d'attaque connus, disponibles même dans son offre gratuite, mais elles ne couvrent que le trafic qui passe par lui et constituent un palliatif temporaire, pas une solution.
6. Surveillez les signes de compromission : fichiers nouveaux ou modifiés dans le répertoire web, tâches planifiées inconnues, nouveaux utilisateurs ou processus du serveur web qui lancent des commandes étranges.

Et les réglages de php.ini ?

Certaines publications ont proposé de modifier des paramètres de configuration comme palliatif. Les responsables de PHP le déconseillent comme solution : selon Help Net Security, la développeuse principale Gina Peter Banyard a affirmé que la seule parade est de corriger ou de mettre à jour PHP, et un autre responsable a écarté l'idée que des réglages de configuration suffisent. N'y recourez, au mieux, que comme mesure de dernière minute le temps de mettre à jour.

Si vous ne pouvez pas mettre à jour aujourd'hui

Le NCSC recommande de dresser l'inventaire des systèmes utilisant PHP, en commençant par ceux exposés à internet, de surveiller les fournisseurs dont les logiciels embarquent PHP et d'appliquer les mesures d'atténuation temporaires indiquées par l'équipe de PHP. Si ce n'est pas possible, il conseille d'envisager de déconnecter le système jusqu'à ce qu'il puisse être protégé et, s'il est impossible de le mettre à jour ou de le déconnecter, de l'examiner à la recherche d'indices de compromission. Vous trouverez l'avis complet du NCSC sur son site.

Pourquoi cela remet la maintenance sur la table

Ce type de faille se règle toujours de la même façon : quelqu'un doit être au courant, tester et mettre à jour rapidement. Les sites que personne ne maintient sont ceux qui paient l'addition, comme nous l'avons vu avec les failles critiques de WordPress de cet été et les extensions exploitées en octobre. Si personne ne s'en occupe chez vous, une maintenance de site web continue ou un audit de sécurité web vous indiquent dans quel état se trouve votre site avant qu'un attaquant ne le découvre.