Le 17 juillet 2026, WordPress publiait la version 7.0.2 pour corriger une faille critique permettant à un attaquant de prendre le contrôle d’un site sans même se connecter. La situation était jugée suffisamment grave pour que l’équipe de WordPress.org force les mises à jour automatiques sur les sites concernés.
Le 6 août, soit vingt jours plus tard, WordPress 7.0.3 est sortie. Encore une version de sécurité. Douze vulnérabilités corrigées cette fois. Et le 12 août, la sortie de WordPress 7.0.4 pour corriger entre autres une faille touchant les comptes Auteur.
Si vous gérez un site WordPress, ces deux dates racontent quelque chose d’important sur ce qu’est devenue la maintenance d’un site web en 2026.
Ce que corrige WordPress 7.0.3
La faille la plus notable porte la référence CVE-2026-64638 et affiche un score de gravité de 8,9 sur 10. Il s’agit d’un cross-site scripting sur l’écran de connexion, exploitable sans aucun compte utilisateur, et qui peut mener à l’exécution de code PHP via l’éditeur de thèmes et d’extensions.
Elle concerne toutes les versions de WordPress depuis la 4.7. Autrement dit, à peu près tout le monde.
Les onze autres corrections sont moins spectaculaires mais pas anodines : injections de scripts nécessitant un compte contributeur ou auteur, contournement du filtre CSS, faille SSRF sur la validation d’URL, fuite de commentaires sur des articles protégés par mot de passe, énumération des slugs, élévation de privilèges sur les installations multisites.
Point rassurant : WordPress a rétroporté les correctifs sur toutes les branches encore éligibles, jusqu’à la 4.7. Vous n’avez pas besoin de passer en version majeure pour être protégé. Un site en 6.8 passe en 6.8.7 et se retrouve couvert.
Le vrai sujet n'est pas la faille, c'est le délai
Une vulnérabilité corrigée n’est dangereuse que pendant la fenêtre où elle est connue publiquement et où votre site ne l’a pas encore appliquée.
Cette fenêtre s’est considérablement réduite. Dès la publication d’un correctif, le code de la faille devient lisible par n’importe qui : il suffit de comparer les fichiers avant et après. Les preuves de concept circulent sur GitHub dans les 24 à 48 heures. Les scanners automatisés, eux, tournent en permanence et ne font pas le tri entre le site vitrine d’un artisan à Béziers et une plateforme e-commerce.
Sur la 7.0.2, des signes d’exploitation active ont été rapportés très rapidement après la publication.
Vous n’êtes donc pas en train de vous protéger d’un pirate qui vous aurait choisi. Vous vous protégez d’un robot qui teste 200 000 adresses par heure.
"Mes mises à jour sont automatiques, non ?"
Souvent oui. Et c’est très bien. Mais l’automatique tombe en panne silencieusement, et c’est précisément le problème.
Les cas que je rencontre le plus souvent chez les clients qui me contactent après coup :
- Les mises à jour automatiques ont été désactivées un jour pour déboguer quelque chose, et jamais réactivées.
- Une mise à jour a cassé un affichage il y a deux ans, alors on a tout coupé « en attendant ».
- Le cœur de WordPress se met bien à jour, mais les extensions et le thème restent figés depuis dix-huit mois.
- Un site de préproduction, accessible publiquement, oublié de tous, qui présente exactement la même surface d’attaque que le site principal.
- La mise à jour est passée, elle a cassé un formulaire ou une mise en page, et personne ne s’en est rendu compte pendant trois semaines.
Ce dernier point mérite qu’on s’y arrête. Une mise à jour appliquée sans vérification derrière, ce n’est pas de la maintenance. C’est un pari. La différence entre les deux, c’est quelqu’un qui regarde le site après.
Une faille SSRF (Server-Side Request Forgery ou falsification de requête côté serveur) est une faille de sécurité. Elle permet à un pirate de forcer un serveur web à envoyer des requêtes HTTP vers des cibles non voulues, comme le réseau interne de l’entreprise ou des services cachés.
Ce que couvre une maintenance mensuelle
01.
Une sauvegarde complète avant toute intervention, base de données comprise.
02.
L’application du correctif, sur la branche du site, sans passage forcé en version majeure.
03.
La mise à jour des extensions et du thème dans la foulée, car garder le cœur à jour est nécessaire mais jamais suffisant : les failles d’extensions sont statistiquement bien plus nombreuses.
04.
Un contrôle visuel et fonctionnel derrière : pages clés, formulaires de contact, affichage mobile.
05.
Une restauration immédiate si quelque chose se passe mal, sans que vous ayez à gérer quoi que ce soit.
06.
Une revue des comptes utilisateurs, puisque cinq des douze failles de la 7.0.3 nécessitent un compte contributeur ou auteur pour être exploitées.
Le tout sans que vous ayez à lire une annonce de sécurité, à comprendre ce qu’est un SSRF, ni à vous demander un vendredi soir si votre site est concerné.
Rebelote : WordPress 7.0.4, six jours plus tard
En ce jour du 12 août 2026, soit six jours à peine après la 7.0.3, WordPress publie une nouvelle version de sécurité : la 7.0.4.
Cette fois, un seul correctif, mais du genre qui ne pardonne pas : une exécution de code à distance réservée aux comptes Auteur ou supérieur, exploitable via un envoi de fichier malveillant sur les sites qui utilisent Imagick et Ghostscript pour le traitement d’images. Référencée CVE-2026-65640.
Un compte Auteur suffit. Sur beaucoup de sites, ça inclut un rédacteur externe, un client qui gère lui-même son blog, ou un ancien collaborateur dont l’accès n’a jamais été révoqué.
Comme pour la 7.0.3, le correctif a été rétroporté jusqu’à la branche 4.7, et la 7.1 (encore en RC) l’intègre également.
Trois versions en quatre semaines, et ce n'est pas fini
Trois versions de sécurité en moins d’un mois : la 7.0.2 le 17 juillet, la 7.0.3 le 6 août, la 7.0.4 le 12 août.
WordPress 7.1 est déjà en Release Candidate, avec une sortie annoncée pour le WordCamp US à la mi-août.
Ce n’est plus une exception, c’est un rythme. Et ce rythme ne se suit pas correctement sans quelqu’un qui s’en occupe chaque mois.
Vous avez deux options. Suivre vous-même l’actualité de WordPress, tester, appliquer, vérifier, corriger si besoin. Ou déléguer, et retrouver votre site dans le même état que vous l’avez laissé.
Si vous voulez savoir dans quel état est réellement votre WordPress aujourd’hui, je fais un point gratuit : version du cœur, extensions obsolètes, comptes actifs, sauvegardes. C’est souvent instructif.
Parlons de votre site : je m’occupe de la création et de la maintenance de sites WordPress pour les TPE et PME de Béziers et de l’Hérault depuis 2008.
FAQ - WordPress 7.0.3
Dois-je mettre à jour vers WordPress 7.0.3 en urgence ?
Rapidement, oui, sans pour autant paniquer. La faille la plus grave nécessite qu’un administrateur clique sur un lien piégé depuis un site contrôlé par l’attaquant. Ce n’est pas une prise de contrôle automatique d’une installation par défaut. Mais l’exposition existe tant que le correctif n’est pas appliqué, et rien ne justifie d’attendre.
Mon site est en WordPress 6.8, suis-je concerné ?
Oui, et le correctif existe pour vous. WordPress a rétroporté les corrections jusqu’à la version 4.7. Passez en 6.8.7. Vous n’avez pas besoin de migrer vers la 7.0 pour être protégé.
Je n'ai aucun contributeur sur mon site, dois-je quand même mettre à jour ?
Oui. La faille de l’écran de connexion s’exploite sans compte. Les problèmes de SSRF, de fuite d’information et d’énumération ne demandent pas non plus de privilèges particuliers.
Une maintenance mensuelle, est-ce vraiment nécessaire pour un simple site vitrine ?
Les attaques automatisées ne distinguent pas un site vitrine d’un site marchand. Elles cherchent des versions vulnérables, point. Un site vitrine compromis sert généralement à héberger des pages de spam ou à rediriger vos visiteurs, ce que Google finit par détecter et sanctionner. Le nettoyage coûte systématiquement plus cher qu’une année de maintenance.
Que se passe-t-il si une mise à jour casse mon site ?
Sur un site maintenu, une sauvegarde complète est prise avant intervention et le site est vérifié après. En cas de problème, la restauration prend quelques minutes. Sans maintenance, le risque n’est pas la casse en elle-même : c’est de ne pas s’en apercevoir avant plusieurs semaines.
Les extensions sont-elles concernées par cette mise à jour ?
Non, la 7.0.3 corrige uniquement le cœur de WordPress. Les failles d’extensions et de thèmes sont suivies séparément, et elles représentent en pratique la grande majorité des compromissions. C’est exactement pour cette raison qu’une maintenance ne peut pas se limiter aux mises à jour du cœur.
