WordPress 7.0.3 puis 7.0.4 : deux correctifs en six jours

Le 6 août 2026, une mise à jour de sécurité est tombée sur le socle qui fait tourner une part majeure du web. Six jours plus tard, une seconde. Pour une équipe qui exploite un site vitrine ou une boutique sous WordPress, la question n'est pas de savoir si ces failles sont spectaculaires. C'est de savoir qui applique le correctif, sur quelles installations, et en combien de temps.

WordPress 7.0.3 corrige une faille exploitable sans compte

La version 7.0.3, publiée le 6 août 2026 par le projet WordPress, regroupe plusieurs correctifs de sécurité. Le plus lourd porte la référence CVE-2026-64638 : le NVD (National Vulnerability Database), la base de vulnérabilités tenue par le NIST, l'institut américain des standards et de la technologie, lui attribue un score CVSS 4.0 de 8,9, en sévérité haute.

Il s'agit d'une XSS réfléchie pré-authentification. En clair : du code glissé dans une URL, renvoyé tel quel par la page, puis exécuté dans le navigateur de la victime, sans qu'il soit nécessaire de posséder le moindre compte sur le site. Le point d'entrée est l'écran de connexion, autrement dit la page qu'une installation ne peut pas fermer au public sans cesser de fonctionner.

De là, l'escalade vers une exécution de code PHP reste possible, mais elle n'a rien d'automatique. L'avis publié par le projet le dit noir sur blanc : cette escalade dépend de conditions qui échappent au contrôle de l'attaquant, et suppose de l'ingénierie sociale pour amener la bonne personne à cliquer au bon moment. C'est une chaîne à plusieurs maillons, pas un bouton rouge.

Six jours plus tard, 7.0.4 corrige une exécution de code bien réelle

WordPress 7.0.4 est sorti le 12 août 2026. Cette fois, la vulnérabilité corrigée, CVE-2026-65640, est une exécution de code à distance authentifiée : un fichier malveillant déposé via l'envoi de médias permet de faire tourner du code sur le serveur. Deux conditions pour que ça marche : disposer d'un compte de rôle Auteur ou supérieur, et que l'installation combine Imagick et Ghostscript, deux briques serveur de traitement d'images.

Le rôle Auteur n'a rien d'un privilège rare. C'est le niveau qu'on donne à un rédacteur, à un stagiaire en communication, à un partenaire qui publie des contenus. Sur un site où les comptes s'empilent depuis cinq ans sans revue, la barrière est plus basse qu'elle en a l'air. C'est exactement le terrain où l'authentification forte et la revue régulière des accès changent quelque chose de mesurable.

La distinction entre les deux versions vaut d'être retenue, parce qu'elle circule mal : la 7.0.3 corrige une faille ouverte à tout le monde mais dont l'exécution de code suppose un scénario complet, la 7.0.4 corrige une exécution de code directe mais qui demande un compte et un environnement précis.

Aucune exploitation connue, et ce n'est pas un détail

Le point est important, parce que ce genre d'annonce déclenche vite des raccourcis : à la date de publication des correctifs, aucune exploitation dans la nature n'est documentée. Le statut d'exploitation renseigné dans la fiche du NVD est « none », et le média spécialisé en cybersécurité The Hacker News relevait le 7 août 2026 que l'avis du projet ne faisait état d'aucune attaque observée.

Mieux : les deux vulnérabilités ont été signalées de façon responsable par l'équipe de recherche pwn.ai, que le projet WordPress remercie nommément dans ses deux annonces. Des chercheurs ont trouvé, prévenu, et le correctif est sorti avant le moindre incident. C'est le fonctionnement souhaitable d'un écosystème mature, et ça mérite d'être dit aussi clairement que les scores CVSS.

La nuance compte pour votre arbitrage : il n'y a pas d'urgence de crise, il y a une fenêtre. Une fois l'avis publié, le mécanisme est décrit noir sur blanc, et repérer les installations restées en arrière devient un exercice de routine pour les scanners qui balaient le web. Le compte à rebours démarre à la publication du correctif, pas à la première attaque.

Un correctif rétroporté jusqu'en 2016

Le détail le plus parlant de l'épisode tient dans la liste des versions publiées. La faille touche toutes les versions de 4.7.0 à 7.0.2, soit vingt-trois branches encore éligibles aux correctifs de sécurité. Le projet a donc reconstruit et publié la correction vingt-quatre fois, de la 7.0.3 jusqu'à la 4.7.34. La branche 4.7 est sortie le 6 décembre 2016 : près d'une décennie de versions couvertes par un même avis.

Ce travail prend tout son sens rapproché de la place occupée par le CMS. Selon W3Techs, service de recensement des technologies du web, WordPress équipe 40,8 % de l'ensemble des sites recensés et 59,0 % de ceux dont le CMS est identifié (relevé du 17 août 2026). Un correctif publié sur ce socle ne concerne pas une niche.

Le travail de maintenance amont est fait, et bien fait. Ce qui ne se délègue pas au projet, c'est l'application côté site : un correctif publié n'a d'effet que sur les installations qui l'installent réellement.

Ce qu'une équipe vérifie cette semaine

Quatre vérifications suffisent à qualifier l'exposition d'un parc, et elles se font sans attendre l'aval de personne.

• La version installée, sur chaque site du parc et pas seulement sur le principal.
• L'état des mises à jour automatiques du CMS, souvent désactivées lors d'une personnalisation ancienne et jamais réactivées depuis.
• La présence d'Imagick et de Ghostscript sur l'hébergement, à demander à l'hébergeur quand la main n'est pas chez vous.
• La liste des comptes de rôle Auteur ou supérieur, avec fermeture des accès devenus inutiles.

Sur un site, comptez une demi-journée. Sur un parc de trente sites hérités de trois prestataires différents, c'est un autre sujet. C'est précisément ce que couvre une maintenance applicative suivie : quelqu'un dont le métier est de voir passer l'avis de sécurité, de qualifier l'impact réel et d'appliquer la mise à jour, sans que ça dépende du retour de congés d'une personne en particulier. Chez Koul, on rattache ce suivi à l'infrastructure et à l'hébergement, parce qu'une question comme « est-ce que Ghostscript tourne sur ce serveur ? » se répond côté infra, pas côté back-office.

Quand le parc est ancien, mal documenté ou repris d'un prestataire précédent, la porte d'entrée reste un audit et une étude de cadrage : on établit l'inventaire réel des installations, des extensions et des accès, on hiérarchise ce qui expose vraiment, et on chiffre la remise à niveau. Deux versions de sécurité en six jours, c'est le rappel que ce travail-là ne se fait pas une fois pour toutes.

Pour aller plus loin

• Ce que fait notre agence pluridisciplinaire au quotidien
• Refondre un site vieillissant sans tout jeter
• Pourquoi un site sur mesure prend du temps
• Les nouveautés de PHP 8.5

Sources

Chaque fait et chaque chiffre de cet article provient des sources ci-dessous, consultées le 17 août 2026 :

• WordPress 7.0.3, annonce officielle du projet WordPress (6 août 2026)
• WordPress 7.0.4, annonce officielle du projet WordPress (12 août 2026)
• Avis de sécurité GHSA-52p2-r8wf-jcrf, dépôt de développement WordPress
• CVE-2026-64638, fiche du National Vulnerability Database (NIST)
• WordPress 4.7, documentation officielle des versions (6 décembre 2016)
• Analyse de la faille pré-authentification (The Hacker News, 7 août 2026)
• Statistiques d'usage de WordPress (W3Techs)