Mercredi 21 octobre 2026, les sites des préfectures sont devenus inaccessibles, ceux de la Drôme et de l'Ardèche dès 14 h (Actu17). impots.gouv.fr affichait « actuellement en maintenance », Météo-France a fermé l'ensemble de ses sites « par mesure de précaution » (L'Express), et la CNIL a coupé une partie des siens (The Record). Le ministère de l'Intérieur a pris la décision « à la demande de l'Agence nationale de la sécurité des systèmes d'information », et précise : « Il ne s'agit pas d'une cyberattaque contre les préfectures, mais d'une mesure de précaution. »
La cause : une faille dans PHP, le langage qui fait tourner une grande partie du web. À 16 h (heure de Paris), l'équipe de PHP a publié en urgence le correctif de deux failles critiques, surnommées PHP2Shell. Notées 9,2 sur 10, elles permettent à un attaquant d'exécuter son propre code sur un serveur, à distance, sans compte ni mot de passe. PHP fait tourner WordPress : si votre site est sous WordPress, il est concerné.
Dans cet article, on vous explique ce qui s'est passé, pourquoi mettre à jour WordPress ne suffit pas, qui doit corriger quoi selon votre hébergement, et ce qu'il faut faire dès aujourd'hui. On termine par notre avis d'agence Webflow sur la question que beaucoup d'équipes marketing se posent cette semaine : faut-il quitter WordPress ?
Article publié le 22 octobre 2026. La situation évolue vite : on le met à jour au fil des annonces officielles.
Que s'est-il passé avec la faille PHP du 21 octobre 2026 ?
Les deux vulnérabilités sont dans le moteur de PHP lui-même : tout site qui s'appuie sur PHP est concerné, quel que soit son CMS. Selon l'avis officiel de PHP :
- CVE-2026-109618 (OOM corruption) : quand un serveur manque de mémoire au mauvais moment, PHP peut laisser des données à moitié initialisées, puis les traiter comme valides.
- CVE-2026-109619 (stale global state) : des données d'une requête peuvent survivre une fois leur mémoire libérée, et être réutilisées par la requête suivante.
Les deux sont notées 9,2 en CVSS v4.0. Elles touchent « toutes les installations PHP qui servent des requêtes web » : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et les versions antérieures n'ont pas de version officielle corrigée : l'équipe a seulement publié des correctifs de code source pour 7.4, 8.0 et 8.1, à appliquer soi-même.
| Date (heure de Paris) | Ce qui s'est passé |
|---|---|
| 11 août 2026 | Le laboratoire Calif signale la première faille à PHP, puis OpenAI et Wiz Research font de même (PHP Foundation) |
| 17 octobre | Amazon repère une première tentative d'exploitation sur ses serveurs pièges, quatre jours avant l'annonce (AWS) |
| 20 octobre, vers 17 h | Les identifiants des failles fuitent en ligne, avec une note erronée de 10/10. PHP avance la publication d'un jour |
| 21 octobre, 9 h 43 | Cloudflare signale les premières attaques (Sansec) |
| 21 octobre, 16 h | PHP publie les versions corrigées |
| 21 octobre | Le CERT-FR publie son alerte CERTFR-2026-ALE-014, mise à jour dans la journée avec les correctifs |
La France n'a pas été seule à couper. Aux Pays-Bas, le centre national de cybersécurité a fermé son propre site, suivi du portail Overheid.nl et du port de Rotterdam (Reuters). En Allemagne, l'hôpital de la Charité a mis tout son site hors ligne et le portail de signalement de la police de Berlin était indisponible (heise). La fondation Wikimedia, qui gère Wikipédia, a elle aussi coupé « un certain nombre de systèmes par précaution » (Newsweek).
Sur l'exploitation réelle, les sources ne disent pas la même chose. L'équipe de PHP n'avait identifié aucun exploit fonctionnel au moment de la publication. Amazon écrit au contraire que PHP2Shell est désormais « largement exploité ». Les sources que nous avons lues ne documentent pas encore d'intrusion réussie sur un site précis. Dans le doute, il faut faire comme si l'attaque était en cours.
Pourquoi WordPress est concerné, et pourquoi le mettre à jour ne suffit pas
WordPress est écrit en PHP. Chaque page d'un site WordPress est fabriquée par PHP sur le serveur, à chaque visite (ou presque, si un cache sert la page). D'après W3Techs au 22 octobre 2026, PHP est utilisé par 69,3 % des sites dont le langage serveur est connu, et WordPress fait tourner 39,6 % de tous les sites web.
La faille est dans PHP, en amont de WordPress. Le laboratoire Calif dit avoir obtenu une exécution de code sans authentification sur WordPress 7.1.2, mais aussi sur Drupal, Joomla, Magento ou Laravel. Wiz Research ajoute, cité par Patchstack, qu'une simple page « Hello World » sur une version vulnérable peut être exploitée.
Conséquence directe, que WordPress écrit lui-même : « Aucune mise à jour de WordPress n'est requise ni prévue pour remédier à ces problèmes. » Mettre à jour WordPress, votre thème et vos extensions est une bonne habitude, mais cette semaine ça ne change rien. Activer le mode maintenance de WordPress non plus : PHP lit la requête avant que WordPress ne vérifie s'il est en maintenance, rappelle Sansec.
Qui doit corriger quoi ?
Tout dépend de qui gère votre serveur. C'est la question à poser en premier, et beaucoup d'équipes marketing n'ont pas la réponse.
| Votre hébergement | Qui installe le correctif PHP | Ce que vous faites |
|---|---|---|
| Hébergement mutualisé (OVHcloud, o2switch, Hostinger…) | L'hébergeur | Vérifier la version de PHP de votre site et la changer si elle est trop ancienne, depuis le panneau de l'hébergeur |
| Hébergement WordPress infogéré | L'hébergeur ou le prestataire de maintenance | Lui demander par écrit la version installée et la date du correctif |
| Serveur géré par votre équipe ou une agence (VPS, cloud) | Vous ou votre prestataire | Mettre à jour PHP, redémarrer tous les processus PHP, vérifier les journaux depuis le 17 octobre |
| Site Webflow | Webflow (aucun PHP côté client) | Rien, d'après le Trust Center de Webflow |
Autre difficulté : même chez un bon hébergeur, le correctif n'était pas disponible partout le 21 octobre. Les distributions Linux ont reçu les correctifs à l'avance, mais le dépôt communautaire Remi, très utilisé sur les serveurs Red Hat et dérivés, ne devait pas l'avoir le jour même (Rapid7). Votre site a pu rester exposé plusieurs heures, sans que personne dans votre équipe ne puisse rien y faire.
Plus d'un site WordPress sur trois n'a aucune version de PHP corrigée à installer
WordPress.org publie la répartition des versions de PHP des sites qui se connectent à ses serveurs (pour vérifier les mises à jour, par exemple). On a relevé ces statistiques publiques le 22 octobre 2026 :
| Version de PHP | Part des sites WordPress | Situation après PHP2Shell |
|---|---|---|
| 8.3 et plus récentes | 40,4 % | Version corrigée disponible, à condition que l'hébergeur l'installe |
| 8.2 | 23,7 % | Version corrigée (8.2.35), mais fin de vie le 31 décembre 2026 |
| 7.4, 8.0 et 8.1 | 30,2 % | Pas de version officielle, seulement un correctif de code source à compiler soi-même |
| Avant 7.4 | 5,7 % | Aucun correctif publié par PHP |
Au total, 35,8 % des sites WordPress tournent sur PHP 8.1 ou plus ancien. Pour eux, il n'y a pas de mise à jour à cliquer : il faut changer de version de PHP, ce qui casse parfois un thème ou une extension trop ancienne. Et dans dix semaines, les 23,7 % encore en PHP 8.2 sortiront à leur tour du support.
Ce relevé a deux limites. Il ne compte que les sites qui contactent WordPress.org, et ignore ceux qui ont coupé cette connexion. Et un site en PHP 8.3 reste exposé tant que son hébergeur n'a pas installé la version 8.3.36.
Ce qu'il faut faire aujourd'hui si votre site tourne sous WordPress
- Trouvez votre version de PHP. Dans l'administration WordPress : Outils → Santé du site → Infos → Serveur. Ou dans le panneau de votre hébergeur.
- Écrivez à votre hébergeur ou à votre prestataire : quelle version exacte est installée, depuis quand, et le correctif du 21 octobre est-il appliqué ? Gardez la réponse.
- Si vous êtes en PHP 8.1 ou plus ancien, planifiez le passage en 8.3 ou 8.4 cette semaine, en testant d'abord sur une copie du site. WordPress recommande PHP 8.3 ou plus.
- Si vous gérez le serveur vous-même et ne pouvez pas mettre à jour tout de suite, les réglages temporaires sont listés dans l'avis de PHP et dans l'alerte du CERT-FR. Ils réduisent le risque sans le supprimer. Le CERT-FR recommande d'isoler les serveurs concernés jusqu'à la mise à jour.
- N'installez pas d'extension « correctif PHP2Shell » ni de bout de code trouvé sur un forum. Patchstack met en garde contre ces faux correctifs, et du code d'exploit non vérifié peut contenir un logiciel malveillant.
- Si vous voyez des signes suspects (comptes administrateurs inconnus, fichiers modifiés, trafic anormal depuis le 17 octobre), considérez le serveur comme compromis et changez les mots de passe et clés d'API qu'il contient.
Une fois votre version trouvée (étape 1), cliquez-la pour voir ce qu'elle implique :
Votre version de PHP, votre situation
Choisissez la version affichée dans Outils → Santé du site → Infos → Serveur.
Si un prestataire assure la maintenance de votre site, ces vérifications font partie de son travail : demandez-lui un compte rendu écrit.
Et si vous coupez le site le temps de corriger, comme l'ont fait les préfectures, pensez à Google. John Mueller, de l'équipe Search de Google, conseille de renvoyer un code HTTP 503 plutôt que de laisser les pages expirer ou répondre en 404 ou 500 (Search Engine Roundtable). Le 503 indique une indisponibilité temporaire, et vos pages gardent leur place dans l'index.
Une alerte ponctuelle ou un problème récurrent ?
En juillet déjà, WordPress corrigeait wp2shell, deux failles de son propre cœur qui permettaient de prendre le contrôle d'un site sans être connecté (versions 7.0.2 et 6.9.5, publiées le 17 juillet 2026). Cybermalveillance.gouv.fr avait alors publié une alerte et appelé à mettre à jour « au plus vite ».
Le reste du temps, le risque vient surtout des extensions. Dans son rapport State of WordPress Security in 2026, Patchstack recense 11 334 nouvelles vulnérabilités dans l'écosystème WordPress en 2025 :
- 91 % concernent des plugins, 9 % des thèmes ;
- 46 % n'avaient pas de correctif de l'éditeur au moment de leur divulgation ;
- pour les failles les plus attaquées, il s'écoule en médiane 5 heures entre la divulgation et l'exploitation de masse.
Mis bout à bout, ça fait quatre étages à surveiller : le serveur, la version de PHP, le cœur de WordPress, et chaque extension installée. Cette semaine, l'étage PHP n'était même pas entre les mains du propriétaire du site. Prenez un site marketing avec une vingtaine d'extensions, maintenu par un prestataire parti depuis longtemps : il cumule tous ces risques, et ce travail de surveillance ne figure dans aucun budget marketing.
Pourquoi un site Webflow n'a rien eu à faire cette semaine
Webflow a publié sa position sur son Trust Center : « Webflow's core services are not built on PHP and are not affected » (les services principaux de Webflow ne reposent pas sur PHP et ne sont pas affectés). L'éditeur précise qu'il vérifie des systèmes internes, hors production, qui utilisent PHP, et conclut : « No action is required from customers. »
Sur Webflow, vous ne gérez ni serveur, ni version de PHP, ni extension. L'hébergement, les certificats SSL et les mises à jour de sécurité sont pris en charge par la plateforme ; Webflow parle sur sa page sécurité d'« automated patches and updates with no customer maintenance » : des correctifs automatiques, sans maintenance côté client. La plateforme est certifiée SOC 2 et ISO 27001. On détaille tout ça dans notre guide de la sécurité Webflow.
Webflow n'est pas invulnérable pour autant, et on préfère le dire. Il reste des risques de votre côté :
- Les accès : un compte sans double authentification, ou des sièges jamais retirés aux anciens prestataires.
- Le code personnalisé et les scripts tiers (chat, tracking, formulaires externes), qui s'exécutent sur votre site et dont la sécurité dépend de leur éditeur.
- La dépendance à un seul éditeur, à qui vous confiez l'hébergement, la sécurité et la feuille de route du produit.
La différence, c'est le nombre de choses que votre équipe doit surveiller. Sur un site Webflow, il en reste peu, et aucune ne dépend d'un hébergeur qui attend un paquet Linux.
Notre avis : faut-il quitter WordPress après PHP2Shell ?
D'abord, ne migrez pas dans la panique. Un projet de migration prend des semaines ; la faille, elle, se corrige cette semaine chez votre hébergeur. Patchez, puis décidez à froid.
Ensuite, chez Digidop, la première question qu'on pose est simple : qui, chez vous, s'occupe de la sécurité du site, et combien ça coûte ? Un WordPress bien tenu, chez un hébergeur sérieux, avec peu d'extensions et un prestataire qui répond le jour même, est un choix défendable.
On recommande de passer à Webflow quand :
- votre site est un site marketing (pages services, blog, cas clients, formulaires) piloté par une équipe marketing ;
- personne en interne ne sait dire quelle version de PHP tourne, ni qui l'installe ;
- le site cumule des extensions dont la moitié ne sont plus mises à jour ;
- chaque modification passe par un développeur, et chaque mise à jour fait peur.
On recommande de rester sur WordPress, et de renforcer sa maintenance, quand :
- le site est une boutique WooCommerce avec des intégrations métier lourdes ;
- il porte une vraie logique applicative (espace client, calculs, base de données métier) ;
- vous avez déjà une équipe technique qui maîtrise l'hébergement et répond aux alertes dans l'heure.
La première situation correspond aux sites marketing B2B que Digidop construit pour la finance, la tech & SaaS et l'industrie. On en parle plus en détail dans nos articles sur les problèmes WordPress que l'on rencontre le plus et sur les raisons de migrer vers Webflow.
Migrer vers Webflow sans perdre son référencement ni sa visibilité IA
Le principal risque d'une migration, c'est de perdre du trafic. Une URL oubliée, une redirection manquante, et des pages qui se classaient disparaissent de Google et des réponses de ChatGPT ou de Perplexity.
Notre processus de migration vers Webflow suit cinq étapes :
- l'audit de l'existant : pages, contenus, trafic, extensions et ce qu'elles font vraiment ;
- l'architecture du CMS et le développement Webflow ;
- la migration des contenus et le plan de redirections 301, URL par URL ;
- l'intégration de vos outils marketing et métier (CRM, formulaires, analytics) ;
- la recette, la mise en ligne, puis un suivi de 90 jours.
Pour les contenus de blog, on a détaillé la méthode dans migrer le contenu d'un blog WordPress vers Webflow.
Pour suivre les positions et les citations dans les moteurs IA avant, pendant et après la bascule, on travaille avec Vydera, une agence SEO & GEO AI-native. Elle peut piloter le référencement pendant la migration et mesurer votre visibilité dans ChatGPT, Gemini ou Perplexity, pour vérifier que rien ne se perd au passage.
Côté budget, une migration vers Webflow est en pratique une reconstruction du site. Nos fourchettes publiées vont de 10 000 à 30 000 € pour un site web marketing, et de 30 000 à 50 000 € pour un site multilingue avec intégrations métiers et plusieurs marchés (détail sur notre offre site marketing).
{{custom-blog-cta}}
Questions fréquentes
Mon site WordPress est-il touché par la faille PHP2Shell ?
Oui, s'il tourne sur une version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, quelle que soit votre version de WordPress. Le CERT-FR liste toutes les versions 5.x à 8.1.x comme vulnérables. Seul votre hébergeur, ou la personne qui gère votre serveur, peut installer la version corrigée.
Mettre à jour WordPress et mes extensions suffit-il ?
Non. La faille est dans l'interpréteur PHP, pas dans WordPress. WordPress indique qu'aucune mise à jour de son côté n'est requise ni prévue. Le mode maintenance de WordPress ne protège pas non plus, car PHP traite la requête avant.
Comment connaître la version de PHP de mon site WordPress ?
Dans l'administration : Outils → Santé du site → Infos, rubrique Serveur. La version apparaît aussi dans le panneau de votre hébergeur. Notez le numéro complet (par exemple 8.3.36), pas seulement 8.3 : c'est lui qui dit si le correctif est installé.
Mon site est en PHP 7.4 ou 8.1, que faire ?
PHP ne publie plus de version officielle pour ces branches. Il existe des correctifs de code source pour 7.4, 8.0 et 8.1, mais ils sont à compiler soi-même, ce qu'un hébergement mutualisé ne permet pas. La solution réaliste est de passer en PHP 8.3 ou 8.4, après un test sur une copie du site pour vérifier que le thème et les extensions suivent.
Un site Webflow est-il concerné par PHP2Shell ?
Non. Webflow indique sur son Trust Center que ses services principaux ne reposent pas sur PHP et ne sont pas affectés, et qu'aucune action n'est requise de ses clients. Un site Webflow n'expose ni PHP ni extension côté client.
Combien coûte une migration de WordPress vers Webflow ?
Chez Digidop, une migration est une reconstruction du site sur Webflow, avec reprise des contenus et plan de redirections. Nos fourchettes publiées vont de 10 000 à 30 000 € pour un site web marketing, de 30 000 à 50 000 € pour un site multilingue avec intégrations métiers, et de 50 000 à 100 000 € pour une plateforme web Enterprise, hors licences tierces.
.webp)
