Ce que ça change pour une PME

  • Si votre site WordPress a un tableau de bord, allez dans Mises à jour et vérifiez que la version affichée est 7.0.4 (ou le dernier correctif de votre branche si vous êtes resté sur une version plus ancienne).
  • La faille ne s'exploite que si le serveur utilise la bibliothèque Imagick avec Ghostscript pour traiter les images — un réglage d'hébergement que votre agence web ou votre hébergeur peut confirmer en une question.
  • Elle demande un compte Auteur ou supérieur sur le site : passez en revue les comptes utilisateurs et supprimez ceux des anciens prestataires ou employés qui ont encore un accès à la publication.
  • Aucune action côté visiteur du site n'est nécessaire : la faille ne concerne que les comptes ayant le droit de publier du contenu.

WordPress a publié le 12 août la version 7.0.4. Elle corrige une faille d'exécution de code à distance référencée CVE-2026-65640, notée 8,8 sur 10 à l'échelle CVSS. L'équipe de sécurité du projet a rétroporté le correctif jusqu'à la branche 4.7, soit toutes les versions maintenues depuis près de dix ans. C'est le signe qu'elle considère le risque comme sérieux, pas théorique. WordPress.org recommande une mise à jour immédiate.

Ce que permet la faille

Le problème vient d'un décalage entre deux vérifications qui ne se parlent pas. WordPress contrôle l'extension d'un fichier envoyé sur le site ; ImageMagick, la bibliothèque utilisée pour traiter les images, regarde le contenu réel du fichier plutôt que son nom. Un attaquant peut donc déposer un fichier qui porte une extension d'image classique, un .png par exemple, mais qui contient en réalité des instructions PostScript. ImageMagick détecte ce contenu et le transmet à Ghostscript, l'outil qu'il utilise en coulisse pour l'interpréter. Résultat : du code arbitraire s'exécute sur le serveur qui héberge le site.

Cette faille demande deux conditions pour être exploitable. Il faut d'abord que le site utilise la combinaison Imagick et Ghostscript pour le traitement d'images, un choix d'hébergement ou de configuration, pas une fonction activée par défaut sur toutes les installations. Il faut ensuite que l'attaquant dispose d'un compte WordPress avec le rôle Auteur ou un rôle supérieur (Éditeur, Administrateur), c'est-à-dire un compte autorisé à téléverser des fichiers. Un simple visiteur anonyme du site ne peut donc rien faire.

Pourquoi ça concerne quand même une PME

À première vue, exiger un compte Auteur limite le risque : un attaquant extérieur sans identifiants ne peut rien faire directement. Mais la plupart des sites WordPress de PME ont plus de comptes à ce niveau qu'on ne le pense. Un prestataire web qui a gardé un accès après la fin de la mission. Un ancien salarié chargé de la communication. Un stagiaire dont le compte n'a jamais été supprimé. Chacun de ces comptes, s'il est compromis par un mot de passe réutilisé ou deviné, devient une porte d'entrée directe vers l'exécution de code sur le serveur, pas seulement vers la publication d'un article indésirable.

SecurityWeek précise que certaines méthodes de téléversement de fichiers n'appliquent pas toutes les vérifications de contenu attendues, ce qui élargit la surface d'attaque au-delà du seul formulaire de médiathèque classique. WordPress.org n'indique pas avoir constaté d'exploitation de cette faille avant la publication du correctif.

Comment vérifier et corriger

La mise à jour se fait de trois façons, selon la configuration du site :

  • Depuis le tableau de bord d'administration : Mises à jour → Mettre à jour maintenant, si la version 7.0.4 (ou le correctif équivalent de votre branche) n'est pas déjà proposée automatiquement.
  • Par téléchargement manuel depuis wordpress.org, pour les sites dont les mises à jour automatiques sont désactivées.
  • Sans rien faire, si l'hébergeur applique les mises à jour de sécurité mineures automatiquement. C'est le cas par défaut sur la plupart des installations WordPress depuis plusieurs années, sauf si ce réglage a été explicitement désactivé.

Seule la version la plus récente de chaque branche bénéficie d'un support actif. WordPress a aussi publié des correctifs pour les branches 6.9, 6.8 et les versions antérieures jusqu'à 4.7, sous forme de mises à jour ponctuelles (7.0.4, 6.9.7, 6.8.8, etc.). Un site resté sur une ancienne version majeure reste protégé contre cette faille précise s'il a reçu le correctif correspondant à sa branche. Il continue en revanche d'accumuler du retard sur toutes les autres.

La deuxième vérification, moins technique, prend cinq minutes : ouvrir la liste des utilisateurs du site (Utilisateurs dans le tableau de bord), et pour chaque compte avec un rôle Auteur ou supérieur, se demander qui c'est et s'il en a encore besoin. Un site vitrine de PME n'a en général besoin que d'un ou deux comptes de ce niveau. Tout le reste est une dette de sécurité qui traîne depuis la dernière refonte du site.