WordPress piraté en quelques heures : ce que la faille de septembre 2026 change pour votre contrat de maintenance

Le 22 septembre 2026, WordPress a publié en urgence la version 7.1.2 pour corriger une faille critique du noyau, exploitée dès le jour même de sa divulgation. Cinq jours plus tard, l'agence américaine de cybersécurité CISA l'a inscrite à son catalogue des vulnérabilités activement exploitées, avec une échéance de correction fixée à ce jour, le 28 septembre 2026, pour les agences fédérales américaines. Cet épisode n'est pas isolé : la même semaine, une faille tout aussi critique touchait une extension Joomla très répandue. Il éclaire une réalité simple, valable pour tous les CMS : un site vitrine n'est jamais à l'abri d'une fenêtre d'exposition de quelques heures entre la divulgation d'une faille et son exploitation massive, et c'est cette fenêtre que la maintenance professionnelle est censée fermer.

Ce qui s'est réellement passé entre le 22 et le 28 septembre 2026

La faille référencée CVE-2026-87902 touche la fonction de résolution des templates de page du cœur de WordPress (get_page_template()), depuis la version 4.7 jusqu'à la 7.1.1, et permet à un attaquant non authentifié d'inclure un fichier PHP situé hors du répertoire du thème actif pour exécuter du code arbitraire sur le serveur. Le correctif a été publié le 22 septembre 2026 dans WordPress 7.1.2, avec des rétroportages vers les branches de maintenance 7.0.6, 6.9.9 et 6.8.10 pour les sites qui n'avaient pas encore basculé sur la version majeure la plus récente.

La chronologie est ce qui distingue cet épisode d'une simple alerte de routine. Les premières tentatives d'exploitation ont été enregistrées dès 11h49 UTC le 22 septembre 2026, le jour même de la publication du correctif. Le lendemain, le réseau de sondes de sécurité Previdian avait déjà comptabilisé 68 tentatives d'exploitation distinctes. Le 24 septembre, la faille faisait la une de plusieurs médias spécialisés en cybersécurité. Le 25 septembre 2026, la CISA (l'agence américaine de cybersécurité) l'a ajoutée à son catalogue des vulnérabilités activement exploitées (KEV), avec un score de gravité CVSS de 9,2 sur 10 et une échéance de remédiation fixée au 28 septembre 2026 pour les administrations fédérales américaines. Moins d'une semaine s'est donc écoulée entre la divulgation du correctif et une réponse au niveau d'un État, ce qui donne une mesure concrète de la vitesse à laquelle une faille de ce type se transforme en risque opérationnel pour n'importe quel site resté en version 7.1.1 ou antérieure.

Comprendre, sans jargon, ce que fait une faille d'inclusion de fichier

Une faille d'inclusion de fichier permet à un attaquant de faire charger et exécuter, par le serveur lui-même, un fichier qu'il ne devrait jamais pouvoir atteindre : dans le cas de CVE-2026-87902, un fichier PHP situé en dehors du dossier du thème actif. Concrètement, le mécanisme de WordPress chargé de déterminer quel modèle de page afficher accepte, sous certaines conditions d'environnement, un chemin de fichier détourné plutôt qu'un simple nom de template prévu par le thème.

Pour un dirigeant ou un responsable marketing sans formation technique, l'important n'est pas le détail du code mais la conséquence : une fois le fichier détourné exécuté, l'attaquant dispose des mêmes droits que le serveur web lui-même, ce qui ouvre la voie à la création de comptes administrateur, à l'installation de portes dérobées ou à l'utilisation du site pour héberger du contenu malveillant (hameçonnage, redirections, minage). C'est pour cette raison que ce type de faille est classé « critique » et non « modérée » : il ne nécessite ni identifiant, ni mot de passe, ni interaction d'un visiteur. Le serveur suffit à lui-même pour être compromis, ce qui explique la vitesse d'exploitation observée dès les premières heures suivant la divulgation.

Un symptôme, pas une exception : Joomla et les extensions tierces concernés la même année

La faille WordPress de septembre n'est pas un accident isolé propre à un seul éditeur : la même année 2026, l'extension d'édition de contenu JCE pour Joomla, très largement installée, a fait l'objet d'une faille tout aussi grave, référencée CVE-2026-48907. Publiée le 17 juin 2026, elle permettait à un attaquant non authentifié de créer de nouveaux profils d'éditeur puis d'y téléverser et d'exécuter du code PHP directement sur le serveur, sans aucun identifiant. Son score de gravité, 10 sur 10 sur l'échelle CVSS 4.0, est le maximum possible. Elle a elle aussi été inscrite au catalogue KEV de la CISA, avec une échéance de remédiation fixée au 7 juillet 2026 pour les administrations concernées, et corrigée par les versions 2.9.99.5 puis 2.9.99.6 de l'extension.

Un troisième exemple, plus discret mais révélateur, concerne l'écosystème des extensions WordPress : l'extension « User Registration & Membership », installée sur plus de 60 000 sites actifs, a été touchée en mars 2026 par la faille CVE-2026-1492, qui permettait à un visiteur non authentifié de manipuler une requête d'inscription pour s'attribuer lui-même les droits d'administrateur, corrigée par les versions 5.1.3 puis 5.1.4. Le point commun de ces trois épisodes n'est pas le CMS, c'est la surface d'attaque : le cœur du logiciel dans un cas, une extension tierce très répandue dans les deux autres. Pour un site vitrine sous Joomla, Drupal, PrestaShop ou WordPress, le risque ne vient donc pas uniquement du CMS lui-même mais de l'ensemble des composants installés autour de lui, chacun avec son propre calendrier de correctifs à suivre.

Pourquoi la mise à jour seule ne suffit pas toujours à fermer le risque à temps

Appliquer une mise à jour de sécurité paraît une évidence, mais le délai entre la publication d'un correctif et son déploiement effectif en production est rarement instantané, alors que l'exploitation de CVE-2026-87902 a commencé le jour même de sa publication. Un site professionnel ne se met pas à jour à l'aveugle : une extension incompatible, un thème personnalisé qui repose sur l'ancien comportement d'une fonction cœur, ou une base de données volumineuse à sauvegarder avant toute intervention sont autant de raisons légitimes de tester une mise à jour avant de la pousser en production. C'est précisément cette période de test qui constitue la fenêtre de risque que les attaquants exploitent.

Le CERT-FR (le centre gouvernemental français de veille et d'alerte en sécurité informatique, rattaché à l'ANSSI) a documenté ce dilemme lors d'une précédente alerte critique sur WordPress, en recommandant, pour les sites ne pouvant pas appliquer le correctif immédiatement, de bloquer l'accès non authentifié à certains points d'entrée sensibles de l'API REST via un pare-feu applicatif, en attendant que la mise à jour puisse être testée et déployée dans de bonnes conditions. Cette approche, connue sous le nom de correctif virtuel, ne remplace jamais la mise à jour elle-même mais réduit la fenêtre d'exposition à quelques heures au lieu de plusieurs jours, en particulier lorsqu'elle est pilotée par une équipe qui surveille activement ce type d'alerte.

Le pare-feu applicatif : un filet de sécurité pendant la fenêtre de risque, pas un substitut

Un pare-feu applicatif web (WAF) analyse chaque requête adressée au site avant qu'elle n'atteigne le CMS, et bloque celles qui correspondent à des signatures d'attaque connues, y compris les tentatives d'inclusion de fichier comme celle exploitée par CVE-2026-87902. Sur un site sous contrat de maintenance professionnel, un WAF managé fait généralement partie de l'offre : son éditeur met à jour ses règles de détection dès qu'une faille majeure est publiée, souvent avant même que l'équipe technique n'ait eu le temps de tester le correctif officiel.

Sur le marché français, un pare-feu applicatif et les briques de sécurité associées (sauvegarde externalisée, mise en cache sécurisée) représentent, hors intervention humaine, de l'ordre d'une trentaine d'euros par mois pour un hébergement mutualisé standard : un montant généralement absorbé dans un forfait de maintenance plutôt que facturé à part. La limite du WAF doit cependant être posée clairement : il réduit la surface d'exposition et gagne du temps, mais il ne corrige pas la faille sous-jacente. Un site protégé par un WAF et resté en version 7.1.1 reste vulnérable dès qu'une requête suffisamment nouvelle contourne les règles de détection. L'ordre des priorités reste donc invariable : mise à jour d'abord, pare-feu applicatif en filet de sécurité complémentaire, jamais l'inverse.

Ce qu'un contrat de maintenance professionnel change concrètement face à ce type d'alerte

Un contrat de maintenance sérieux transforme un événement comme celui du 22 septembre 2026 d'une urgence subie en une procédure suivie : veille active sur les bulletins de sécurité des CMS utilisés, environnement de préproduction où le correctif est testé avant sa mise en ligne, et astreinte capable d'intervenir en dehors des heures ouvrées si l'exploitation est déjà en cours. C'est cette combinaison, plus que la seule application du correctif, qui distingue un site accompagné d'un site laissé à lui-même.

Le contraste est net avec un site sans accompagnement structuré : les offres d'entrée de gamme ou les solutions automatisées à bas coût traitent en général les demandes de support sous 24 à 72 heures ouvrées, un délai largement suffisant pour qu'une faille massivement exploitée compromette le site avant toute intervention. Une astreinte de type agence, avec alertes de sécurité suivies en continu, réduit ce délai à quelques heures, ce qui correspond précisément à la fenêtre d'exploitation observée sur CVE-2026-87902. Le contrat de maintenance ne se limite donc pas à « faire les mises à jour » : il fixe un niveau de réactivité contractuel face à ce type d'événement, ce que la page contrat de maintenance web détaille par niveau de service.

Combien coûte l'inaction : le prix réel d'une intervention d'urgence sur un site compromis

Sur le marché français, une intervention d'urgence pour nettoyer et sécuriser un site déjà compromis se situe le plus souvent entre 500 et 1 000 euros HT, sans compter la perte d'activité pendant l'indisponibilité du site ni l'impact sur son référencement lorsque le moteur de recherche détecte du contenu malveillant. À titre de comparaison, un forfait de maintenance mensuel pour un site vitrine se situe, selon la profondeur des prestations incluses (sauvegardes, surveillance, mises à jour testées, sécurité), dans une fourchette de 30 à 300 euros HT par mois sur le marché français ; une intervention ponctuelle hors forfait se facture, en moyenne constatée, autour de 90 euros HT de l'heure.

Le calcul économique est donc simple à poser, sans qu'il soit besoin d'avancer un tarif propre à un prestataire en particulier : quelques mois de forfait de maintenance couvrent généralement le coût d'une seule intervention d'urgence post-piratage, sans compter le temps perdu, la communication de crise éventuelle et le risque de récidive si la cause initiale de la compromission n'a pas été traitée en profondeur. C'est ce diagnostic de fond, plutôt qu'un simple nettoyage de surface, qu'apporte un dépannage de site internet mené par une équipe technique, en particulier lorsque le site a déjà été touché.

Ce que le RGPD impose si des données personnelles sont concernées par la compromission

Si le site compromis collecte des données personnelles, ne serait-ce qu'un formulaire de contact ou une liste d'abonnés à une newsletter, la découverte d'une intrusion déclenche, indépendamment du nettoyage technique, des obligations légales précises fixées par le RGPD, avec des délais courts à respecter et des sanctions qui peuvent être aussi bien administratives que pénales. Le règlement général sur la protection des données impose, en son article 33, une notification à la CNIL dans un délai maximal de 72 heures après la prise de connaissance de l'incident ; lorsque le risque pour les personnes concernées est élevé, par exemple en cas de vol de coordonnées bancaires en clair sur une boutique en ligne, l'article 34 impose en complément d'en informer directement les personnes concernées, sans délai injustifié.

Cette chronologie légale place le prestataire de maintenance dans une position particulière : l'article 33.2 du RGPD lui impose d'alerter l'entreprise responsable du site « dans les meilleurs délais » dès qu'il constate une intrusion, une notification écrite et horodatée étant ce qui permet ensuite à l'entreprise de faire courir, ou non, son propre délai de 72 heures vis-à-vis de la CNIL. Sur le plan pénal, le code pénal sanctionne le défaut de sécurisation des traitements de données de cinq ans d'emprisonnement et 300 000 euros d'amende (article 226-17), et l'accès frauduleux à un système avec suppression de données de trois à cinq ans d'emprisonnement et de 100 000 à 150 000 euros d'amende (articles 323-1 et 323-3). Ce volet réglementaire, souvent sous-estimé au moment de choisir un contrat de maintenance, justifie à lui seul qu'un incident de sécurité soit documenté et tracé dès sa détection, plutôt que traité comme un simple problème informatique refermé une fois le site nettoyé.

La checklist des 48 heures qui suivent l'annonce d'une faille critique sur votre CMS

Face à une alerte comme celle du 22 septembre 2026, l'ordre des vérifications compte autant que leur exhaustivité : identifier précisément la version installée, tester le correctif avant de le déployer, et ne pas se reposer sur la seule apparence de fonctionnement normal du site, qui ne prouve rien quant à une éventuelle compromission déjà en cours.

• Identifier la version exacte du CMS et de ses extensions installée en production, et la comparer à la liste des versions corrigées annoncées par l'éditeur.
• Vérifier si le site est déjà concerné par la fenêtre d'exploitation en consultant les journaux serveur à la recherche de requêtes suspectes sur les points d'entrée visés par la faille, et en recherchant des fichiers PHP inconnus ou récemment modifiés dans les dossiers de téléversement.
• Tester le correctif en environnement de préproduction avant de le déployer sur le site en ligne, pour vérifier sa compatibilité avec le thème et les extensions actives.
• Si le correctif ne peut pas être déployé immédiatement, activer ou renforcer une règle de pare-feu applicatif ciblant spécifiquement le point d'entrée concerné, à titre de mesure temporaire.
• Consulter les bulletins officiels (CERT-FR, catalogue KEV de la CISA, bulletin de sécurité de l'éditeur du CMS) pour connaître les indicateurs de compromission spécifiques à la faille et les vérifier sur le site.
• Renforcer la surveillance pendant les 48 à 72 heures suivant la divulgation, période où le volume de tentatives d'exploitation automatisées est statistiquement le plus élevé, comme l'a montré le passage de zéro à 68 tentatives détectées en une seule journée sur CVE-2026-87902.
• Documenter l'incident, même en l'absence de compromission avérée, pour alimenter le prochain audit de site web et affiner la procédure de réaction pour la prochaine alerte.

Ce que les DSI responsables de plusieurs sites doivent en retenir

Pour un directeur des systèmes d'information ou un responsable communication gérant plusieurs sites vitrines, parfois sur des CMS différents hérités de fusions, de rachats ou de projets menés par plusieurs agences successives, le risque principal n'est pas technique mais d'inventaire : savoir, à l'instant où une faille comme CVE-2026-87902 est publiée, quels sites du parc utilisent réellement la version concernée, sans avoir à interroger chaque agence ou chaque webmaster séparément.

Un site isolé, oublié dans un coin du parc digital parce qu'il ne génère plus beaucoup de trafic, reste un point d'entrée aussi exploitable qu'un site vitrine principal : une fois compromis, il peut servir de rebond vers l'infrastructure d'hébergement partagée ou nuire à la réputation de l'ensemble du domaine. C'est cette visibilité centralisée, associée à un traitement homogène des alertes de sécurité sur l'ensemble des sites d'un même portefeuille, que vise une prestation d'infogérance de parc digital, plutôt que la gestion site par site qui laisse statistiquement plus de chances à une faille de passer inaperçue.

Foire aux questions

Mettre à jour vers WordPress 7.1.2 suffit-il à protéger mon site contre CVE-2026-87902 ?

Oui, à condition que la mise à jour ait été réellement appliquée en production : la version 7.1.2, ainsi que les rétroportages 7.0.6, 6.9.9 et 6.8.10 publiés le 22 septembre 2026, corrigent la fonction de résolution de template exploitée par cette faille. Vérifiez la version affichée dans le tableau de bord d'administration, sous « Mises à jour », et pas seulement la présence d'une notification de mise à jour disponible, qui peut être ignorée sur un site laissé sans suivi.

Comment savoir si mon site a déjà été ciblé par cette faille ?

Les signes à rechercher sont des comptes administrateur non reconnus créés récemment, des fichiers PHP présents dans des dossiers qui ne devraient contenir que des images ou des documents, et des requêtes inhabituelles dans les journaux du serveur pointant vers les mécanismes de gestion de templates. En cas de doute, un audit technique reste la seule manière fiable de confirmer l'absence de compromission, une simple vérification visuelle du site ne suffisant jamais à l'exclure.

Un pare-feu applicatif suffit-il à lui seul, sans appliquer la mise à jour ?

Non : un pare-feu applicatif réduit la fenêtre d'exposition en filtrant les requêtes correspondant à des signatures d'attaque connues, mais il ne corrige pas la faille elle-même. Le CERT-FR ne le recommande qu'à titre de mesure temporaire, dans l'attente d'une mise à jour testée et déployée, jamais comme une alternative durable à celle-ci.

Ce type de faille concerne-t-il aussi Joomla, Drupal ou PrestaShop, et pas seulement WordPress ?

Oui : la même année 2026, l'extension Joomla JCE a fait l'objet d'une faille notée 10 sur 10 en gravité (CVE-2026-48907), et une extension WordPress installée sur plus de 60 000 sites a été touchée par une faille distincte (CVE-2026-1492). Le risque ne dépend pas du CMS choisi mais de la rigueur avec laquelle son cœur et ses extensions sont maintenus à jour, quel que soit l'éditeur.

Mon site tourne sur une ancienne version de CMS qui n'est plus maintenue par son éditeur : que faire en priorité ?

Un CMS en fin de vie ne reçoit plus aucun correctif de sécurité, y compris pour des failles aussi critiques que celle du 22 septembre 2026 : la priorité n'est alors plus le suivi des alertes ponctuelles mais la planification d'une montée de version ou d'une migration, un audit préalable permettant de mesurer l'ampleur réelle des travaux avant de s'engager sur un calendrier.

Passez à l'action avant la prochaine alerte critique

Entre le 22 et le 28 septembre 2026, une seule semaine aura suffi pour qu'une faille critique WordPress passe de la divulgation à l'inscription au catalogue fédéral américain des vulnérabilités activement exploitées, avec un exemple tout aussi grave côté Joomla la même année. Pulsar Agency accompagne, depuis 2005, les dirigeants et responsables marketing ou informatique de PME et de grands comptes dans la maintenance et l'infogérance de leurs sites vitrines existants, avec une veille sur les failles de sécurité, un environnement de test avant chaque mise à jour et une astreinte technique. Découvrez notre offre de sécurité de site web pour évaluer, sans engagement, le niveau de protection actuel de votre site.