PHP2Shell (CVE-2026-109618 et CVE-2026-109619) : ce que les entreprises qui utilisent PHP doivent faire maintenant

Un technicien avec un ordinateur portable intervenant sur une baie de serveurs

Le 21 octobre 2026, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités qui « peuvent permettre une exécution de code à distance sans authentification ». Autrement dit : toute personne capable d'envoyer une requête HTTP à votre site web pourrait être en mesure d'exécuter son propre code sur votre serveur. Elle n'a besoin d'aucun mot de passe et, sur certaines configurations, l'attaque fonctionne avant que votre application n'ait exécuté une seule ligne. Le duo a été baptisé PHP2Shell, et PHP attribue aux deux failles la note de 9,2 (CVSS 4.0, sur une échelle de 10).

Ce guide s'adresse à ceux qui doivent agir : propriétaires de sites web et de boutiques en ligne en PHP, responsables informatiques, et toute personne dont un prestataire fait tourner PHP pour son compte. Il a été rédigé le 22 octobre 2026, le lendemain de la publication, à partir des avis de sécurité du projet PHP lui-même, des recommandations des agences nationales de cybersécurité et des chiffres publiés par les éditeurs. Là où les sources divergent, nous le signalons.

L'essentiel

Mettez à jour PHP lui-même, puis redémarrez-le. Mettre à jour WordPress, Drupal, Laravel ou une extension ne corrige pas le problème. La faille se trouve dans PHP, sous votre application.
Toute installation PHP qui répond à des requêtes web est concernée, selon PHP : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP considère Apache avec mod_php comme la configuration la plus à risque.
Près de la moitié des sites PHP tournent sur une branche pour laquelle le projet PHP ne publie plus de versions (notre lecture des données de W3Techs, ci-dessous). Pour ceux-là, il n'existe aucun paquet officiel à installer.
Les réglages et les pare-feu font gagner du temps, ils ne mettent pas à l'abri. PHP liste des mesures provisoires et précise qu'elles « ne rendent pas une installation sûre ».
Si vous ne pouvez pas appliquer le correctif aujourd'hui, les agences américaines, britanniques et européennes donnent le même conseil : déconnectez le système d'internet jusqu'à ce que ce soit possible.

Ce qui s'est passé, dans l'ordre

19 août 2026. Des chercheurs de Wiz découvrent la première des failles, selon leur publication, et les signalent à l'équipe de sécurité de PHP le 24 août. Des chercheurs de plusieurs autres entreprises sont également crédités dans les avis de PHP.
20 octobre. Les numéros CVE fuitent en ligne deux jours avant la divulgation prévue. PHP avance sa publication d'un jour, au 21 octobre à 14:00 UTC, et demande à tout le monde de se préparer.
21 octobre, 03:02 UTC. Cloudflare active des règles de pare-feu pour tous les clients qui disposent de son WAF, offre gratuite comprise. L'entreprise indique ensuite avoir « observé du trafic d'attaque ciblant nos clients » et avoir vu des attaquants « modifier la charge utile de l'attaque pour tenter de contourner nos protections ».
21 octobre, vers 14:00 UTC. PHP publie les correctifs et son avis de sécurité. Le même jour, la CISA aux États-Unis, le NCSC britannique, le CERT-EU et une déclaration commune de la Commission européenne, de l'ENISA, du CERT-EU, d'Europol et des CSIRT nationaux de l'UE demandent tous aux organisations d'appliquer les correctifs immédiatement.

Quelle est la gravité ?

Trois éléments distinguent cette affaire des correctifs mensuels habituels.

L'attaquant n'a besoin de rien d'autre qu'une requête. Aucune connexion, et personne n'a besoin de cliquer sur un lien. L'avis de PHP décrit un exploit démontré contre Apache avec mod_php, « où une requête non authentifiée peut déclencher l'attaque avant l'exécution de tout code applicatif ». Wiz a démontré des attaques contre les versions actuelles de WordPress, Drupal et Joomla, et note que « même une simple application “Hello World” tournant sur une version de PHP affectée peut être vulnérable ». Le code exécuté de cette manière dispose des droits du compte du serveur web, qui, sur la plupart des sites, peut lire la configuration de l'application : le mot de passe de la base de données, les clés API, les identifiants de messagerie et de paiement. Pour la seconde faille, CVE-2026-109619, PHP confirme aussi une divulgation de mémoire : des données de la mémoire du serveur qui fuient vers l'extérieur, même sans exécution de code complète.

Le parc installé est énorme. Selon W3Techs, PHP fait tourner 69,3 % des sites web dont le langage côté serveur est connu (chiffres du 22 octobre 2026). Unit 42, l'équipe de Palo Alto Networks, recense plus de 22,6 millions d'instances exposées potentiellement vulnérables, à partir de ses propres scans d'internet, et indique qu'au moins un gouvernement européen a mis son site web hors ligne par précaution.

Le développement d'exploits avance vite. Le CERT-EU indique que les premières preuves de concept « ont commencé à circuler ». L'entreprise de sécurité watchTowr affirme que ses honeypots enregistrent des exploitations depuis le 21 octobre. Cloudflare fait état de trafic d'attaque. Et Wiz indique que ses chercheurs ont utilisé des modèles d'IA tout au long de leurs travaux, si bien qu'un seul chercheur a fait en une semaine ce qui « aurait pris des mois à une équipe de classe mondiale ». Les attaquants qui adaptent un exploit à votre version de PHP disposent des mêmes outils.

Il faut aussi présenter l'autre versant : lorsque la CISA a publié son alerte le 21 octobre, elle n'avait pas observé d'exploitation, et aucune des deux failles ne figurait encore dans son catalogue Known Exploited Vulnerabilities (vulnérabilités exploitées connues). Red Hat classe le problème comme « Important » plutôt que critique, car un serveur Red Hat Enterprise Linux standard fait tourner PHP-FPM, où l'exploitation est plus difficile. Plus difficile ne veut pas dire impossible : PHP confirme qu'un des chemins d'attaque de la seconde faille fonctionne aussi sur PHP-FPM. Rien de tout cela ne change ce que vous devez faire. Cela change seulement le préavis dont vous disposerez.

Quelle version utilisez-vous ? Les chiffres

W3Techs publie aussi les versions de PHP utilisées par les sites web, en comptant les sites qui affichent leur version. En rapprochant ses deux tableaux du 22 octobre 2026 :

Branche PHP	Part des sites PHP	Correctif du projet PHP
8.3, 8.4, 8.5	environ 34 %	Oui : 8.3.36, 8.4.27, 8.5.12
8.2	environ 18 %	Oui : 8.2.35. Mais la 8.2 elle-même arrive en fin de vie le 31 décembre 2026
8.0, 8.1	environ 14 %	Aucune version publiée. 8.0 et 8.1 : backport source uniquement
7.x	26,9 %	Aucune version publiée. 7.4 : backport source uniquement ; 7.3 et antérieures : rien
5.x et antérieures	7,8 %	Rien

Ainsi, environ 48 % des sites PHP tournent sur une branche pour laquelle le projet PHP ne publie aucune version corrigée, et 18 % de plus reçoivent leur correctif maintenant et perdent le support dans dix semaines.

Deux réserves. W3Techs ne voit que les sites qui affichent leur version. Et une distribution Linux peut avoir corrigé elle-même une ancienne branche : c'est le cas d'Ubuntu, comme vous le verrez plus bas. Le numéro de version seul ne vous dit pas si vous êtes protégé. La version du paquet de votre éditeur, si.

Étape 1 : recenser toutes vos installations PHP

Vous ne pouvez pas corriger ce que vous n'avez pas recensé, et PHP se cache bien. Le NCSC britannique demande aux organisations de trouver chaque système PHP, en commençant par ceux qui sont exposés sur internet, et ajoute : « ne limitez pas la recherche aux versions obsolètes de PHP ». La déclaration commune de l'UE avertit que certains produits « peuvent être affectés par ces vulnérabilités même s'ils ne semblent pas utiliser PHP directement ».

Où chercher :

Sites web et boutiques : WordPress et WooCommerce, Drupal, Joomla, Magento et Adobe Commerce, Shopware, PrestaShop, TYPO3, et tout ce qui est construit sur Laravel ou Symfony.
Les oubliés : microsites de campagne, une ancienne version linguistique, serveurs de préproduction et de test accessibles depuis internet, le webmail ou le helpdesk que quelqu'un a installé il y a des années.
Conteneurs : chaque image construite à partir d'une image de base php embarque son propre PHP. Mettre à jour l'hôte n'y change rien.
Panneaux de contrôle d'hébergement : cPanel, Plesk et les panneaux similaires fournissent leurs propres builds de PHP à côté de celui du système. Chaque version activée dans le panneau est un élément distinct à mettre à jour.
Produits qui embarquent PHP : appliances, outils de supervision, CRM, helpdesks et interfaces d'administration d'éditeurs. Le NCSC néerlandais tient une liste publique de ces produits avec leur statut, éditeur par éditeur.
Prestataires : votre hébergeur, votre agence, tout service dont vous savez qu'il repose sur PHP. Demandez-leur par écrit quelles versions de PHP font tourner vos systèmes et quand elles seront corrigées.

Pour chacun, notez la version de PHP, la façon dont PHP est exécuté (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, un conteneur), s'il est accessible depuis internet, et qui est en mesure de le corriger.

Étape 2 : corriger, dans le bon ordre

Commencez par tout ce qui est accessible depuis internet et, parmi ces systèmes, par les configurations Apache avec mod_php.

Sur une branche supportée (8.2 à 8.5). Passez à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou au paquet de votre distribution qui contient le correctif. PHP indique que les distributions Linux ont reçu les correctifs à l'avance. Confirmé à ce jour :

Ubuntu : des paquets corrigés pour chaque version de 14.04 à 26.10. Sur 22.04 et les versions ultérieures, ils arrivent avec les mises à jour normales ; sur 20.04 et les versions antérieures, ils nécessitent un abonnement Ubuntu Pro, gratuit jusqu'à cinq machines (l'annonce de Canonical).
Debian : php8.4 8.4.27 pour Debian 13 (DSA-6574-1) et php8.2 8.2.35 pour Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux : le bulletin de sécurité RHSB-2026-013 de Red Hat liste les paquets par version.
Le dépôt Remi, très utilisé pour disposer de versions récentes de PHP sur les systèmes de la famille Red Hat : le 21 octobre, le CERT-EU a relevé qu'il ne proposait pas de paquets le jour de la publication et a conseillé de passer aux paquets de la distribution ou de compiler depuis les sources. Vérifiez s'il a rattrapé son retard avant de vous y fier.

Sur PHP 7.4, 8.0 ou 8.1. Le projet PHP ne publie aucune version pour ces branches. Son équipe de sécurité a réalisé des backports minimaux dans le code source pour les trois branches, utiles si vous compilez PHP vous-même. Sinon, le correctif doit venir de votre éditeur (Ubuntu Pro couvre par exemple PHP 7.4 sur Ubuntu 20.04) ou d'une mise à niveau de PHP. Pour quiconque est en 8.1 ou antérieure et ne peut pas mettre à jour, le conseil de la CISA est sans détour : mettez le système hors ligne jusqu'à ce qu'il soit corrigé ou mis à niveau.

Sur PHP 7.3 ou antérieure. Rien ne viendra du projet PHP. À moins qu'un éditeur ne corrige encore votre build, le choix se résume à une mise à niveau ou à la mise hors ligne du système.

Redémarrez après la mise à jour. Installer un paquet ne remplace pas le PHP déjà en cours d'exécution. L'annonce d'Ubuntu le dit clairement : l'application « devra probablement être redémarrée ». Redémarrez PHP-FPM, Apache, LiteSpeed ou le conteneur sur chaque serveur. Vérifiez ensuite la version que le serveur web exécute réellement, pas seulement php -v en ligne de commande, qui peut correspondre à un autre build.

Conteneurs : reconstruisez vos images à partir d'une image de base corrigée et redéployez-les. Un hôte corrigé qui fait tourner une ancienne image reste exposé.

Hébergement infogéré : demandez à votre prestataire la date et la version, puis vérifiez par vous-même.

Étape 3 : si vous ne pouvez pas corriger aujourd'hui

L'avis de PHP liste des mesures provisoires et les introduit par un avertissement : elles « réduisent l'exposition à certains chemins d'attaque, mais ne rendent pas une installation sûre ». En bref, pour la personne qui gère vos serveurs :

Pour CVE-2026-109618 : définissez memory_limit=-1 de façon que l'application ne puisse pas le redéfinir (par exemple avec php_admin_value dans le pool PHP-FPM ou dans la configuration Apache) ; fixez une valeur basse pour post_max_size (PHP suggère 8M sans upload de fichiers, 32M avec) ; limitez la taille des requêtes, le nombre de champs et le nombre de parties multipart au niveau du serveur web ou du proxy ; et utilisez une limite mémoire de conteneur ou de cgroup, jamais RLIMIT_AS ni RLIMIT_DATA.
Pour CVE-2026-109619 : définissez session.upload_progress.enabled=0 dans php.ini ou dans la configuration du serveur (pas avec ini_set() ni dans un fichier .user.ini) et redémarrez chaque worker. Sur PHP 8.5, définissez aussi fatal_error_backtraces=0.

Deux avertissements. Le réglage de session largement relayé le 20 octobre ne ferme que des chemins d'attaque de la seconde faille, comme l'a fait remarquer un membre de l'équipe de sécurité de PHP ; il ne fait rien contre la première. Et memory_limit=-1 supprime le plafond de mémoire propre à PHP, si bien qu'une seule requête lourde peut désormais épuiser le serveur. Associez-le à la limite de conteneur ou de cgroup.

Un pare-feu applicatif web aide, un peu. Les règles de Cloudflare sont actives par défaut sur toutes les offres qui incluent son WAF, l'offre gratuite comprise, et Palo Alto Networks ainsi que d'autres éditeurs ont publié leurs propres protections. Cloudflare demande malgré tout à ses clients de corriger PHP « même avec les protections du WAF », et l'entreprise a vu des attaquants modifier leurs charges utiles pour passer entre les mailles de ses règles. Un WAF ne protège en outre que le trafic qui passe par lui. Si votre serveur répond sur sa propre adresse IP, un attaquant peut le contourner.

Si rien de tout cela ne peut être fait rapidement, la CISA, le CERT-EU, le NCSC et la déclaration commune de l'UE vont tous dans le même sens : retirez le système de l'internet public jusqu'à ce qu'il soit corrigé. Une page de maintenance pendant une journée coûte moins cher qu'un serveur reconstruit.

Étape 4 : vérifier si vous avez déjà été touché

La fenêtre s'est ouverte le 20 octobre, avec le début de la fuite, et du trafic d'attaque a été signalé le lendemain matin. Si un système était accessible et non corrigé pendant cette fenêtre, le correctif ferme la porte, mais ne vous dit pas si quelqu'un est entré avant. Le NCSC demande à quiconque n'a pas pu corriger immédiatement de rechercher des signes de compromission et des portes dérobées.

Ce qu'il faut rechercher, d'après les recommandations publiées et la pratique courante de la réponse aux incidents :

Des processus PHP qui font ce que PHP ne fait jamais, comme lancer un shell ou télécharger des outils (CISA).
Des requêtes multipart inhabituelles suivies d'erreurs de limite mémoire ou de réponses HTTP 500 répétées, des workers PHP qui redémarrent sans raison claire, et des cookies PHPSESSID anormalement grands ou malformés dans les réponses (Wiz).
Des fichiers PHP nouveaux ou modifiés dans les dossiers d'upload, les dossiers de cache ou la racine web, de nouveaux comptes administrateur dans votre CMS, et des tâches planifiées que personne n'a créées.

Des journaux propres ne sont pas une preuve. L'avis de PHP sur la seconde faille met précisément en garde contre cela, et Wiz note que les journaux applicatifs peuvent contenir peu de contexte.

Si vous trouvez quelque chose, traitez-le comme un incident, pas comme un chantier de correctifs. Isolez le serveur, conservez les preuves, faites appel à un prestataire de réponse aux incidents, et changez chaque secret que le serveur web pouvait lire : mots de passe de base de données, clés API, identifiants de paiement et de messagerie, clés de signature. Comme la seconde faille peut divulguer de la mémoire, envisagez de renouveler les plus sensibles de ces secrets sur tout serveur resté exposé et non corrigé pendant des jours, même sans signe d'intrusion.

Étape 5 : ce que vous devrez peut-être signaler

Une vulnérabilité seule n'est pas un incident à signaler. Une vulnérabilité exploitée peut l'être.

NIS2 : si votre organisation est dans le champ de la directive et qu'une compromission constitue un incident important, l'alerte précoce à votre CSIRT national doit être transmise sous 24 heures. Consultez notre guide NIS2.
RGPD : si quelqu'un a accédé à des données personnelles, l'autorité de contrôle doit être notifiée dans les 72 heures après que vous avez pris connaissance de la violation, à moins qu'elle ne soit pas susceptible d'engendrer un risque pour les personnes. Consultez notre guide RGPD.
Cyber Resilience Act : si vous vendez un logiciel ou un appareil qui embarque PHP, vous en êtes le fabricant au sens du CRA. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées dans leurs produits via la plateforme unique de signalement du CRA, comme le rappelle la déclaration commune de l'UE. Consultez notre guide du CRA.
Vos clients : si vous hébergez ou exploitez PHP pour des clients, ils vous poseront la question. Une courte note écrite (ce que vous faites tourner, quand le correctif a été appliqué, ce que vous avez vérifié) répond à la plupart d'entre eux, et c'est la même note qu'un auditeur ou un cyberassureur voudra voir.

Après l'urgence : ce qu'il faut changer

Sur la plupart des serveurs bien gérés, PHP2Shell sera corrigé en quelques jours. Ce que la faille a révélé de votre environnement restera vrai ensuite.

Sachez combien de temps vous prend un correctif. De l'avis de sécurité au redémarrage de chaque serveur : des heures, des jours ou des semaines ? Si la réponse honnête est « il faudrait demander à l'agence », réglez ce point avant la prochaine fois. Quand des chercheurs disent que l'IA a ramené leur développement d'exploits de plusieurs mois à une semaine, partez du principe que les attaquants peuvent aller à ce rythme eux aussi.
Conservez l'inventaire que vous venez de constituer. C'était la partie la plus difficile de la réponse, et il devient obsolète dès que personne n'en est responsable.
Quittez les versions de PHP en fin de vie. Un site en 7.4 ou 8.1 avait besoin cette fois d'un éditeur ou d'un backport source ; la prochaine fois, il n'y aura peut-être ni l'un ni l'autre. PHP 8.2 arrive en fin de vie le 31 décembre 2026 : un site qui quitte la 8.1 doit donc passer directement à la 8.3 ou à une version ultérieure. Changer de version de PHP implique souvent de mettre aussi à jour l'application : notre article sur la fin de vie de Drupal, Umbraco et Kentico montre ce que cela représente pour un CMS.
Préférez PHP-FPM à mod_php quand c'est possible. C'était la configuration la moins risquée cette fois-ci.
Laissez la progression d'upload désactivée si vous ne vous en servez pas. L'avis de PHP suggère de garder session.upload_progress.enabled désactivé même après le correctif lorsque l'application n'en a pas besoin.
Inscrivez les délais de correction dans vos contrats. Demandez à votre hébergeur et à votre agence en combien de temps ils appliquent les correctifs critiques de PHP, et obtenez la réponse par écrit.

Une liste de contrôle pour cette semaine

Recensez chaque installation PHP, y compris les conteneurs, les panneaux de contrôle, les produits d'éditeurs et les serveurs de préproduction.
Corrigez d'abord les systèmes exposés sur internet, en commençant par Apache mod_php.
Redémarrez chaque processus PHP et vérifiez la version que le serveur web indique.
Reconstruisez et redéployez les images de conteneurs.
Là où vous ne pouvez pas corriger aujourd'hui, appliquez les réglages provisoires de PHP, faites passer le trafic par un WAF ou mettez le système hors ligne.
Demandez par écrit à vos prestataires et à vos hébergeurs leur version de PHP et leur date de correction.
Examinez les journaux et les modifications de fichiers sur tout ce qui a été exposé et non corrigé depuis le 20 octobre.
Déterminez si une obligation de signalement (NIS2, RGPD, CRA) s'applique.
Planifiez l'abandon de PHP 8.1 et des versions antérieures, et celui de la 8.2 avant le 31 décembre.

Comment nous pouvons vous aider

La plupart des entreprises ne manquent pas de volonté pour appliquer les correctifs. Ce qui leur manque, c'est une vision claire de ce qu'elles font tourner, ou les personnes pour faire le travail cette semaine. C'est cette partie que nous prenons en charge :

Inventaire et correctifs, en quelques jours. Nous trouvons vos installations PHP sur vos serveurs, vos conteneurs, vos panneaux d'hébergement et chez vos prestataires, nous les corrigeons, redémarrons et vérifions, et nous vous laissons un compte rendu écrit de ce qui a été fait et quand. Ce compte rendu est aussi votre réponse aux clients et aux auditeurs.
Sortir des anciennes versions de PHP. Les applications bloquées sur PHP 7.x, 8.0 ou 8.1 parce que le code ne tourne sur rien de plus récent : nous les portons vers une version supportée dans le cadre de notre service de maintenance des systèmes existants.
Durcissement et routine de correctifs, pour que le prochain avis de sécurité soit une tâche planifiée plutôt qu'une urgence.

Si vous trouvez des signes d'intrusion, appelez d'abord un prestataire de réponse aux incidents. Nous pouvons prendre en charge la reconstruction et la mise à niveau à ses côtés.

Écrivez à office@c9group.dev en nous indiquant ce que vous faites tourner, et nous vous répondrons avec ce que nous ferions en premier.

Sources

Sources vérifiées le 22 octobre 2026. La situation évolue encore : le statut d'exploitation et les paquets des éditeurs, en particulier, peuvent avoir changé depuis.

Projet PHP

Agences

Chercheurs, éditeurs et données