Ce qui s'est passé le 21 octobre
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619, et le surnom PHP2Shell. Elles sont notées 9,2 sur 10. Concrètement, une requête web bien formée suffit pour exécuter du code sur le serveur, avant même que le site ou l'application se lance. Pas besoin de compte, pas besoin de mot de passe, pas besoin que le site ait un bug : la faille est dans PHP lui-même.
L'affaire a commencé par une fuite. Mardi 20 octobre, en fin d'après-midi, un message sur Hacker News a annoncé deux vulnérabilités critiques sous embargo. La société watchTowr a confirmé le soir même qu'elles étaient réelles, et PHP a annoncé un correctif pour le lendemain à 14 h UTC. Entre-temps, des pages prétendant publier un exploit ont circulé, Cloudflare a activé des règles de pare-feu pour tous ses clients dès 3 h 02 UTC, et a vu des attaquants modifier leurs charges pour les contourner. On sait depuis qu'Amazon avait reçu une première tentative d'exploitation sur ses pièges dès le 17 octobre, quatre jours avant les correctifs. Les correctifs sont sortis mercredi avec une petite avance : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Le signal le plus parlant : dans l'après-midi, le ministère de l'Intérieur a mis hors ligne les sites de toutes les préfectures à la demande de l'ANSSI, « mise en maintenance préventive de l'ensemble de ses sites Internet exposés à une vulnérabilité critique de sécurité », et Météo-France a fermé ses sites de prévisions et de vigilance de sa propre initiative. Une partie du portail des impôts a été coupée aussi selon la presse, et le lendemain la CAF, Ameli, l'URSSAF et le CNES sont passés en maintenance à leur tour, pendant qu'Orange suspendait quelques sites et applications de ses filiales. Les Pays-Bas ont éteint DigiD et MijnOverheid, la Finlande ses services publics en ligne, des conseils municipaux britanniques et des services danois ont fait pareil. Aucun de ces sites n'a signalé d'intrusion : c'est une mesure de précaution, exactement celle que recommande le CERT-FR quand on ne peut pas corriger tout de suite. Si l'État coupe ses propres sites plutôt que de prendre le risque, un site d'entreprise qui tourne sur PHP n'a pas de raison de se croire à l'abri.
Le point qui change tout : PHP 8.1, 8.0, 7.4 et les versions plus anciennes ne reçoivent pas de nouvelle version. Le projet a publié des correctifs source pour 7.4, 8.0 et 8.1, à compiler soi-même ou à obtenir de son hébergeur, mais rien d'officiel ne sera installé tout seul. Or, selon W3Techs, environ un site PHP sur quatre tourne encore en PHP 7. Si c'est le vôtre, personne ne le corrigera à votre place.
Le CERT-FR, l'équipe de l'ANSSI, a publié le jour même l'alerte CERTFR-2026-ALE-014 : isoler les systèmes touchés, puis passer à une version maintenue et corrigée. Les contournements qui circulent, comme désactiver session.upload_progress ou bloquer les envois de fichiers, réduisent la surface d'attaque pour une seule des deux failles. Ils ne remplacent pas la mise à jour.
PHP2Shell, c'est quoi ? Le surnom donné aux deux failles : une requête web spécialement formée permet d'exécuter des commandes sur le serveur, un « shell », à travers PHP, sans compte ni mot de passe. Il n'y a pas de virus PHP2Shell à chercher sur votre ordinateur. C'est un défaut du moteur PHP lui-même, sur le serveur, et il se corrige par les versions du 21 octobre.
Quelle version de PHP est corrigée ?
Le correctif n'existe que pour les branches encore maintenues. PHP 8.5 passe en 8.5.12, PHP 8.4 en 8.4.27, PHP 8.3 en 8.3.36 et PHP 8.2 en 8.2.35, et c'est la dernière branche corrigée : elle s'arrête le 31 décembre 2026, donc le passage en 8.3 ou 8.4 est de toute façon à prévoir avant la fin de l'année. PHP 8.1 est en fin de vie depuis le 31 décembre 2025, PHP 8.0 et 7.4 depuis plus longtemps : pour ces trois-là, PHP a publié des correctifs source à compiler soi-même, et certains hébergeurs ou distributions Linux les intègrent dans leurs paquets. PHP 7.3 et plus anciens, PHP 5 : rien, et watchTowr considère que toutes les versions depuis PHP 5.4 sont concernées. Changer de branche est la seule issue.
Le numéro qui compte est celui que votre site utilise vraiment, pas celui d'une ligne de commande sur le serveur : un hébergement peut faire tourner plusieurs versions côte à côte.
Sur WordPress ou WooCommerce : Outils, puis Santé du site, onglet Infos, rubrique Serveur, ligne « Version de PHP ». Mettre à jour WordPress, un thème ou un plugin ne change pas ce numéro.
Chez o2switch : dans cPanel, rubrique Logiciels, l'outil « Sélectionner une version de PHP » affiche la version courante dans un menu déroulant. Choisissez 8.3 ou 8.4 puis « Apply », en laissant cochées les extensions par défaut. Attention, la version « native » cochée par défaut est PHP 8.1, qui n'a pas de correctif : le pas à pas complet et ce qu'o2switch a fait le 21 octobre sont dans le guide o2switch.
Chez OVHcloud : espace client, Web Cloud, Hébergements, votre hébergement, onglet Informations générales, ligne « Version PHP globale ». Pour changer, dans le cadre Configuration, le bouton « … » puis « Modifier la configuration ». Les plus à l'aise peuvent aussi modifier la ligne app.engine.version du fichier .ovhconfig à la racine du FTP. Le détail, bouton grisé et fichier .ovhconfig compris, est dans le guide OVHcloud.
Chez IONOS : espace client, rubrique Hébergement, menu PHP, « Ouvrir », cochez le domaine, « Modifier la version PHP », choisissez puis enregistrez. La bascule prend quelques minutes, et le réglage est par domaine. Le détail, et ce que vaut le « PHP Extended Support » d'IONOS, est dans le guide IONOS.
Chez Infomaniak : Manager, Hébergement Web, cliquez sur le nom du produit, « Plus d'informations », « Modifier », choisissez la version, « Enregistrer ». Le changement est immédiat, et revenir à une version vulnérable est ensuite bloqué. Infomaniak corrige aussi lui-même PHP 7.4, 8.0 et 8.1, ce que presque aucun hébergeur ne fait : le détail heure par heure est dans le guide Infomaniak.
Chez Hostinger : hPanel, Sites web, « Gérer », puis « Configuration PHP » sous « Avancé », choisissez la version, « Mise à jour ». La version vaut pour tous les sites du plan, et Hostinger annonce « aucune action requise », ce qui ne couvre pas un site resté en 8.1 : le guide Hostinger explique pourquoi.
Chez PlanetHoster : dans N0C, « Langages », « PHP », choisissez la version puis « Appliquer » ; sur un ancien compte cPanel ou sur HybridCloud, le chemin change, et les envois de fichiers peuvent renvoyer une erreur 403 ce soir à cause des mesures d'urgence de l'hébergeur : tout est dans le guide PlanetHoster.
Sur un VPS, un serveur dédié ou Plesk : dans Plesk, Sites web & domaines, rubrique PHP de chaque site. Sur un serveur, php -v donne la version en ligne de commande, mais c'est la page phpinfo() ou l'en-tête X-Powered-By qui dit laquelle sert vraiment le site. Ensuite apt ou dnf pour mettre à jour, puis redémarrage de PHP-FPM ou d'Apache.
Dans tous les cas, 8.2.35, 8.3.36, 8.4.27 et 8.5.12 sont les numéros à voir apparaître. L'outil de vérification lit le numéro quand le serveur l'affiche, et reconnaît l'hébergeur pour vous donner le bon chemin.
Êtes-vous concerné ? Site, boutique, logiciel, intranet
On parle beaucoup de « sites web », mais la faille ne regarde pas le nom qu'on donne à la chose. Elle regarde ce qui tourne sur le serveur.
Votre site vitrine sous WordPress, Joomla, Drupal, SPIP ou TYPO3 tourne sur PHP. Concerné.
Votre boutique en ligne sous PrestaShop, WooCommerce, Magento ou Thelia tourne sur PHP. Concernée, et c'est la cible la plus intéressante pour un attaquant : il y a des paiements et des adresses dedans.
Votre logiciel métier, votre intranet, votre extranet, votre espace client, s'ils ont été développés en PHP (Laravel, Symfony ou du code maison), sont concernés même s'ils sont protégés par un mot de passe. La faille joue avant la page de connexion. Un outil interne que seuls vos salariés utilisent, mais qui est joignable depuis internet, est exposé comme un site public.
Les outils installés sur un serveur, Dolibarr, GLPI, Nextcloud, Moodle, un forum phpBB, un wiki, un outil de tickets, sont dans le même cas.
Pas concernés : les éditeurs de sites comme Wix, Squarespace, Shopify, Webflow, Jimdo ou Google Sites. Ils n'exécutent pas PHP pour vous, et ils entretiennent leurs serveurs eux-mêmes. Une application développée en Node.js, en Python ou en .NET n'est pas touchée non plus par cette faille-là. Petit bémol : Node.js a publié ses propres correctifs de sécurité le même jour, le 21 octobre. Même réflexe, même jour.
Si vous ne savez pas sur quoi tourne votre site, l'outil de vérification le lit sur votre page d'accueil : il reconnaît la plateforme, la version de PHP quand elle est affichée, et souvent l'hébergeur. Sinon, la question à poser à votre prestataire tient en une ligne : « quelle version de PHP sert ce site, et a-t-elle été mise à jour depuis le 21 octobre ? »
Ce que votre hébergeur fait, et ce qu'il ne fait pas
En hébergement mutualisé, PHP appartient à l'hébergeur. Vous ne pouvez pas l'installer vous-même ; vous choisissez seulement une branche (8.1, 8.2, 8.3…) dans votre espace. L'hébergeur, lui, installe les versions corrigées sur ses serveurs pour les branches encore maintenues, de 8.2 à 8.5.
Le 21 octobre au soir, voici ce que j'ai pu relever. o2switch a désactivé la fonctionnalité en cause dès 8 h 07 du matin, mais à 16 h 40 ses serveurs tournaient encore avec les versions du 6 octobre, en attendant les paquets de CloudLinux prévus dans la soirée. OVHcloud annonce des règles de pare-feu sur ses clusters mutualisés et une campagne de maintenance. Infomaniak a ouvert une maintenance de 15 h jusqu'au lendemain 3 h, avec les correctifs déployés par ses équipes et aucune action demandée, sauf pour les sites restés sur une version de PHP plus maintenue. Pour IONOS, Hostinger, PlanetHoster, LWS ou Gandi, je n'ai trouvé aucune annonce publique à cette heure-là.
Ce qui vous revient, dans tous les cas : vérifier dans un jour ou deux que la version a réellement changé. Un correctif annoncé n'est pas un correctif installé. Et si votre site est en PHP 8.1 ou moins, l'hébergeur ne le touchera pas : c'est à vous de passer en 8.3 ou 8.4 depuis cPanel, Plesk ou l'espace client, après une sauvegarde et un test, parce qu'un vieux thème ou une vieille extension peut ne pas suivre.
Les trois questions à poser à votre prestataire
Beaucoup de sites et d'outils ont été faits il y a trois, cinq ou huit ans par une agence ou un freelance qu'on ne voit plus. C'est le moment de leur écrire, par e-mail, pour garder une trace.
Première question : quelle version de PHP sert le site ou l'application aujourd'hui ? La réponse doit être un numéro précis, 8.3.36 par exemple, pas « c'est à jour ».
Deuxième question : a-t-elle été mise à jour depuis le 21 octobre 2026, et par qui ?
Troisième question : les journaux du serveur ont-ils été regardés depuis le 20 octobre ? Des requêtes POST volumineuses de type multipart vers des pages qui n'en reçoivent jamais sont le signal à chercher.
Si personne ne répond dans la journée, ou si le prestataire n'existe plus, c'est exactement le genre de situation que je reprends : je récupère les accès, je mets à jour, je teste, et je vous écris ce qui a été fait.
Et si votre site tourne encore en PHP 7 ou 8.1 ?
C'est le cas le plus délicat, et le plus fréquent chez les TPE. Deux options.
Le paquet rétroporté : certains hébergeurs et certaines distributions Linux (Debian, Ubuntu) intègrent les correctifs dans leurs anciennes versions sans changer le numéro. Il faut leur demander, par écrit, si c'est fait. Un numéro ancien ne prouve donc pas la faille à lui seul, mais dans le doute, il faut une confirmation.
Le changement de branche : passer en PHP 8.3 ou 8.4. C'est la vraie solution, et c'est aussi ce qu'il faudra faire de toute façon, puisque PHP 8.2 s'arrête le 31 décembre 2026. Ça demande de vérifier que le CMS, le thème et les extensions acceptent la nouvelle version, de faire une sauvegarde hors du serveur, et de tester sur une copie avant de basculer. Une heure pour un site simple, une demi-journée pour une boutique avec beaucoup de modules.
Si aucune des deux n'est possible aujourd'hui, la recommandation du CERT-FR est claire : mettez l'application hors ligne, ou derrière un pare-feu applicatif, le temps de faire le nécessaire.
Impôts, CAF, Ameli, préfectures : quand reviennent-ils, et faut-il s'inquiéter ?
Si vous êtes arrivé ici parce que impots.gouv.fr ou caf.fr affiche « en maintenance », que votre compte Ameli ne s'ouvre pas ou que le site de votre préfecture ne répond pas : c'est cette faille, et c'est volontaire. Le ministère de l'Intérieur parle d'une « mise en maintenance préventive » et de « meilleurs délais » pour la remise en ligne ; la CAF parle de maintenance et garde ses délais habituels de déclaration. Le retour se fait service par service : Météo-France a rouvert le 22 octobre au matin, ameli.fr et urssaf.fr répondaient le 23 à 11 h 40, et à la même heure caf.fr, impots.gouv.fr et les sites des préfectures affichaient encore une page de maintenance. Vos données ne sont pas en cause, aucune intrusion n'a été annoncée, et vous n'avez rien à faire pour ces sites.
Une seule précaution : les e-mails et SMS qui prétendent venir des impôts, de votre hébergeur ou de « l'ANSSI » pour vous faire « vérifier vos identifiants » vont fleurir dans les jours qui viennent. Les arnaques suivent toujours ce genre d'actualité.
Mettre à jour WordPress ne suffit pas
C'est la confusion que j'entends le plus souvent. « J'ai fait les mises à jour, tout est vert. » Les mises à jour de WordPress, de PrestaShop ou des plugins ne touchent pas à PHP, qui tourne en dessous. Un plugin de sécurité peut bloquer certaines requêtes, pas toutes, et les attaquants ont déjà modifié leurs charges pour passer les règles de Cloudflare. La seule porte qui ferme vraiment, c'est la version corrigée de PHP sur le serveur.
Les premières tentatives d'attaque ont été vues par Amazon sur ses pièges dès le 17 octobre, quatre jours avant le correctif, puis en continu depuis la matinée du 21. Le 22, Wordfence voyait les attaques continuer sans aucune compromission connue par cette faille : rassurant, mais si votre site est resté exposé, il faut regarder.
Dans les journaux d'accès du serveur, cherchez depuis le 17 octobre des requêtes POST de type multipart inhabituelles. Dans les dossiers d'envoi de fichiers (uploads, cache, tmp), cherchez des fichiers .php récents que vous n'avez pas mis là. Dans l'administration, cherchez des comptes administrateurs inconnus et des tâches planifiées nouvelles. En cas de doute : sauvegarde immédiate, changement de tous les mots de passe d'administration, et si des données personnelles de clients sont concernées, notification à la CNIL sous 72 heures.
Ce que je peux faire pour vous
Je suis développeur freelance près de Rennes, et je travaille à distance partout en France. Pour cette faille, je fais une chose simple : je lis la version de PHP réellement servie par votre site, votre boutique ou votre outil, je mets PHP à jour ou je fais changer de branche, je vérifie que tout fonctionne encore, et je vous écris ce qui a été fait. Si votre prestataire ne répond plus, je récupère les accès et je reprends la suite.
Commencez par vérifier votre site gratuitement, ça prend dix secondes. Et si le résultat n'est pas celui que vous espériez, écrivez-moi : je réponds sous 24 heures.
Sources : avis de sécurité et versions corrigées sur php.net, alerte CERTFR-2026-ALE-014 du CERT-FR, préfectures et Météo-France hors ligne, France 3 le 21 octobre à 18 h 56, sites publics coupés aux Pays-Bas, en Finlande et au Royaume-Uni, The Record, règles de pare-feu de Cloudflare, relevé des hébergeurs par Clubic le 21 octobre à 18 h 25, page de statut d'Infomaniak, correctifs de sécurité Node.js du 21 octobre 2026, tentative d'exploitation du 17 octobre vue par Amazon, Ameli, CAF, impôts et URSSAF hors service, Clubic le 22 octobre à 10 h 53, attaques en cours sans compromission connue, Wordfence le 22 octobre.
