PHP2Shell : la faille PHP qui a poussé préfectures, ministères et géants du web à couper leurs sites

Deux failles critiques découvertes dans le cœur de PHP, baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), ont provoqué cette semaine l’une des plus grosses mobilisations de l’histoire du web. Annoncées par l’équipe de sécurité de PHP le mardi 20 octobre 2026, corrigées en urgence le lendemain, elles permettent à un attaquant d’exécuter du code sur un serveur sans même avoir de compte. Résultat : en France, le ministère de l’Intérieur, Météo-France, le site des impôts ou encore la mairie de Toulouse ont basculé en maintenance. En Italie, au Brésil, en Allemagne ou au Japon, même réflexe. Voici ce qui s’est passé, ce que dit vraiment php.net, et où en sont les mises à jour.

Précisons tout de suite une chose, parce qu’on l’a beaucoup lu sur les réseaux sociaux : non, « tous les sites du monde » n’ont pas été piratés. La grande majorité des coupures étaient volontaires. Des administrateurs ont préféré fermer boutique quelques heures plutôt que de laisser un serveur vulnérable exposé pendant qu’ils installaient le correctif. Un site en maintenance n’est pas un site hacké. Mais le risque, lui, était bien réel.

Ce que php.net a annoncé, étape par étape

Le déroulé officiel tient en deux messages publiés sur le site du projet.

Le 20 octobre, l’équipe de sécurité de PHP publie un avis préalable assez sobre : une version de sécurité sortira le mercredi 21 octobre à 14 h UTC (16 h à Paris et à Rome), elle corrige deux vulnérabilités critiques notées 9,2 sur l’échelle CVSS v4.0, et tout le monde est invité à se préparer. Le texte précise que l’équipe se réserve le droit d’avancer la sortie si des détails fuitent ou si des attaques apparaissent. Ce n’était pas une précaution de style.

Le 21 octobre, vers 13 h 35 UTC, soit avec un peu d’avance sur l’horaire annoncé, quatre versions sortent d’un coup : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles s’accompagnent d’un bulletin intitulé, sans détour, « Critical remote code execution vulnerabilities, update now ». Le message du projet est limpide : la mise à jour est la seule solution sûre, aucun réglage ne protège complètement.

Le bulletin apporte plusieurs précisions qui comptent :

• toutes les installations de PHP qui répondent à des requêtes web sont concernées, quel que soit le mode d’exécution : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed ;
• le risque est jugé maximal avec mod_php, pour lequel une attaque fonctionnelle a été démontrée avant même que le code de l’application ne s’exécute ;
• les distributions Linux et les éditeurs de support longue durée ont reçu les correctifs en avance ;
• PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles, mais vu la gravité, l’équipe a publié des correctifs minimaux sous forme de code source pour PHP 7.4, 8.0 et 8.1 ;
• le dépôt communautaire rpms.remirepo.net, très utilisé sur les serveurs Red Hat, AlmaLinux ou Rocky Linux, n’allait pas être mis à jour le jour même. PHP conseillait donc à ses utilisateurs de passer aux paquets de leur distribution ou de compiler eux-mêmes.

Le bulletin liste enfin des mesures temporaires pour ceux qui ne peuvent pas mettre à jour immédiatement, en prenant soin de dire qu’elles réduisent l’exposition sans rendre une installation sûre. Nous les détaillons dans notre guide pratique (voir plus bas).

Deux failles, un même point faible : la gestion de la mémoire

Sans entrer dans les entrailles du moteur Zend, on peut résumer les deux failles ainsi.

CVE-2026-109618 : quand PHP manque de mémoire au mauvais moment

PHP impose une limite de mémoire à chaque requête (le fameux memory_limit). La première faille exploite ce qui se passe quand cette limite est atteinte en plein milieu de la préparation d’une requête. PHP s’interrompt alors que certaines données internes ne sont qu’à moitié construites. Ensuite, la phase de nettoyage passe sur ces données et les traite comme si elles étaient valides. C’est ce qu’on appelle une corruption mémoire, et un attaquant habile peut la transformer en exécution de code.

Le détail qui fait froid dans le dos : l’épuisement de la mémoire peut être provoqué depuis l’extérieur, avec une requête d’envoi de fichier (un formulaire « multipart ») fabriquée pour l’occasion. Pas besoin de compte, pas besoin de mot de passe.

CVE-2026-109619 : les restes d’une requête précédente

La seconde faille est plus sournoise. Un serveur PHP moderne ne lance pas un nouveau processus à chaque visiteur : il garde des « workers » qui enchaînent les requêtes. Normalement, chaque requête repart d’une page blanche. Sauf qu’ici, une partie de l’état interne d’une requête peut survivre après la libération de la mémoire qui la contenait. La requête suivante traitée par le même worker peut alors utiliser ces restes avant qu’ils ne soient remis à zéro. Les spécialistes parlent de « use-after-free », une catégorie de bug classée CWE-416 par le Centre canadien pour la cybersécurité dans son alerte.

D’après les avis techniques publiés sur GitHub, deux chemins d’attaque sont confirmés : la fonction de suivi de progression des envois de fichiers (session.upload_progress), activée par défaut, et sur PHP 8.5, l’affichage des traces lors des erreurs fatales (fatal_error_backtraces).

Une image pour fixer les idées : imaginez un serveur de restaurant qui ne débarrasse pas complètement la table entre deux clients. Le suivant tombe sur un ticket oublié et peut, en le remplissant habilement, se faire servir ce qu’il veut en cuisine.

Des failles très anciennes

Le plus inquiétant, c’est leur âge. Selon l’analyse publiée par Google Cloud, toutes les versions de PHP depuis la 5.4 jusqu’à la 8.5.11 sont vulnérables. Autrement dit, du code présent depuis plus d’une décennie. Le laboratoire watchTowr confirme que les branches abandonnées, PHP 5 compris, sont touchées.

Pourquoi « PHP2Shell » et comment l’affaire a fuité

Le surnom vient des chercheurs : la faille permet d’obtenir un « shell », c’est-à-dire une ligne de commande sur le serveur visé. La découverte revient à l’équipe de Calif, qui a travaillé avec OpenAI et des outils d’intelligence artificielle durant l’été. La chronologie reconstituée par la PHP Foundation situe le signalement à l’équipe de sécurité de PHP au 11 août 2026, OpenAI ayant identifié la même cause de son côté le même jour. Les chercheurs de Wiz ont ensuite repéré d’autres variantes et démontré des attaques sur WordPress, Drupal et Joomla en environnement de test.

La publication coordonnée était prévue pour le jeudi 22 octobre. Elle n’a pas tenu. Le 20 octobre au matin, un message sur Hacker News annonce l’existence de deux failles d’exécution de code dans PHP. Dans la journée, les identifiants CVE circulent. Le soir, l’équipe PHP avance la sortie au 21. Et selon la PHP Foundation, une entreprise (Chainguard) a publié tôt le 21 au matin des images contenant déjà le correctif, ce qui permettait de comparer le code avant et après et d’en déduire la faille avant la sortie officielle.

La fondation a d’ailleurs reconnu publiquement des lenteurs : des indices du problème remontaient à un audit mené en 2024, sans qu’un scénario d’attaque concret ait été démontré à l’époque.

Le rôle de l’intelligence artificielle dans cette découverte n’est pas anodin. Nous avions déjà évoqué ce basculement avec GPT-6 Astra, le modèle d’OpenAI qui a franchi un seuil critique en cybersécurité : les mêmes outils qui aident les chercheurs à trouver des failles peuvent aussi raccourcir le travail des attaquants.

Concrètement, que peut faire un pirate avec PHP2Shell ?

La formule technique est « exécution de code à distance sans authentification ». En clair, quelqu’un qui envoie les bonnes requêtes à votre serveur peut lui faire exécuter ses propres instructions, avec les droits du processus PHP. À partir de là, tout dépend de la configuration, mais la liste des dégâts possibles est longue :

• vol de la base de données (clients, commandes, adresses, mots de passe chiffrés) ;
• récupération des clés d’API stockées dans les fichiers de configuration (paiement, envoi d’e-mails, services cloud) ;
• dépôt d’une porte dérobée qui restera active même après la mise à jour ;
• modification des pages, injection de scripts malveillants, redirections vers des arnaques ;
• utilisation du serveur pour miner de la cryptomonnaie ou attaquer d’autres sites.

La seconde faille ajoute un risque supplémentaire : la fuite d’informations présentes en mémoire, ce qui peut inclure des jetons de session ou des secrets applicatifs. C’est pour cela que beaucoup d’experts conseillent de changer les clés sensibles après coup, même si aucun signe d’intrusion n’est visible.

Pourquoi un tel affolement ? Parce que PHP fait tourner l’essentiel du web. Selon W3Techs, il était détecté le 21 octobre sur 69,3 % des sites dont on connaît le langage côté serveur. WordPress, WooCommerce, Drupal, Joomla, PrestaShop, Magento, Moodle, la plupart des hébergements mutualisés et une foule de panneaux d’administration reposent dessus.

Les sites mis hors ligne : la liste, pays par pays

Il n’existe pas de recensement complet et vérifié. Voici ce qui a été documenté par les autorités, les médias et les organismes eux-mêmes entre le 20 et le 22 octobre.

En France : l’ANSSI recommande de couper

C’est en France que la réaction a été la plus visible. L’ANSSI a recommandé de mettre hors ligne les serveurs concernés jusqu’à l’installation du correctif, et a recensé plus de 600 000 serveurs utilisant PHP sur l’Internet français. À sa demande, le ministère de l’Intérieur a placé en « maintenance préventive » l’ensemble de ses sites exposés.

Parmi les sites devenus inaccessibles le mercredi 21 octobre :

• les sites des préfectures, qui ont relayé leurs informations par les réseaux sociaux et par affichage ;
• le site de la Préfecture de police ;
• Météo-France ;
• le site des impôts, toujours en maintenance le jeudi 22 au matin ;
• le site de la mairie et de la métropole de Toulouse, qui affichait encore une page de maintenance le lendemain.

Beaucoup d’internautes ont découvert à cette occasion que leur déclaration ou leur prise de rendez-vous en préfecture dépendait d’un langage de programmation dont ils n’avaient jamais entendu parler.

En Italie : GARR, des communes et l’alerte du CSIRT

En Italie, le consortium GARR, qui gère le réseau national de l’enseignement et de la recherche, a annoncé le 21 octobre avoir isolé certaines de ses plateformes par précaution, le temps d’appliquer les correctifs. La commune de Montemurlo, en Toscane, a suspendu ses portails et plusieurs applications de gestion dès l’après-midi. Le CSIRT Italia, rattaché à l’Agence nationale de cybersécurité (ACN), a diffusé un bulletin d’alerte relayé notamment par le CSIRT Toscana.

Ailleurs en Europe

D’après Reuters, des sites gouvernementaux ont été coupés en Allemagne, aux Pays-Bas, en Belgique, en Finlande et en République tchèque, avec des services municipaux, scolaires et hospitaliers touchés dans plusieurs pays. Le Royaume-Uni et le Danemark figurent aussi parmi les pays cités par la presse française. Côté hébergeurs, l’allemand Netcup a mis ses offres d’hébergement hors ligne le temps de corriger, et Uberspace a carrément désactivé PHP à partir de 15 h 45 le 21 octobre. La Wikimedia Foundation a coupé certains outils utilisés par les développeurs bénévoles, sans fermer Wikipédia.

Amériques et Asie

Au Brésil, le Tribunal régional fédéral de la 1re région a suspendu l’accès externe à son système de gestion documentaire SEI, tout comme le Tribunal des comptes de l’État du Tocantins. Aux États-Unis, l’ICANN a désactivé temporairement certains services et la NSA a appelé à une mise à jour immédiate. Au Japon, des plateformes très populaires comme niconico et pixiv sont passées en maintenance juste avant la sortie du correctif, selon le site Gigazine.

Les attaques ont-elles vraiment commencé ?

Oui, des tentatives ont été observées. Cloudflare a indiqué voir du trafic malveillant visant ces failles dès le matin du 21 octobre, avant même la sortie du correctif, ainsi que des variations répétées des requêtes pour contourner ses filtres. Le laboratoire watchTowr dit avoir constaté une exploitation réelle à partir du 21 via son réseau de pots de miel. Au 22 octobre en revanche, la CISA américaine n’avait pas encore inscrit les deux failles dans son catalogue des vulnérabilités activement exploitées.

Ce qu’on ne sait pas encore, c’est combien de sites ont réellement été compromis. Personne n’a publié de bilan fiable, et il faut se méfier des chiffres spectaculaires. Ce que mesurent les moteurs de scan, c’est l’exposition : selon Censys, environ 1,5 million d’hôtes sur 2,6 millions affichaient une version de PHP sans correctif disponible, et quelque 884 000 serveurs exposés tournaient encore, le 20 octobre, sous PHP 8.1 ou plus ancien. Ce sont ces serveurs oubliés, qu’aucune mise à jour officielle ne viendra sauver, qui inquiètent le plus pour les semaines à venir.

Comment le monde se met à jour

La correction se joue à trois niveaux : les distributions Linux qui fabriquent les paquets, les hébergeurs qui les installent, et les services de protection qui filtrent le trafic en attendant.

Les distributions Linux

Ubuntu a publié son avis USN-8948-1 dès le 21 octobre, avec des correctifs pour les versions 26.10, 26.04 LTS, 24.04 LTS et 22.04 LTS. Attention, piège classique : Ubuntu intègre la correction sans changer le numéro de version principal. Un Ubuntu 24.04 corrigé affiche toujours PHP 8.3.6, c’est le numéro du paquet qui change (8.3.6-0ubuntu0.24.04.13). Debian 13 propose PHP 8.4.27 dans ses dépôts de sécurité, alors que Debian 12 était encore en attente d’un avis au moment de nos vérifications. Red Hat, Rocky Linux, Fedora et Amazon Linux ont publié leurs propres bulletins. Enfin, le dépôt d’Ondřej Surý (sury.org), très populaire sur Debian et Ubuntu, a rétroporté la correction jusqu’à PHP 5.6, ce qui a évité une migration en catastrophe à beaucoup d’administrateurs.

Les hébergeurs

La plupart des grands hébergeurs ont communiqué dans la journée du 21. Quelques exemples :

Le cas d’o2switch, vérifié par Clubic, illustre bien la nuance : un hébergeur peut avoir mis en place des protections temporaires tout en faisant encore tourner, quelques heures après la sortie du correctif, des binaires antérieurs. Protégé ne veut pas forcément dire corrigé.

Cloudflare et les pare-feu applicatifs

Cloudflare a activé des règles dédiées à PHP2Shell dès 3 h 02 UTC le 21 octobre, y compris pour les sites en offre gratuite. CloudLinux, qui équipe de nombreux hébergements mutualisés sous cPanel, a fait de même via son pare-feu Imunify360, avec une limite notable : ses règles bloquent l’attaque publique sur les serveurs Apache mais se contentent de la journaliser sur LiteSpeed. Tous le répètent : un pare-feu est une couche de protection, pas un correctif.

WordPress : pas de mise à jour à attendre

Point qui a semé la confusion : WordPress.org a confirmé qu’aucune mise à jour du cœur de WordPress n’est prévue, puisque le problème se situe dans PHP, sous WordPress. Mettre à jour vos extensions et votre thème reste une bonne habitude, mais cela ne corrige pas PHP2Shell.

Les autorités de cybersécurité sur le pont

Rarement une faille aura suscité autant d’alertes simultanées. La CISA américaine a appelé dès le 21 octobre à corriger immédiatement. Le NCSC britannique a recommandé de mettre à jour ou de mettre PHP hors ligne. Le CERT-EU a publié son avis 2026-018, l’ENISA une déclaration commune européenne, le Centre canadien pour la cybersécurité son alerte AL26-026. Les agences australienne et japonaise ont fait passer le même message. En France, l’ANSSI est allée jusqu’à recommander la coupure des serveurs non corrigés, ce qui explique l’ampleur des maintenances côté administration.

Ce que vous devez faire, en résumé

Si vous gérez un site, la question n’est pas « suis-je concerné ? » (vous l’êtes, si vous utilisez PHP) mais « qui doit appliquer le correctif ? ».

• Sur un hébergement mutualisé ou managé, c’est l’hébergeur. Vérifiez sa page de statut ou demandez-lui explicitement si le correctif du 21 octobre est installé.
• Sur un VPS ou un serveur dédié, c’est vous. Mettez à jour les paquets PHP, puis redémarrez PHP-FPM ou Apache.
• Sous PHP 8.1 ou plus ancien, planifiez la migration vers une version supportée, en vérifiant d’abord si votre distribution ou votre hébergeur fournit un correctif.

Nous avons préparé un guide pas à pas pour les indépendants, les petites boutiques en ligne et les sites vitrines : Faille PHP2Shell : comment protéger et mettre à jour un petit site.

Et votre ordinateur, il est protégé ?

Soyons honnêtes : aucun antivirus installé sur votre PC ne corrige une faille située dans PHP, sur un serveur. Ce travail revient à la mise à jour, et à elle seule. Mais les crises de ce genre ont une seconde vague, beaucoup plus banale et tout aussi efficace. Dans les jours qui suivent, les escrocs envoient de faux e-mails « de votre hébergeur » ou « de l’ANSSI » qui invitent à « appliquer le correctif » via un lien piégé, ou à télécharger un prétendu outil de vérification. Et l’ordinateur sur lequel vous gérez votre site contient ce qui intéresse le plus un pirate : vos accès FTP et SSH, vos mots de passe d’administration, vos clés d’API.

C’est là qu’une suite de sécurité récente est utile. Les éditeurs mettent à jour leurs bases de signatures et leurs filtres anti-hameçonnage en continu, et les grandes suites ajoutent désormais une protection web qui bloque les pages frauduleuses, un pare-feu et, souvent, un gestionnaire de mots de passe. Voici celles que nous recommandons pour protéger le poste de travail d’un administrateur de site ou d’une petite entreprise, avec leurs prix relevés le 23 octobre 2026.

Pour un indépendant qui gère un seul ordinateur et un téléphone, une formule trois appareils suffit largement. Une petite équipe aura plutôt intérêt à regarder les formules cinq ou dix appareils, dont le prix par poste devient vite très faible.

Notre boîte à outils pour sécuriser votre site et vos données

Au-delà de l’antivirus, quelques équipements simples changent vraiment la donne quand une faille comme PHP2Shell tombe un mardi soir : une clé de sécurité pour verrouiller vos comptes d’hébergement, un support de sauvegarde hors ligne que personne ne peut chiffrer à distance, et de quoi garder votre matériel en état de marche.

Questions fréquentes sur la faille PHP2Shell

Qu’est-ce que PHP2Shell exactement ?

C’est le surnom de deux failles critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10. Elles permettent à un attaquant non authentifié d’exécuter du code sur un serveur web qui utilise une version non corrigée de PHP.

Mon site WordPress est-il concerné ?

Très probablement, puisque WordPress fonctionne avec PHP. Ce qui compte, c’est la version de PHP installée sur le serveur et le fait que votre hébergeur ait appliqué ou non le correctif. Vous trouverez la version dans Outils, puis Santé du site, onglet Infos, rubrique Serveur.

Quelle version de PHP est sûre ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou plus récentes. Sur Ubuntu et Debian, un numéro plus ancien peut être corrigé : il faut regarder la version du paquet. PHP 8.3.35, sortie en septembre, n’est pas protégée.

Faut-il mettre à jour WordPress, PrestaShop ou mes extensions ?

Ce n’est pas suffisant. La faille se trouve dans PHP lui-même. Seule la mise à jour de PHP sur le serveur la corrige.

Pourquoi le site des impôts ou des préfectures était-il inaccessible ?

À la demande de l’ANSSI, le ministère de l’Intérieur et d’autres administrations ont mis leurs sites exposés en maintenance préventive le temps d’installer les correctifs. Il ne s’agissait pas d’un piratage avéré.

Est-ce dangereux de faire des achats en ligne en ce moment ?

Pas en soi. La faille touche les serveurs, pas votre ordinateur ou votre téléphone. Restez simplement attentif aux e-mails et SMS inhabituels, et suivez les consignes d’un site si celui-ci signale un incident.

Ma version PHP 7.4 ou 8.1 sera-t-elle corrigée ?

Pas par le projet PHP via une version officielle. Certaines distributions, le dépôt sury.org, cPanel ou des éditeurs de support étendu proposent des correctifs rétroportés. La vraie sortie reste la migration vers PHP 8.2 minimum, idéalement 8.4 ou 8.5, sachant que PHP 8.2 ne sera plus maintenu après le 31 décembre 2026.

Une alerte qui laissera des traces

PHP2Shell restera sans doute comme l’un des épisodes de sécurité marquants de 2026. Pas seulement par sa gravité, mais parce qu’il a rappelé qu’une préfecture, une mairie, un forum japonais et une petite boutique en ligne reposent souvent sur la même brique logicielle, maintenue par une équipe réduite. Le correctif existe depuis le 21 octobre. Le vrai danger, désormais, ce sont les serveurs que personne ne pense à mettre à jour.

Votre hébergeur vous a-t-il prévenu, ou avez-vous découvert le problème en lisant la presse ? Racontez-nous votre expérience en commentaire, et retrouvez notre guide pratique pour mettre à jour PHP et sécuriser votre site.

Sources principales : bulletin de sécurité de php.net (20 et 21 octobre 2026), avis de la CISA, du Centre canadien pour la cybersécurité, de Google Cloud, de watchTowr, de la PHP Foundation, de WordPress.org, de Cloudflare, et articles de Clubic, Melles750, Renseignement Économique, macitynet.it, tuttotech.net et Gigazine. Article mis à jour le 23 octobre 2026.

En tant que Partenaire Amazon, Wanda-techs réalise un bénéfice sur les achats remplissant les conditions requises. Cela n’affecte ni notre analyse indépendante, ni le prix que vous payez.