WordPress a déclenché des mises à jour automatiques forcées après la découverte d’une chaîne de vulnérabilités permettant à un attaquant non authentifié d’exécuter du code sur certains sites. Le problème ne vient ni d’un plugin ni d’un thème tiers, mais de fonctions intégrées au cœur du CMS.
Deux vulnérabilités combinées
WordPress a publié le 17 juillet les versions 7.0.2 et 6.9.5 afin de corriger deux failles de sécurité, dont une vulnérabilité critique référencée CVE-2026-63030. L’éditeur recommande une installation immédiate des correctifs et a activé les mises à jour automatiques forcées sur les versions concernées, une mesure réservée aux problèmes jugés particulièrement graves.
Surnommée « wp2shell », la chaîne d’exploitation repose sur deux faiblesses distinctes. La première provoque une confusion dans le traitement des routes de l’API REST utilisées pour regrouper plusieurs requêtes. La seconde, identifiée sous la référence CVE-2026-60137, permet d’injecter des instructions dans une requête SQL générée par la classe WP_Query.
L’association des deux vulnérabilités peut conduire à une exécution de code à distance. Un attaquant peut ainsi agir sur le serveur sans disposer au préalable d’un compte WordPress ni demander une action à l’utilisateur. WPScan lui attribue un score CVSS de 9,8 sur 10. Le NIST n’a pas encore publié sa propre évaluation, tandis que la CISA retient pour l’instant un score de 7,5.
Le cœur de WordPress directement concerné
La faille se distingue des nombreuses alertes qui touchent habituellement l’écosystème WordPress. Elle ne dépend pas d’une extension abandonnée ou mal entretenue, mais de composants natifs du CMS, notamment son API REST et son mécanisme de requêtes vers la base de données.
Les versions 6.9 antérieures à 6.9.5 et les versions 7.0 antérieures à 7.0.2 sont vulnérables à l’ensemble de la chaîne. WordPress 6.8 est seulement touché par la faille d’injection SQL et doit être mis à jour vers la version 6.8.6. Les branches antérieures à WordPress 6.8 ne sont pas concernées, selon l’éditeur.
Les correctifs modifient trois fichiers du cœur de WordPress liés au serveur REST, au traitement de l’API et à WP_Query. Cette intervention ciblée confirme que le problème réside dans la manière dont certaines requêtes sont interprétées et transmises entre ces différents composants.
Cloudflare apporte toutefois une précision sur les conditions d’exploitation. Selon l’entreprise, l’exécution de code sans authentification concerne les installations WordPress 6.9 et suivantes qui n’utilisent pas de cache d’objets persistant. L’acteur a déployé des règles de protection sur son pare-feu applicatif, tout en invitant ses clients à vérifier l’installation effective des versions corrigées.
Une mise à jour automatique à contrôler
L’activation d’une mise à jour forcée réduit la période pendant laquelle les sites restent exposés, mais elle ne garantit pas que chaque installation a bien reçu le correctif. Les mises à jour automatiques peuvent échouer à cause de droits insuffisants sur les fichiers, d’une configuration particulière, d’un hébergement ancien ou d’un mécanisme volontairement désactivé.
Les administrateurs doivent donc contrôler la version utilisée depuis le tableau de bord WordPress. Les installations sous WordPress 7.0 doivent être passées en 7.0.2, celles restées sur la branche 6.9 en 6.9.5 et celles utilisant WordPress 6.8 en 6.8.6. Une sauvegarde du site et de sa base de données reste recommandée avant une intervention manuelle.
Aucune campagne d’exploitation massive n’était confirmée dans l’évaluation publiée par la CISA le 17 juillet. L’agence considérait néanmoins la faille comme automatisable et susceptible d’avoir un impact technique total. La diffusion publique d’informations détaillées et d’un code de démonstration réduit désormais l’intérêt d’attendre avant de vérifier les installations.
