Faille de sécurité WordPress : la liste de contrôle

Si le site de votre entreprise tourne sous WordPress, il aurait dû recevoir deux correctifs de sécurité en quinze jours. Le 22 septembre, WordPress a corrigé une faille de sécurité classée critique (WordPress.org), la CVE-2026-87902, notée 9,2 sur 10 (Cyberattaque.org) (Namebay). Le 6 octobre, la version 7.1.3 en a corrigé sept autres (WordPress.org). Le lendemain, le CERT-FR, le centre d'alerte de l'agence française de cybersécurité, a publié un avis qui vise toutes les versions antérieures à 7.1.3 (CERT-FR).

Votre site a-t-il suivi ? Voici ce que cette faille de sécurité WordPress change pour une PME, et la liste de ce qu'il faut vérifier cette semaine.

Ce que permet la faille de sécurité WordPress du 22 septembre

Pour afficher une page, WordPress choisit un « modèle », c'est-à-dire le fichier qui en dessine la mise en page. La faille permet à un inconnu d'influencer ce choix depuis l'adresse de la page. Il peut ainsi forcer le site à charger un autre fichier PHP (le langage dans lequel WordPress est écrit) présent ailleurs sur le serveur (WordPress.org) (Cyberattaque.org).

Deux détails la rendent sérieuse. L'attaquant n'a besoin d'aucun compte sur le site, ni d'aucune action d'un administrateur (Cyberattaque.org) (Namebay). Et si certaines conditions sont réunies sur le serveur et dans le thème, il peut aller jusqu'à exécuter son propre code, donc prendre la main sur le site (WordPress.org).

Ces conditions ne sont pas présentes partout. D'après les éléments publiés, il faut notamment que le thème contienne un dossier dont le nom commence par « page- » et que la configuration PHP du serveur s'y prête (Cyberattaque.org) (Génération-NT). Génération-NT signale toutefois que certaines configurations par défaut, dont les images Docker officielles (des environnements prêts à l'emploi pour héberger WordPress), sont très exposées (Génération-NT).

Toutes les versions de 4.7.0 à 7.1.1 sont touchées (Cyberattaque.org). Un site passé en 7.1.1, publiée le 17 septembre, reste donc vulnérable (Cyberattaque.org).

Des attaques rapides, des versions qui s'enchaînent

Le jour du correctif, aucune attaque réelle n'avait été rendue publique (Cyberattaque.org). Trois jours plus tard, Génération-NT rapportait, d'après les relevés de la société Previdian, des vagues d'attaques automatisées lancées environ cinq heures après l'annonce officielle (Génération-NT). Le mécanisme est connu : un correctif publié montre aussi aux pirates où frapper. Des robots parcourent ensuite Internet à la recherche des sites restés en arrière.

Puis est arrivée la 7.1.3, le 6 octobre, avec sept correctifs de sécurité et quatre corrections de bugs (WordPress.org). Parmi les failles corrigées : du code malveillant glissé dans la page d'administration des commentaires via des commentaires en attente, un moyen de faire tomber le site, une injection SQL (une manipulation de la base de données) dans l'export des contenus, et la possibilité, sans compte, de lire des commentaires laissés sur des articles privés ou non publiés (WordPress.org). Le CERT-FR résume les risques : atteinte à la confidentialité et à l'intégrité des données, déni de service à distance (CERT-FR).

À retenir : la bonne version aujourd'hui, c'est 7.1.3 ou plus récente, pas 7.1.2 (CERT-FR) (WordPress.org).

Ce que risque concrètement une PME

Un site piraté, ce n'est pas seulement une page d'accueil défigurée. Ce sont des visiteurs redirigés vers des sites d'arnaque. Des pages de spam qui apparaissent dans Google sous votre nom. Un formulaire de contact qui collecte des données pour quelqu'un d'autre. Pour une boutique en ligne, ce sont les commandes et les coordonnées des clients qui sont en jeu.

Il y a aussi l'arrêt. Un hébergeur qui détecte un site infecté le suspend souvent le temps du nettoyage. Pendant ce temps, vos prospects tombent sur une page d'erreur. Le coût de ne rien faire se compte en jours d'arrêt et en confiance perdue, bien plus qu'en temps passé sur une mise à jour.

La liste de contrôle à faire cette semaine

1. La version installée

Connectez-vous à l'administration, puis ouvrez Tableau de bord, Mises à jour. La version y est indiquée. Si elle est inférieure à 7.1.3, faites d'abord une sauvegarde (point 3), puis cliquez sur « Mettre à jour maintenant » (WordPress.org).

Votre site tourne sur une branche plus ancienne ? WordPress a reporté le correctif de septembre jusqu'à la branche 4.7, par exemple en 7.0.6 ou 6.9.9 (Cyberattaque.org). Les reports des correctifs de la 7.1.3 étaient annoncés « en cours » le 6 octobre, et WordPress rappelle que seule la version la plus récente est activement suivie (WordPress.org). Le plus sûr reste de passer à la dernière version.

2. Les mises à jour automatiques

Les sites qui acceptent les mises à jour automatiques en arrière-plan reçoivent le correctif seuls (WordPress.org). Encore faut-il que cette fonction n'ait pas été coupée par un développeur ou un hébergeur, ce qui arrive. Sur la page Mises à jour, vérifiez ce qui est indiqué à ce sujet. Si elles sont désactivées et que personne ne sait pourquoi, posez la question.

3. Les sauvegardes

Une sauvegarde utile contient les fichiers et la base de données. Elle est stockée ailleurs que sur le serveur du site. Et elle a déjà été restaurée au moins une fois, pour vérifier qu'elle fonctionne. Posez-vous une question simple : si le site tombait ce soir, qui saurait le remettre en ligne, et à partir de quelle copie ? Notre guide pour choisir un hébergement adapté à WordPress détaille ce qu'un hébergeur doit fournir sur ce point.

4. Les extensions et les thèmes

Chaque extension est une porte de plus. Dans le menu Extensions, supprimez celles qui ne servent plus : une extension désactivée laisse ses fichiers sur le serveur. Pour les autres, regardez la date de dernière mise à jour sur leur fiche. Une extension qui n'a pas bougé depuis des années est sans doute abandonnée : cherchez une remplaçante. Faites de même avec les thèmes inutilisés.

5. Les signes de piratage

Mettre à jour ferme la porte. Cela ne fait pas sortir quelqu'un qui serait déjà entré. Vérifiez donc :

les comptes utilisateurs : un administrateur que personne ne connaît est une alerte sérieuse ;
Google : tapez « site: » suivi de votre nom de domaine et repérez les pages qui ne sont pas les vôtres ;
les redirections : ouvrez le site depuis un téléphone, sans être connecté à l'administration ;
les fichiers : demandez à votre hébergeur s'il voit des fichiers PHP récents et inconnus, notamment dans les dossiers temporaires, que visent les attaques décrites (Génération-NT) ;
les alertes : message de l'hébergeur, avertissement du navigateur, chute soudaine des visites.

Au moindre doute, changez tous les mots de passe (administration, hébergement, base de données) et faites examiner le serveur avant de restaurer quoi que ce soit.

Si la mise à jour est impossible tout de suite, par exemple parce que le site a été très modifié, demandez au moins à votre hébergeur d'appliquer la parade citée par Génération-NT : désactiver un réglage PHP qui casse la chaîne d'attaque (Génération-NT). Ce n'est qu'un pansement, qui ne règle pas le fond (Génération-NT).

Faire soi-même ou confier la maintenance

Pour un site vitrine simple, avec peu d'extensions et une personne en interne qui se connecte chaque semaine, la liste ci-dessus suffit souvent. Ce qui compte, c'est la régularité, pas la technique.

La question change quand le site vend, prend des rendez-vous ou collecte des données clients. Elle change aussi quand plus personne n'a les accès, ou quand le développeur d'origine est parti. Avec des attaques signalées quelques heures après un correctif (Génération-NT), le vrai sujet est le délai : combien de temps s'écoule chez vous entre l'annonce d'une faille et son correctif ?

Si vous confiez la maintenance, posez ces questions avant de signer :

Sous quel délai les mises à jour de sécurité sont-elles appliquées ?
À quelle fréquence les sauvegardes sont-elles faites, où sont-elles stockées, et quand ont-elles été testées ?
Le nettoyage après un piratage est-il compris ou facturé à part ?
Recevez-vous un compte rendu de ce qui a été fait ?
Restez-vous propriétaire de tous les accès : hébergement, nom de domaine, administration ?

Un prestataire qui répond clairement à ces cinq questions a de bonnes chances de connaître son métier. S'il reste vague, vous savez à quoi vous en tenir.

Ce que vous pouvez faire aujourd'hui

Ouvrez l'administration de votre site et lisez le numéro de version. S'il est inférieur à 7.1.3, sauvegardez, mettez à jour, puis passez en revue les signes de piratage. Si vous préférez qu'un regard extérieur s'en charge, DiGit Summit assure la maintenance et la sécurité de sites WordPress ; vous pouvez aussi nous écrire depuis la page contact.

Questions fréquentes

Mon site est en WordPress 7.1.2 : suis-je protégé ?

Contre la faille critique CVE-2026-87902, oui. Mais la version 7.1.3, publiée le 6 octobre, corrige sept autres failles, et l'avis du CERT-FR vise toutes les versions antérieures à 7.1.3. Il faut donc mettre à jour une nouvelle fois.

La mise à jour risque-t-elle de casser mon site ?

Une version de sécurité comme la 7.1.3 change peu de choses, mais aucun site n'est à l'abri d'un conflit avec une extension ou un thème très modifié. Faites une sauvegarde complète juste avant, puis vérifiez vos pages clés et vos formulaires juste après. Si le site a été fortement personnalisé, faites d'abord l'essai sur une copie.

Mon thème n'a pas de dossier « page- » : dois-je quand même mettre à jour ?

Oui. Ces conditions techniques sont difficiles à vérifier sans accès au serveur, et la configuration PHP compte aussi. Surtout, la version 7.1.3 corrige d'autres failles qui ne dépendent pas du thème. C'est la mise à jour que WordPress recommande.

J'ai mis à jour : faut-il encore vérifier quelque chose ?

Oui, si le site est resté sur une version vulnérable après le 22 septembre. La mise à jour bloque l'attaque, mais n'efface pas ce qu'un pirate aurait pu installer avant. Contrôlez les comptes administrateurs, les pages indexées par Google et les fichiers récents avec votre hébergeur.

Mon développeur n'est plus joignable : par où commencer ?

Récupérez d'abord les accès qui vous appartiennent : hébergement, nom de domaine et compte administrateur du site. Votre hébergeur peut souvent vous aider à retrouver l'accès et à faire une sauvegarde. Ensuite, faites vérifier la version et l'état du site par un prestataire de maintenance.

Sources

Cet article vous a été utile ?

Faille de sécurité WordPress : passez en 7.1.3 et contrôlez votre site