L’essentiel à retenir ℹ️
WordPress 7.0.4, publié le 12 août 2026, referme une exécution de code à distance (CVE-2026-65640, CVSS 8,8) présente dans le cœur depuis la 4.7. Deux conditions doivent être réunies : votre serveur traite les images avec Imagick et Ghostscript, et quelqu’un dispose d’un compte Auteur, Éditeur ou Administrateur capable d’envoyer des fichiers. La première se vérifie dans Outils, Santé du site, section Gestion des médias. Le correctif étant rétroporté jusqu’à la branche 4.7, il existe pour votre version quelle qu’elle soit. Mettez à jour, puis faites le ménage dans les comptes à privilèges.
WordPress a publié le 12 août 2026 une version 7.0.4 estampillée sécurité. Elle referme une faille qui permet à un simple compte Auteur d’exécuter du code sur votre serveur, en uploadant une image piégée. Score CVSS de 8,8, référence CVE-2026-65640. La faille a été signalée par l’équipe de pwn.ai, déjà à l’origine du signalement du XSS corrigé dans la 7.0.3.
Avant de paniquer, une bonne nouvelle : deux conditions doivent être réunies en même temps pour que votre site soit réellement exploitable, et beaucoup de sites n’en remplissent qu’une. Je vous montre le mécanisme, comment vérifier en trente secondes si vous êtes concerné, et quoi faire selon votre configuration.
La faille en clair : un PNG qui n’en est pas un
Le mécanisme est presque élégant, et il repose sur un malentendu entre deux logiciels.
WordPress, quand vous envoyez un fichier dans la médiathèque, vérifie son extension. Un fichier qui se termine par .png, c’est une image, il passe. ImageMagick, la bibliothèque de traitement d’images qui prend le relais derrière, ne raisonne pas du tout comme ça : elle identifie un fichier par son contenu réel, pas par son nom.
Un attaquant fabrique donc un fichier nommé photo.png qui contient en réalité du PostScript, un langage de description de page qui est aussi, techniquement, un langage de programmation. Sur certaines voies d’envoi, WordPress voit un PNG et le laisse passer sans regarder ce qu’il contient. ImageMagick l’ouvre, reconnaît du PostScript, et fait ce qu’elle fait toujours dans ce cas : elle délègue le travail à Ghostscript. Et Ghostscript, lui, ne traite pas ce fichier comme une image. Il l’exécute comme un programme.
Le détail qui pique : ce trou concerne les versions 4.7.0 à 7.0.3. WordPress 4.7 date de décembre 2016. Cette faille traînait donc dans le cœur depuis bientôt dix ans.
La médiathèque n’était pas la porte d’entrée
Ce point a été peu repris ailleurs : l’écran d’envoi classique de la médiathèque inspecte le contenu du fichier et bloque le faux PNG. Deux autres chemins d’écriture sautent ce contrôle. La méthode wp.uploadFile de XML-RPC, active par défaut, et la routine qui extrait la pochette d’un fichier MP3. Toutes deux écrivent le fichier via wp_upload_bits(), sans regarder ce qu’il contient. C’est par là que le PostScript déguisé atteignait ImageMagick.
Le correctif de la 7.0.4 ajoute une inspection du contenu avant tout passage par ImageMagick. Sont désormais refusés les signatures PostScript et EPS, les faux PDF sans en-tête %PDF-, les archives compressées qu’ImageMagick sait décompresser toute seule, et les préfixes de format du type EPS:photo.png.
Les deux conditions pour être vraiment vulnérable
Condition 1 : votre serveur utilise Imagick et Ghostscript
C’est le filtre le plus sélectif. Beaucoup d’hébergements mutualisés traitent les images avec GD, l’autre bibliothèque supportée par WordPress, et pas avec Imagick. Et même quand Imagick est présente, Ghostscript ne l’est pas toujours. Sans les deux, la chaîne d’attaque ne se déclenche pas.
Condition 2 : quelqu’un possède un compte capable d’uploader
La faille est authentifiée. Il faut un compte disposant de la capacité upload_files, ce qui correspond par défaut aux rôles Auteur, Éditeur et Administrateur. Le rôle Contributeur ne suffit pas, puisqu’il ne peut pas envoyer de fichiers dans la médiathèque.
Et c’est là que le niveau de risque change complètement selon votre site. Un blog personnel où vous êtes le seul administrateur ne risque pratiquement rien : l’attaquant devrait d’abord obtenir vos identifiants, et s’il les a, il n’a pas besoin de cette faille. En revanche, si vous gérez un site multi-auteurs, un site membres avec des rédacteurs externes, ou un site client d’agence avec des comptes Auteur distribués à l’équipe, la surface d’attaque devient sérieuse. Moins de sites sont concernés que par le XSS de la 7.0.3, mais ceux qui le sont le sont bien davantage.
Vérifier en trente secondes si vous êtes concerné
Pas besoin d’accès SSH ni de contacter votre hébergeur. WordPress affiche l’information tout seul.
- Dans l’administration, allez dans Outils, puis Santé du site.
- Ouvrez l’onglet Informations.
- Dépliez la section Gestion des médias.
- Cherchez les lignes ImageMagick et Ghostscript. Si les deux affichent un numéro de version, votre serveur remplit la première condition.
Ensuite, faites le tour de vos comptes dans Comptes, et filtrez sur les rôles Auteur, Éditeur et Administrateur. Vous allez probablement y trouver deux ou trois comptes oubliés d’anciens contributeurs, d’un prestataire parti depuis longtemps ou d’un plugin qui a créé son propre utilisateur. C’est le genre de ménage qui sert bien au-delà de cette faille.
Mettre à jour, et rectifier une idée fausse au passage
La 7.0.4 est une version de sécurité, donc rétroportée sur toutes les branches jusqu’à la 4.7. Si votre site tourne en 6.9 ou en 6.4 pour une raison de compatibilité, vous avez quand même un correctif qui vous attend. Le correctif est également intégré à la Release Candidate 3 de WordPress 7.1, sortie le même jour, et donc à la 7.1 finale attendue le 19 août 2026.
Soyons clairs sur un point que j’ai vu passer de travers ailleurs : il ne s’agit pas d’une mise à jour forcée. WordPress indique que les sites qui acceptent les mises à jour automatiques en arrière-plan vont se mettre à jour progressivement. Ce n’est pas la même chose qu’un déploiement imposé à tous, et ça veut dire qu’un site où ces mises à jour ont été désactivées, ce qui est fréquent chez les agences, restera vulnérable jusqu’à ce que quelqu’un clique.
La marche à suivre tient en trois gestes. Faites une sauvegarde, ne serait-ce que par habitude. Allez dans Tableau de bord, puis Mises à jour, et lancez la mise à jour. Vérifiez ensuite le numéro de version affiché en bas à droite de l’admin. Une version mineure de WordPress ne casse quasiment jamais rien, c’est tout l’intérêt de cette politique de versionnage.
Si la mise à jour doit attendre une fenêtre de maintenance, réduisez la surface d’attaque entre-temps. Coupez XML-RPC si aucun service externe n’en dépend, avec le filtre xmlrpc_enabled ou une règle serveur. Rétrogradez aussi en Contributeur les comptes Auteur qui ne publient plus rien. Ce sont des mesures d’appoint, pas un correctif.
Si vous administrez plusieurs sites, c’est exactement le scénario où un outil de gestion centralisée fait gagner une heure. J’en avais détaillé un dans mon article sur MainWP pour gérer plusieurs sites WordPress.
Ce que je ferais à votre place
Mettez à jour aujourd’hui, quelle que soit votre configuration. Même si votre hébergeur utilise GD et que vous êtes seul sur le site, une version mineure de sécurité s’applique sans réfléchir : le rapport bénéfice-risque n’a jamais été aussi favorable côté WordPress.
Ensuite, activez les mises à jour automatiques des versions mineures si ce n’est pas déjà fait. C’est la troisième version de sécurité du cœur en trois semaines, après la 7.0.2 qui corrigeait la chaîne d’exploitation wp2shell et la 7.0.3 qui refermait un XSS sur l’écran de connexion. Le rythme ne va pas ralentir, et cliquer manuellement à chaque fois finit toujours par produire un oubli.
Et si vous ne devez retenir qu’une chose au-delà du correctif : allez regarder qui a un compte Auteur ou plus sur vos sites. Cette faille sera bouchée dans dix minutes, mais les comptes fantômes à privilèges élevés, eux, resteront jusqu’à ce que vous les supprimiez. Ce sont eux qui transforment la prochaine faille authentifiée en incident réel.
Profitez-en pour activer la double authentification sur les comptes qui restent. Un mot de passe réutilisé sur un compte Auteur suffit à donner l’accès que cette faille réclame. Dix minutes de ménage aujourd’hui évitent une restauration de sauvegarde dans six mois.
Foire aux questions
Toutes les versions de 4.7.0 à 7.0.3, soit près de dix ans de sorties. Le correctif a été rétroporté sur toutes les branches jusqu’à la 4.7, vous avez donc une mise à jour disponible même sur une vieille installation.
Allez dans Outils, Santé du site, onglet Informations, puis dépliez la section Gestion des médias. Si les lignes ImageMagick et Ghostscript affichent toutes les deux un numéro de version, votre serveur remplit la première condition.
Non. La chaîne d’attaque passe par ImageMagick puis Ghostscript, elle ne se déclenche pas avec GD seul. Mettez quand même à jour, une version mineure de sécurité ne coûte rien à appliquer.
Non, le rôle Contributeur ne dispose pas de la capacité upload_files et ne peut rien envoyer dans la médiathèque. Il faut au minimum un compte Auteur.
Les sites qui acceptent les mises à jour en arrière-plan la reçoivent progressivement, mais ce n’est pas un déploiement imposé à tous. Si ces mises à jour sont désactivées, passez par Tableau de bord puis Mises à jour.
Coupez XML-RPC si aucun service externe n’en dépend et rétrogradez les comptes Auteur inactifs en Contributeur. Ces mesures réduisent la surface d’attaque en attendant, elles ne remplacent pas le correctif.
Aucune exploitation n’a été confirmée au moment de la publication du correctif. La divulgation responsable par pwn.ai a laissé le temps de corriger le cœur avant toute diffusion publique.
