Faille PHP2Shell : les sites des Hauts-de-France à mettre à jour

Il est rare qu'une alerte informatique vide d'un coup les sites de l'administration. C'est pourtant ce qui s'est passé mercredi 21 octobre : les sites des préfectures ont été coupés par le ministère de l'Intérieur à la demande de l'ANSSI, rapporte la presse spécialisée, les portails gouvernementaux néerlandais et finlandais ont été débranchés, la Région flamande a déconnecté les siens. En cause, deux failles du moteur PHP, le langage qui fait tourner environ sept sites web sur dix dans le monde, et donc la très grande majorité des sites d'entreprise du Nord et du Pas-de-Calais, du restaurant lillois à l'artisan du Béthunois.

La réponse courte. Si votre site tourne sous WordPress, WooCommerce, PrestaShop, Joomla, Drupal ou sur un développement PHP sur mesure, il est concerné, même si vous avez installé toutes les mises à jour de votre CMS et de vos extensions. La faille est dans le moteur PHP lui-même, sous l'application. Seule une version corrigée de PHP (8.5.12, 8.4.27, 8.3.36 ou 8.2.35) règle le problème. La chose à faire aujourd'hui : vérifier la version de PHP active sur votre hébergement, et la changer si elle n'est pas dans cette liste. La marche à suivre est plus bas, ainsi que ce que je propose aux entreprises de la région.

Ce qui s'est passé le 21 octobre

Les deux vulnérabilités portent les références CVE-2026-109618 et CVE-2026-109619. La presse les a réunies sous un seul nom, « PHP2Shell ». Elles sont notées 9,2 sur 10 sur l'échelle CVSS v4.0 et permettent à un attaquant d'exécuter du code à distance sur le serveur : sans compte, sans mot de passe, et sans qu'un utilisateur ait à cliquer sur quoi que ce soit.

L'équipe PHP avait prévenu la veille qu'une publication de sécurité critique aurait lieu le mercredi à 14 h UTC. Entre-temps, les références des failles avaient fuité sur le forum Hacker News dès le 20 octobre, et une société de sécurité avait diffusé par erreur une vidéo de son attaque. Les correctifs sont sortis en début d'après-midi, un peu en avance sur l'horaire, pour les quatre branches encore maintenues : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le CERT-FR, le centre d'alerte de l'ANSSI, a publié son alerte CERTFR-2026-ALE-014 le jour même. Le CERT-EU a recommandé de couper les sites qui ne pouvaient pas être corrigés sans délai.

Les failles ont été trouvées par des modèles d'intelligence artificielle. Les chercheurs de Calif, partenaires d'OpenAI, ont signalé la première à l'équipe PHP le 11 août ; Wiz, filiale de Google, a signalé la seconde le 24 août. Le code fautif, lui, remonte à PHP 5.4, publié en 2012 : il était là depuis quatorze ans, dans la configuration par défaut. Dans le récit qu'elle a publié depuis, relayé sur les réseaux sociaux, la PHP Foundation reconnaît que les premiers signes remontaient à un audit de 2024 financé par l'État allemand, que le correctif est resté bloqué des mois, et parle d'un « échec structurel ». Elle rappelle aussi que la sécurité d'un langage qui fait tourner commerces, services publics et intranets repose sur « un petit groupe » de développeurs.

Pourquoi un site « à jour » reste vulnérable

C'est le point qui déroute le plus. Un site web en PHP, c'est un empilement : en bas, le serveur et son système ; au milieu, le moteur PHP ; en haut, l'application (WordPress, PrestaShop, un site sur mesure). Les mises à jour qu'on fait d'habitude, celles du CMS, du thème et des extensions, touchent l'étage du haut. PHP2Shell est à l'étage du milieu. Les chercheurs l'ont montré en compromettant des installations WordPress, Drupal, Joomla et Magento parfaitement à jour.

Le mécanisme tient en une image. PHP traite les visiteurs à la chaîne, dans la même mémoire, qu'il doit nettoyer entre deux requêtes. Quand une requête plante en cours de route (mémoire épuisée, erreur fatale), le moteur abandonne tout sans finir son ménage. La requête suivante réutilise alors une zone de mémoire déjà libérée, que l'attaquant a pu remplir à sa guise. La première faille exploite les pénuries de mémoire ; la seconde, des « notes » internes qui ne sont jamais effacées, et qui permettent en prime d'aspirer des fragments de mémoire : mots de passe, jetons de session ou clés d'API d'autres visiteurs.

Concrètement, un simple formulaire d'envoi de fichier, comme on en trouve sur une page de contact ou de candidature, suffit à provoquer le plantage, puis à exécuter du code avec tous les droits du serveur web : lecture des fichiers de configuration, vol des identifiants de la base de données, dépôt d'une porte dérobée, rebond vers le réseau interne de l'entreprise. Autre conséquence contre-intuitive : le mode maintenance de votre CMS ne protège de rien, puisque PHP analyse la requête avant que l'application n'ait son mot à dire.

Panique ou excès de zèle ? Ce que disent les experts

Tout le monde n'est pas d'accord sur la gravité pratique. Un billet largement partagé sur Hacker News, au titre sans détour (« There isn't an easy exploit for this PHP vulnerability »), rappelle que les milliers de preuves de concept apparues sur GitHub en quelques heures ne fonctionnent pas contre une installation PHP standard : la plupart exigent que le serveur souffre déjà d'une autre faille, et beaucoup ont été écrites par des assistants d'IA qui, faute d'y arriver, ont modifié le serveur de test pour le rendre vulnérable. Pour son auteur, on est loin de Log4Shell ou de Heartbleed, où des botnets ravageaient le web dès le jour de la publication. D'autres praticiens parlent d'un « travail d'horloger pour chaque cible », sous peine de ne faire que planter le serveur.

Les faits connus plaident pourtant pour la prudence. Cloudflare dit avoir observé des tentatives d'attaque dès 9 h 43, heure de Paris, six heures avant la sortie des correctifs. Un outil d'exploitation circule publiquement. Et la rapidité joue dans les deux sens, comme le résume Samuel Hassine, cofondateur de l'éditeur français Filigran : « L'IA a trouvé des failles restées inaperçues pendant plus de dix ans, et les mêmes outils permettent aux attaquants de développer des exploits fonctionnels en quelques heures. » Son collègue Mathieu Rigotto, responsable de la sécurité de la même entreprise, s'agace surtout de la chronologie : publier un exploit fonctionnel avant le correctif « a donné une longueur d'avance aux attaquants, alors que les défenseurs n'avaient rien à déployer ».

Pour une PME, le calcul est simple : la mise à jour se compte en heures, une compromission se compte en semaines. « Mettre un site hors ligne pendant une journée est une décision bien moins coûteuse que d'expliquer une compromission pendant un an », résume encore Samuel Hassine.

Votre site est-il concerné ? Trois questions

1. Votre site tourne-t-il en PHP ?

Si vous avez un site WordPress (avec ou sans WooCommerce), PrestaShop, Joomla, Drupal, Magento, ou un site développé sur mesure par une agence ou un indépendant de la région, la réponse est presque toujours oui. Les frameworks modernes comme Laravel ou Symfony tournent eux aussi sur PHP et ont dû être mis à jour comme les autres. Si votre site est hébergé sur une plateforme fermée comme Wix, Squarespace ou Shopify, c'est la plateforme qui gère son infrastructure : vous n'avez rien à faire.

2. Quelle version de PHP est active ?

C'est la question clé, et la réponse ne se trouve pas dans WordPress mais chez votre hébergeur. Chez o2switch, Ionos, Hostinger ou tout hébergeur sous cPanel, un outil « Sélectionner la version PHP » (ou « MultiPHP ») l'affiche dans l'espace client. Chez OVHcloud, c'est l'onglet de configuration de l'hébergement web. Les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; un numéro inférieur dans la même branche est, par défaut, vulnérable. Une nuance pour les hébergements mutualisés : certains hébergeurs recompilent PHP avec le correctif sans changer le numéro de version, comme le font les distributions Linux. Dans ce cas, seule une confirmation écrite et datée de l'hébergeur vaut preuve : demandez-la. Sous WordPress, le menu Outils puis Santé du site, onglet Informations, section Serveur, donne aussi le numéro exact.

Si votre site est encore en PHP 7.4, 8.0 ou 8.1, la situation est plus sérieuse : ces branches ne sont plus maintenues et ne recevront aucun correctif officiel. L'équipe PHP a publié des rustines minimales pour ceux qui compilent eux-mêmes, mais sur un hébergement classique, la seule issue est de passer à une branche maintenue, de préférence 8.3 ou 8.4 (la 8.2 cesse ses correctifs de sécurité le 31 décembre 2026). Ce passage peut casser un vieux thème ou une extension abandonnée, d'où l'intérêt de le faire avec quelqu'un qui saura revenir en arrière.

3. Qui s'en occupe ?

C'est souvent là que ça coince. Le site a été livré il y a quatre ans par une agence qui n'existe plus, par un neveu, par un indépendant qui a changé de métier. Personne n'a d'identifiants d'hébergement sous la main. Les administrations ont coupé leurs sites parce qu'elles ne savaient pas où PHP tournait chez elles ; une TPE a l'avantage de n'avoir qu'un site, encore faut-il savoir qui en tient les clés.

Votre situation	Ce qu'il faut faire	Quand
Hébergement mutualisé (o2switch, OVHcloud, Ionos, Hostinger...)	Vérifier la version PHP dans l'espace client, basculer sur une version corrigée (ou obtenir la confirmation écrite de l'hébergeur), tester le site	Aujourd'hui
Serveur dédié ou VPS, géré par vous ou votre prestataire	Mettre à jour les paquets PHP du système, redémarrer PHP-FPM ou Apache, vérifier la version en ligne de commande	Aujourd'hui
Site en PHP 7.4, 8.0 ou 8.1	Sauvegarde, puis passage à une branche maintenue (8.3 ou 8.4) avec test du thème et des extensions	Cette semaine, palliatifs en attendant
Site derrière Cloudflare	Les règles du pare-feu applicatif protègent depuis mercredi 5 h, offre gratuite comprise, mais la mise à jour reste nécessaire	Aujourd'hui
Plateforme hébergée (Wix, Shopify, Squarespace)	Rien

Ce que font les hébergeurs, et ce qu'ils ne font pas

Les grands acteurs du cloud étaient dans la confidence depuis plusieurs semaines. Cloudflare a activé des règles de protection pour tous ses clients, offre gratuite comprise, à 3 h 02 UTC mercredi, onze heures avant les correctifs. Google Cloud a mis à jour d'office ses services entièrement gérés (App Engine standard, Cloud Run), mais laisse ses clients reconstruire leurs conteneurs et abandonner PHP 8.1 et antérieurs. AWS et Microsoft étaient plus discrets mercredi soir. La règle du jeu est celle de la responsabilité partagée : ce qui est entièrement géré se corrige tout seul, le reste est l'affaire du client.

Pour les hébergeurs mutualisés, qui font tourner l'immense majorité des sites de TPE et de PME de la région, le schéma est le même en plus petit. L'hébergeur fournit les versions corrigées de PHP et s'appuie en attendant sur des boucliers provisoires comme Imunify360 de CloudLinux. Mais c'est le client, ou son webmaster, qui choisit la version active pour son site. Un hébergement laissé en PHP 7.4 par confort depuis 2021 ne passera pas tout seul en 8.3 : il faut le décider, le faire et vérifier que le site fonctionne encore. La fiche pédagogique d'OVHcloud consacrée à PHP, qui rappelle que « les mises à jour régulières renforcent la sécurité du langage », ne vous dira pas quelle version tourne chez vous : seul votre espace client le sait.

Mise à jour PHP en urgence : ce que je propose aux entreprises du Nord et du Pas-de-Calais

Je suis webmaster indépendant, installé près de Béthune, et j'interviens à distance sur les hébergements de mes clients, de Lille à Arras, de Lens à Dunkerque ou Saint-Omer. La question que se posent les entreprises cette semaine est partout la même : « est-ce que mon site est concerné, et qui peut le mettre à jour vite ? » Voici comment je procède.

1. Vérification de la version et de l'exposition. Vous m'envoyez l'adresse de votre site et le nom de votre hébergeur. Je vous dis si le site est concerné, quelle version tourne et ce qu'il y a à faire. Ce premier diagnostic est gratuit.
2. Passage à une version corrigée. Sauvegarde, bascule de la version PHP dans votre hébergement, test des pages, du formulaire de contact, du panier et de l'administration, retour arrière prévu si une extension ne suit pas. Sur un hébergement mutualisé, c'est le plus souvent l'affaire d'une à deux heures.
3. Palliatifs si la mise à jour est impossible aujourd'hui (site en 7.4 ou 8.1 avec un thème fragile, prestataire injoignable) : désactivation de la progression d'envoi des sessions, blocage ou surveillance des requêtes multipart au niveau du serveur ou d'un pare-feu applicatif, mise derrière Cloudflare. Ces mesures réduisent l'exposition, elles ne remplacent pas le correctif, et je vous dis clairement ce qu'elles couvrent et ce qu'elles ne couvrent pas.
4. Recherche de compromission. Si le site est resté exposé plusieurs jours, on suppose qu'un attaquant a pu passer : recherche de web shells et de fichiers inattendus, contrôle des utilisateurs administrateurs, des tâches planifiées et des connexions sortantes, changement des identifiants de base de données et des clés d'API. C'est le volet que couvre aussi mon accompagnement à la sécurisation des bases de données.

Ces interventions sont facturées au temps passé, selon ma grille de dépannage et de mise à jour de site : 80 € de l'heure pour une correction sur un hébergement mutualisé, 120 € de l'heure pour la gestion d'un serveur que vous administrez. Devis gratuit, et vous savez avant de commencer ce que ça coûtera. Si votre site a été laissé en plan par une agence ou un prestataire qui ne répond plus, la reprise de votre site commence par récupérer les accès à l'hébergement, et c'est précisément ce dont vous avez besoin aujourd'hui.

Pour une demande urgente, le plus rapide est le téléphone : 07 45 01 54 82. Sinon, le formulaire de contact, avec l'adresse de votre site et le nom de votre hébergeur, et je vous réponds avec un premier diagnostic.

Les palliatifs recommandés par l'équipe PHP et l'ANSSI

Pour les administrateurs de serveur qui lisent ces lignes, voici ce que recommandent l'équipe PHP et le CERT-FR tant que le correctif n'est pas appliqué. Aucune de ces mesures ne rend une installation sûre ; elles ferment des chemins d'attaque précis.

• Contre la faille liée à la mémoire (CVE-2026-109618) : memory_limit=-1, posé de façon que l'application ne puisse pas le changer (php_admin_value dans le pool FPM ou la configuration Apache), et un post_max_size bas (8M sans envoi de fichiers, 32M sinon), upload_max_filesize restant en dessous. Les limites de taille, de nombre de champs et de parties multipart gagnent à être appliquées aussi au niveau du serveur web ou du proxy.
• Contre la faille liée à l'état résiduel (CVE-2026-109619) : session.upload_progress.enabled=0, puis redémarrage de tous les processus. Dans php.ini ou la configuration du pool, pas via ini_set() ni un fichier .user.ini, qui arrivent trop tard. Sur PHP 8.5, fatal_error_backtraces=0 en plus.
• Au niveau du pare-feu applicatif ou du serveur web : bloquer, ou au minimum surveiller, les requêtes dont l'en-tête Content-Type est multipart. C'est la mesure que l'ANSSI met en avant, en précisant que la désactivation de upload_progress ne couvre à elle seule qu'une des deux failles.
• Masquer les erreurs avec error_reporting, display_errors ou @ ne sert à rien. Corriger les erreurs fatales et les dépassements de temps qu'un visiteur peut déclencher, si.
• En dernier recours : couper le site, le temps de corriger. C'est ce qu'ont fait les préfectures.

Sur un hébergement mutualisé, vous n'avez la main sur presque rien de tout cela : c'est pourquoi la seule vraie réponse y est le changement de version PHP.

Ce que cette alerte change pour la suite

Trois enseignements dépassent le correctif de la semaine.

Savoir où PHP tourne chez vous. Un site, mais aussi un intranet, un extranet fournisseurs, un outil de réservation, une vieille application de gestion des congés. « Le plus difficile n'est pas d'installer le correctif, mais de savoir où PHP s'exécute », résume Samuel Hassine. Une PME gagne à tenir une liste de ses sites et applications, avec l'hébergeur, la version et le nom de la personne qui a les accès.

L'IA a changé le rythme. Des modèles ont trouvé en quelques mois ce que quatorze ans de relecture humaine avaient manqué, et les mêmes outils raccourcissent le délai entre divulgation et exploitation. Il y aura d'autres mercredis comme celui-là. La question n'est plus de lire les bulletins de sécurité plus vite, mais de savoir avant l'alerte où l'on est exposé.

Décider qui est responsable des mises à jour. Pas de la rédaction d'un article de blog : de la mise à jour du moteur. Si la réponse est « personne » ou « je ne sais pas », c'est la première chose à régler, avant la prochaine alerte. PHP 8.2 cesse ses correctifs de sécurité le 31 décembre 2026 : les sites qui s'y trouvent ont dix semaines pour prévoir le passage en 8.3 ou 8.4.

Questions fréquentes

Mon site WordPress est à jour, suis-je protégé ?

Non. La faille est dans PHP, sous WordPress. Les mises à jour du CMS, du thème et des extensions n'y changent rien. C'est la version de PHP active sur l'hébergement qu'il faut vérifier et changer.

Comment savoir quelle version de PHP utilise mon site ?

Dans l'espace client de votre hébergeur (outil de sélection de la version PHP), ou sous WordPress dans Outils, Santé du site, onglet Informations, section Serveur. Vous cherchez 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un numéro supérieur dans la même branche.

Mon hébergeur a-t-il fait la mise à jour pour moi ?

Sur un hébergement mutualisé, l'hébergeur met les versions corrigées à disposition, mais c'est le client qui choisit la version active de son site. Sur un serveur dédié ou un VPS, personne ne le fera à votre place. Si votre hébergeur annonce avoir corrigé sans que le numéro de version ait changé, demandez-lui une confirmation écrite.

Je suis en PHP 7.4 ou 8.1, que faire ?

Ces versions ne reçoivent plus de correctifs officiels. Il faut passer à une branche maintenue, 8.3 ou 8.4 de préférence, après une sauvegarde et un test des extensions. En attendant, appliquer les palliatifs ou placer le site derrière un pare-feu applicatif.

Combien coûte une mise à jour PHP par un webmaster dans le Nord ou le Pas-de-Calais ?

Je facture au temps passé : 80 € de l'heure sur un hébergement mutualisé, 120 € de l'heure pour un serveur administré. Le diagnostic de départ est gratuit, et le devis aussi.

Comment savoir si mon site a déjà été attaqué ?

Fichiers récents que vous n'avez pas créés, utilisateurs administrateurs inconnus, redirections ou publicités que vous n'avez pas posées, alerte de votre hébergeur, site ralenti sans raison. En cas de doute, changez les mots de passe d'administration et de base de données, et faites examiner les fichiers du site.

Un site Wix, Shopify ou Squarespace est-il concerné ?

Non. Ces plateformes gèrent elles-mêmes leur infrastructure et ne reposent pas sur un PHP que vous administrez.

Pour aller plus loin

• Le bulletin de sécurité de l'équipe PHP (en anglais), avec les versions corrigées et les palliatifs détaillés.
• L'alerte CERTFR-2026-ALE-014 du CERT-FR, le centre d'alerte de l'ANSSI.
• Les avis techniques GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, sur le dépôt GitHub du projet PHP.