WordPress : l'alerte du CERT-FR est close, la mise à jour reste à faire

<p>Le CERT-FR a clôturé le 24 août 2026 son alerte sur deux failles de WordPress permettant une prise de contrôle du site sans authentification. La...

Il y a un contresens fréquent dans la lecture des bulletins de sécurité: quand une alerte est clôturée, on suppose que le danger est passé. C'est l'inverse. Une clôture signifie que l'organisme qui suivait le dossier estime avoir dit tout ce qu'il avait à dire — le correctif existe, les consignes sont publiées, il n'y a plus de nouvelle information à diffuser. Le site qui n'a pas été mis à jour, lui, est exactement aussi vulnérable qu'avant. Le CERT-FR a clôturé le 24 août 2026 son bulletin d'alerte CERTFR-2026-ALE-007, consacré à deux vulnérabilités de WordPress Core corrigées par l'éditeur le 17 juillet 2026: une injection SQL (CVE-2026-60137) et un contournement de la politique de sécurité (CVE-2026-63030). Enchaînées, ces deux failles permettent à un attaquant non authentifié — donc sans compte ni mot de passe sur le site — d'exécuter du code à distance sur les versions 6.9 et suivantes.

D'après le bulletin, les versions concernées sont les 6.8.x antérieures à 6.8.6, les 6.9.x antérieures à 6.9.5, les 7.x antérieures à 7.0.2 et les 7.1.x antérieures à 7.1 beta2. Le CERT-FR indiquait avoir connaissance d'un code de démonstration public et anticipait des tentatives d'exploitation à grande échelle. De son côté, Cybermalveillance.gouv.fr avait diffusé une AlerteCyber sur le même sujet le 23 juillet 2026. Les numéros de version et de vulnérabilité cités ici sont ceux des avis officiels à leur date de publication; vérifiez la version en vigueur au moment où vous lisez ces lignes. Dans beaucoup d'entreprises, le site vitrine ou la boutique en ligne est le seul serveur réellement exposé sur Internet. Il est aussi, souvent, le moins surveillé: confié à un prestataire il y a plusieurs années, alimenté de temps en temps, jamais inventorié dans le plan de maintenance. C'est une combinaison désagréable, parce qu'une prise de contrôle de ce serveur ouvre plusieurs scénarios très concrets.

Défiguration ou détournement du site, avec l'atteinte de réputation qui va avec, souvent découverte par un client avant l'entreprise elle-même. Hébergement de contenus frauduleux — pages de hameçonnage, fichiers malveillants — sous votre nom de domaine, ce qui expose au blocage du domaine par les navigateurs et les messageries.

Vol de données clients: comptes, commandes, adresses, avec les obligations de notification que cela déclenche. Rebond vers le reste du système d'information, si le serveur web partage des identifiants, un réseau ou des accès avec l'interne.

Les mesures à prendre

Identifiez la version exacte de chaque site WordPress de l'entreprise. Elle figure dans le tableau de bord, rubrique Mises à jour. Si le site est géré par un prestataire, demandez-lui la réponse par écrit. Pensez aux sites oubliés: ancienne campagne, blog, site d'une filiale. Mettez à jour sans attendre vers 6.8.6, 6.9.5, 7.0.2 ou une version plus récente selon votre branche. Avant l'opération: sauvegarde complète des fichiers et de la base de données, et si vous en avez la possibilité, essai préalable sur un environnement de préproduction.

Si la mise à jour est impossible immédiatement, les chercheurs à l'origine de la découverte préconisent de bloquer l'accès non authentifié à l'API REST, notamment le chemin /wp-json/batch/v1 et les requêtes portant le paramètre rest_route=/batch/v1, au moyen d'un pare-feu applicatif. C'est un contournement temporaire, pas un correctif: à valider hors production, car il peut casser des fonctionnalités. Activez les mises à jour automatiques de sécurité du cœur de WordPress, ainsi que celles des extensions et des thèmes.

Cherchez des traces de compromission: comptes administrateurs que personne ne reconnaît, fichiers PHP récents dans wp-content/uploads, tâches planifiées inhabituelles, modifications de pages sans explication. Vérifiez que votre sauvegarde est restaurable et conservée hors ligne, puis testez réellement la restauration. Une sauvegarde jamais testée n'est qu'une hypothèse.

Inscrivez le site à un plan de mise à jour mensuel, pour ne pas revivre la même urgence au prochain bulletin.

Les chemins, paramètres et numéros de version indiqués sont donnés à titre indicatif: ils doivent être validés sur votre propre installation avant toute application en production. La question à poser cette semaine n'est pas « sommes-nous concernés? » mais « qui, chez nous ou chez notre prestataire, a vérifié la version et me le confirme par écrit? ». Sur un site public exposé à un code d'exploitation déjà diffusé, l'écart entre un correctif appliqué et un correctif prévu se mesure en jours, et parfois moins. CERT-FR, bulletin d'alerte CERTFR-2026-ALE-007 relatif à des vulnérabilités dans WordPress, dernière version du 24 août 2026 (clôture). WordPress, bulletin de sécurité accompagnant la version 7.0.2, 17 juillet 2026.

Cybermalveillance.gouv.fr, AlerteCyber consacrée à ces vulnérabilités, 23 juillet 2026.

Synthèse rédactionnelle originale de TICLIC, établie à partir de la veille du 25 août 2026. Les identifiants de vulnérabilités, numéros de version et dates proviennent des avis cités; ils n'ont pas fait l'objet d'une vérification indépendante complémentaire lors de la rédaction, la consultation directe des sources en ligne n'ayant pas été possible. L'existence d'un code de démonstration public et le niveau d'exploitation constatée sont ceux décrits dans le bulletin à sa date de publication et peuvent avoir évolué: reportez-vous au CERT-FR pour l'état à jour.

Tags: cybersécuritémise à jourwordpress
← Retour aux actualités