Deux correctifs WordPress en six jours : êtes-vous concerné ?

Un gérant nous appelle un mercredi matin, un courriel d'alerte sous les yeux : faille critique WordPress, mise à jour immédiate recommandée. Dans la même boîte, une agence qu'il ne connaît pas propose un audit de sécurité en urgence. Sa question est la bonne, et c'est celle que presque personne ne pose : est-ce que son site est réellement exposé, ou reçoit-il une alerte générique adressée à des millions d'installations ?

Le mois d'août 2026 a été chargé pour WordPress. La version 7.0.3 est publiée le 6 août avec une dizaine de correctifs de sécurité. Six jours plus tard, le 12 août, la version 7.0.4 sort pour une seule vulnérabilité, mais une exécution de code à distance notée 8,8 sur 10. Deux versions de sécurité en moins d'une semaine, cela suffit à inquiéter un dirigeant et à nourrir beaucoup de démarchage. Cet article explique comment trancher en quelques minutes, et pourquoi la réponse ne change presque rien à la conduite à tenir.

Ce que corrige exactement la version 7.0.4

La vulnérabilité porte la référence CVE-2026-65640. Elle permet à une personne disposant déjà d'un compte sur votre site d'exécuter du code sur le serveur en envoyant un fichier piégé dans la médiathèque. Le fichier se présente comme une image ordinaire, une extension .png par exemple, mais il contient en réalité un programme PostScript.

Le point important est que la faiblesse d'origine n'appartient pas au cœur de WordPress. Elle naît d'un désaccord entre deux briques du serveur. WordPress oriente le fichier vers son outil de traitement d'image en se fiant à l'extension. ImageMagick, lui, regarde le contenu réel du fichier, y reconnaît du PostScript et confie le travail à Ghostscript, qui l'exécute comme un programme. Le correctif ferme ce chemin en vérifiant le contenu avant de transmettre le fichier, et en empêchant qu'un nom de fichier manipulé oriente le traitement vers Ghostscript.

La faille a été signalée de manière responsable par une équipe de recherche, et le projet WordPress n'a pas publié de preuve d'exploitation dans la nature au moment de la correction. Cela ne rend pas la mise à jour facultative, cela change simplement le degré d'urgence.

Deux conditions doivent être vraies en même temps

C'est ce qui rend cette faille inhabituelle, et c'est ce que les courriels d'alerte automatiques ne disent jamais.

La première condition est côté serveur. Votre hébergement doit utiliser ImageMagick pour traiter les images, et Ghostscript doit être installé à côté. Beaucoup d'hébergements mutualisés utilisent la bibliothèque GD à la place, et parmi ceux qui utilisent ImageMagick, tous n'ont pas Ghostscript. Si l'une des deux briques manque, ce chemin d'attaque n'existe pas chez vous.

La seconde condition est côté comptes. L'attaquant doit disposer d'un compte capable d'envoyer des fichiers, ce qui correspond aux rôles Auteur, Éditeur et Administrateur. Le rôle Contributeur ne permet pas l'envoi de fichiers et ne suffit donc pas. Sur un site vitrine dont les deux seuls comptes appartiennent au dirigeant et à son prestataire, la surface d'attaque se réduit à une compromission de mot de passe, ce qui nous ramène à un sujet que nous traitons ailleurs, la double authentification.

Beaucoup de sites échouent aux deux tests, et n'étaient donc pas vulnérables. Un site de commerce ou un site à plusieurs rédacteurs, en revanche, coche souvent la seconde condition sans le savoir.

Comment vérifier votre situation en trois minutes

Trois vérifications suffisent, et elles ne demandent aucun outil externe.

1. Dans l'administration, ouvrez Outils, puis Santé du site, puis l'onglet Informations. La section consacrée au traitement des médias indique quelle bibliothèque d'images est active sur votre serveur. Vous y verrez ImageMagick ou GD.
2. Ouvrez la liste des comptes et triez par rôle. Comptez précisément combien de personnes disposent d'un rôle Auteur ou supérieur, et vérifiez que chacune est encore en poste. Un compte d'ancien prestataire resté actif est un sujet à part entière, que nous décrivons dans notre article sur la révocation des accès au départ d'un collaborateur.
3. Regardez la version du cœur affichée en bas du tableau de bord. Si elle est antérieure à celle de votre branche corrigée, la question de la vulnérabilité passe au second plan : votre site accumule surtout un retard de mises à jour.

Si vous cumulez ImageMagick avec Ghostscript et plusieurs comptes de niveau Auteur, traitez la mise à jour comme urgente. Sinon, appliquez-la à votre rythme habituel, sans y consacrer votre soirée.

Ce que la rétroportation jusqu'à la branche 4.7 ne signifie pas

Le correctif a été rétroporté sur toutes les branches encore suivies, jusqu'à la 4.7. C'est une bonne nouvelle pour les sites anciens : vous n'avez pas besoin d'une montée de version majeure pour être corrigé sur ce point précis.

C'est aussi un piège de lecture. Recevoir un correctif de sécurité sur une vieille branche ne veut pas dire que le site est à jour, ni que son socle est sain. Seule la version la plus récente est réellement suivie sur l'ensemble du périmètre. Un site resté sur une branche ancienne traîne en général une version de langage serveur abandonnée, sujet que nous traitons dans notre article sur PHP obsolète sur WordPress, et des extensions qui n'ont plus de mainteneur. La faille du mois n'est alors que le symptôme visible.

Ce que nous faisons pour les sites que nous maintenons

Notre réponse à ce type d'annonce est volontairement ennuyeuse, parce qu'elle est décidée à l'avance. Nous relevons la version de chaque site que nous suivons, nous vérifions la bibliothèque de traitement d'image côté hébergeur, et nous listons les comptes disposant de droits d'envoi. Cette liste nous dit en quelques minutes quels sites passent en priorité et lesquels suivent le cycle normal.

Nous appliquons ensuite la mise à jour sur un environnement de recette avant la production, méthode que nous détaillons dans notre article sur le staging WordPress, et nous disposons d'une sauvegarde stockée ailleurs que sur le serveur d'hébergement, point que nous développons dans la sauvegarde WordPress hors serveur. C'est ce qui permet d'appliquer un correctif un mardi sans se demander comment revenir en arrière si le thème casse.

Ce travail vit dans la maintenance WordPress à 500 HT / an, qui comprend les mises à jour du cœur, du thème et des extensions, les sauvegardes hors du serveur, la supervision et le suivi des annonces de sécurité. Le principe général, celui qui explique pourquoi ce contrat existe, est développé dans notre article sur les failles WordPress et la maintenance. Nous intervenons à distance dans toute la France et en Suisse.

Si vous avez reçu une alerte et que vous ne savez pas si elle vous concerne, envoyez-nous l'adresse de votre site. Nous vous dirons quelle version il fait tourner, quels comptes peuvent envoyer des fichiers, et si la mise à jour relève de l'urgence ou du cycle normal.