En bref : PHP2Shell est le nom de deux failles de sécurité critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619. Par elles, des attaquants peuvent exécuter du code malveillant sur des serveurs web vulnérables sans authentification. Seule la mise à jour vers une version corrigée de PHP, suivie du redémarrage de tous les processus PHP, apporte un remède.
Qu'est-ce que PHP2Shell ?
PHP est le langage de programmation sur lequel fonctionne une grande partie de tous les sites web : sites d'entreprise avec WordPress ou TYPO3, boutiques en ligne avec Shopware ou WooCommerce, portails internes et développements spécifiques. Le 21 octobre 2026, le projet PHP a publié des mises à jour de sécurité pour deux failles devenues connues sous le nom de PHP2Shell.
Les deux failles sont évaluées à 9.2 selon CVSS v4.0, donc comme critiques. La conséquence est la même dans les deux cas : exécution de code malveillant à distance, sans que l'attaquant ait besoin de s'authentifier. Les spécialistes parlent d'« unauthenticated Remote Code Execution ». Qui peut exécuter du code sur le serveur peut, dans le pire des cas, lire des données, installer des portes dérobées ou utiliser le serveur pour d'autres attaques.
Point important pour la compréhension : la faille ne se trouve pas dans un CMS ou un plugin donné, mais dans PHP. Une mise à jour de WordPress, de Shopware ou de TYPO3 ne la referme donc pas.
Pourquoi la faille est-elle si grave ?
Trois points rendent PHP2Shell particulièrement délicate du point de vue des autorités de sécurité :
- Ampleur : les modes d'exécution courants de PHP sont concernés, à savoir PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables.
- Aucune connexion nécessaire : l'attaquant n'a besoin ni de mot de passe ni de compte utilisateur.
- Moment précoce : avec Apache et mod_php, selon l'équipe PHP, un exploit a été démontré avant même que le code de l'application ne s'exécute. Les fonctions de protection à l'intérieur du site web n'interviennent alors pas.
Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) a émis le niveau d'alerte 3 (orange). Il recommande la mise à jour immédiate et, si celle-ci n'est pas possible sur-le-champ, de déconnecter temporairement du réseau les serveurs web concernés.
Quels serveurs sont concernés par PHP2Shell ?
Les failles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions plus anciennes de ces branches sont concernées. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles ; selon la presse spécialisée, presque toutes les versions, jusqu'à PHP 5.4, sont concernées. Vous trouverez l'aperçu complet sur la page Quelles versions de PHP sont concernées ?.
Une particularité : les distributions Linux et les hébergeurs appliquent parfois les corrections sous forme de backport. Plesk continue alors par exemple d'afficher 8.2.34 alors que l'erreur est corrigée. Ce qui fait foi, ce sont l'état des paquets et la confirmation du fournisseur. Comment le vérifier, nous l'expliquons sous Bien vérifier la version de PHP et l'état des correctifs.
Qu'est-ce qui est établi, qu'est-ce qui reste ouvert ?
Sont établis les deux numéros CVE, les versions corrigées et les mesures transitoires publiées par php.net. Le 23 octobre s'est ajouté un avis concernant une autre faille, CVE-2026-115560, qui n'agit que dans une configuration inhabituelle.
Probable : les attaquants continuent de rechercher activement les serveurs non corrigés. Selon des reportages de médias, une première tentative d'attaque a déjà été observée le 17 octobre, donc avant la publication des correctifs. Cloudflare a signalé des tentatives d'attaque et a déployé des règles de protection, mais souligne que des règles fondées sur les seules données de la requête ne suffisent pas.
Reste ouvert : le nombre de serveurs déjà attaqués avec succès. Selon le BSI, des attaques réussies à grande échelle n'étaient d'abord pas connues. Il n'existe pas d'indicateurs de compromission (IOC) publiés et confirmés. Savoir si un serveur a été touché ne peut donc s'apprécier que par une analyse comportementale. Le déroulement dans le temps est résumé dans la chronologie du 17 au 25 octobre.
Ce que les entreprises devraient faire maintenant
- Clarifier qui est responsable : serveur en propre, serveur géré ou hébergeur.
- Mettre PHP à jour vers une version corrigée ou un backport confirmé.
- Redémarrer tous les processus PHP. De nouveaux fichiers seuls ne suffisent pas tant que d'anciens processus tournent en mémoire.
- Sauvegarder les journaux, et ce à partir du 20 octobre. La presse spécialisée conseille de conserver ces données.
- Rechercher des traces. Un correctif ne supprime aucun logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. La page Suis-je déjà compromis ? donne des indications à ce sujet.
Une mise à jour ferme la porte, mais ne fait pas le ménage. Si votre serveur était joignable entre le 17 octobre et le correctif, un examen des traces est une obligation et non un luxe.
Comment PHP SOS aide-t-il concrètement ?
Avec l'assistance immédiate PHP2Shell, nous prenons en charge les étapes que de nombreuses entreprises ne peuvent pas couvrir à court terme en interne :
- Inventaire : nous déterminons la version de PHP, le mode d'exécution et l'état des paquets de chaque serveur concerné.
- Correctif ou transition : nous installons la mise à jour ou, lorsque ce n'est pas encore possible, mettons en place les mesures transitoires de php.net et clarifions la question de savoir si le serveur doit être temporairement déconnecté du réseau.
- Redémarrage et attestation : nous redémarrons tous les processus PHP et documentons l'état avant et après.
- Examen des traces : nous sauvegardons les journaux à partir du 20 octobre et recherchons des anomalies, jusqu'à ce que l'incident soit clos et documenté.
Questions fréquentes
PHP2Shell est-elle une faille de WordPress ?
Non. Les failles se trouvent dans PHP, donc dans le langage de programmation sur lequel fonctionnent WordPress, Shopware, TYPO3 et de nombreux autres systèmes. Une mise à jour du CMS ne les referme donc pas. Ce qui compte, c'est la version de PHP sur le serveur.
Dois-je faire quelque chose moi-même en tant que client d'un hébergeur ?
Avec l'hébergement mutualisé, c'est en règle générale l'hébergeur qui installe la mise à jour de PHP. Vous devriez néanmoins vous faire confirmer par écrit que la version de PHP que vous utilisez a été corrigée et redémarrée. La mise à jour ne répond pas à la question de savoir si quelque chose s'est produit avant le correctif.
D'où vient le nom PHP2Shell ?
Le nom décrit la conséquence : via PHP, un attaquant peut, dans le pire des cas, obtenir une ligne de commande, c'est-à-dire un shell, sur le serveur. Les désignations officielles sont les numéros CVE-2026-109618 et CVE-2026-109619.
Mon site web a-t-il déjà été attaqué s'il a été mis hors ligne ?
Pas nécessairement. Certains fournisseurs ont mis des sites web hors ligne par précaution, comme le recommande le BSI lorsqu'une mise à jour n'est pas possible immédiatement. C'est une mesure de protection et non la preuve d'une attaque.