Ce que Next a mesuré, et ce que le chiffre ne dit pas
Selon Next, 2 novembre 2026, la rédaction est partie du fichier open data de l'AFNIC, qui recense les 4,6 millions de noms de domaine en .fr existant encore en septembre 2026. Elle a interrogé chaque domaine à raison d'environ dix par seconde, soit près de cinq jours de traitement, et relevé la version de PHP annoncée dans la réponse HTTP. Un serveur qui ne communique pas cette information n'est pas analysé. Le tri est sévère. Environ 1,2 million de domaines n'ont renvoyé aucun statut HTTP, près de 2,6 millions ont répondu sans indiquer de version de PHP, et environ 500 000 serveurs ont affiché une version. C'est sur ces 500 000 que repose l'analyse. Le chapeau de l'article évoque « au moins 250 000 domaines » avec une version vulnérable ; un intertitre parle de 387 000 sites à risque et de 127 000 sites à jour. L'article étant réservé aux abonnés après environ la moitié du texte, nous n'avons pas pu expliquer l'écart entre ces deux chiffres. Nous retenons donc le chiffre du chapeau, le plus prudent. Une lecture arithmétique, qui est la nôtre et non celle de Next : 250 000 sur environ 500 000 serveurs qui affichent une version, c'est la moitié, mais seulement 5 % de l'ensemble des domaines .fr. Surtout, le chiffre mesure une exposition apparente. Un système Debian ou Ubuntu peut appliquer le correctif sans changer le numéro de version affiché : selon IT-Connect, c'est la révision du paquet, après le tiret, qui prouve que la correction est faite, alors que la commandephp -v montre encore l'ancien numéro. Inversement, un serveur qui masque sa version peut être vulnérable sans apparaître dans le scan.
PHP2Shell en quatre faits vérifiés
- Deux failles, un même risque. CVE-2026-109618 et CVE-2026-109619 sont des défauts de gestion de la mémoire dans PHP, notés 9,2 sur 10 selon l'échelle CVSS v4 par l'équipe PHP (Next, 21 octobre 2026). Elles permettent d'exécuter du code à distance, sans authentification, selon IT-Connect et Recorded Future (Insikt Group).
- Les versions corrigées. PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L'équipe PHP a annoncé la publication le 20 octobre pour le 21 ; elle est intervenue un peu plus tôt que prévu après des fuites d'informations. Le journal des modifications officiel de PHP 8 date la version 8.5.12 du 22 octobre : un écart d'un jour que nous signalons, sans pouvoir l'expliquer.
- Les attaques ont démarré avant les correctifs. Selon Codeur.com, mis à jour le 26 octobre 2026, Amazon a repéré une première tentative le 17 octobre, le 21 octobre a marqué le début des attaques massives, un chercheur a constaté 35 prises de contrôle réussies sur ses serveurs pièges le 24 octobre, et la CISA américaine a inscrit PHP2Shell à sa liste des failles activement exploitées le 26 octobre. Wordfence dit avoir bloqué plus de 74 000 tentatives visant WordPress en deux jours.
- Aucune victime n'est officiellement confirmée. Toujours selon Codeur.com, mis à jour le 26 octobre 2026, deux annonces d'intrusion, attribuées à Sophos et à Palo Alto Networks, ont été retirées faute de preuves. Recorded Future (Insikt Group) précise de son côté que l'étendue des compromissions réussies n'est pas établie publiquement.
Pourquoi les PME des Hauts-de-France sont concernées
Nous n'avons trouvé aucune ventilation régionale du scan de Next : le .fr n'est pas découpé par département, et nous n'inventons donc aucun chiffre pour les Hauts-de-France. Ce que l'on peut dire sans extrapoler, c'est que la faille touche le moteur de la plupart des sites de petites structures : WordPress, Drupal et Joomla sont tous cités comme exploitables sans mot de passe par Wiz, selon Recorded Future. Les commerçants, artisans, cabinets, associations et collectivités de la région qui ont fait réaliser leur site par une agence ou l'ont confié à un hébergeur mutualisé sont donc dans le même cas que le reste du pays. Le point sensible est la chaîne de responsabilité. Sur un hébergement mutualisé, c'est l'hébergeur qui met à jour PHP ; sur un serveur privé virtuel ou dédié, c'est vous ou votre prestataire. Beaucoup de dirigeants ne savent pas dans quel cas ils sont. Cette incertitude est le vrai risque, et c'est la raison pour laquelle Codeur.com recommande de demander par écrit à l'hébergeur s'il a appliqué le correctif, et quand. La logique est la même que celle que nous avions décrite pour la faille wp2shell sur WordPress en juillet, ou pour l'incident des prestataires Atexo et Docaposte touchant la Région : la sécurité d'une organisation dépend de celle de ses fournisseurs.Cinq vérifications à faire cette semaine
- Identifier la version de PHP de chaque site. Espace client de l'hébergeur, ou Outils > Santé du site sous WordPress. Notez la version et la date du dernier changement.
- Demander une confirmation écrite à l'hébergeur ou à l'agence. Posez deux questions : le correctif PHP2Shell est-il appliqué, et à quelle date ? Sur un serveur privé, confiez la mise à jour à un prestataire compétent.
- Sortir des branches non maintenues. Une version 7.4, 8.0 ou 8.1 ne reçoit plus de correctif officiel régulier ; la branche 8.2 n'en recevra plus après le 31 décembre 2026, selon IT-Connect. Planifiez la migration et un test du site avant.
- Si le site est resté non corrigé plusieurs jours, chercher des traces d'intrusion. Fichiers inconnus dans les dossiers du site, administrateurs créés récemment, requêtes inhabituelles dans les journaux depuis le 20 octobre. En cas de doute, changez les mots de passe et les clés d'accès.
- Ne pas se reposer sur de simples réglages temporaires. Désactiver la progression d'envoi de session (
session.upload_progress.enabledà 0) ou filtrer les envois de fichiers réduit l'exposition, mais ne remplace pas la mise à jour. Les redémarrages des processus PHP sont nécessaires après toute modification.
Ce que nous ne savons pas
Nous ne savons pas combien de sites de la région sont concernés, ni combien ont déjà été compromis. Nous n'avons pas lu l'intégralité de l'article de Next, en partie réservé aux abonnés, et nous ne pouvons pas expliquer l'écart entre ses chiffres de 250 000 et de 387 000 sites. Nous n'avons pas pu vérifier de déclaration d'OVHcloud ni d'un autre hébergeur sur la correction de leurs offres mutualisées. Les vidéos intégrées n'ont pas été visionnées. Pages consultées le mardi 3 novembre 2026.FAQ : PHP2Shell et les sites des PME
Qu'est-ce que PHP2Shell ?
C'est le nom donné à deux failles critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4). Elles permettent d'exécuter du code à distance sur un serveur sans mot de passe, via de simples requêtes web. Les correctifs ont été publiés le 21 octobre 2026.
Comment savoir si mon site est concerné ?
Si votre site tourne sous WordPress, Drupal, Joomla ou une application sur mesure en PHP, il l'est potentiellement. Regardez la version de PHP dans l'espace client de votre hébergeur ou, sur WordPress, dans Outils > Santé du site. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Sur Debian ou Ubuntu, le numéro affiché peut rester ancien alors que le correctif est appliqué : vérifiez la révision du paquet.
Mettre à jour WordPress et ses extensions suffit-il ?
Non. La faille est dans PHP, le moteur qui exécute le site, pas dans WordPress. Selon Codeur.com, c'est PHP lui-même qui doit être mis à jour, par l'hébergeur sur un mutualisé ou par vous (ou votre prestataire) sur un serveur privé.
Mon hébergement utilise PHP 7.4 ou 8.0 : que faire ?
Ces branches ne reçoivent plus de correctifs officiels réguliers. L'équipe PHP a publié des correctifs minimaux pour 7.4, 8.0 et 8.1, mais ils sont à compiler soi-même (source : IT-Connect). La solution durable est de migrer vers une branche maintenue, en prévoyant un test de compatibilité du site avant le changement.
Les 250 000 sites repérés par Next sont-ils tous piratables ?
Non. Next a relevé la version de PHP annoncée par les serveurs, pas testé l'exploitation. Une version affichée peut être ancienne tout en étant corrigée par le système (paquets Debian ou Ubuntu), et un serveur peut masquer sa version. Le chiffre mesure une exposition apparente, pas des sites compromis.
Sources : Next, 2 novembre 2026 · Next, 21 octobre 2026 · Codeur.com, 22 octobre 2026 · Codeur.com, mis à jour le 26 octobre 2026 · Recorded Future (Insikt Group) · IT-Connect · journal des modifications officiel de PHP 8
