WordPress 7.0.2 corrige une faille RCE critique exploitable sans connexion

WordPress a publié le 17 juillet 2026 une mise à jour de sécurité urgente pour corriger deux vulnérabilités dans le cœur de son système de gestion de contenu. La plus grave peut permettre à un attaquant d’exécuter du code à distance sans disposer d’un compte sur le site ni provoquer d’action de la part d’un administrateur.

La version WordPress 7.0.2 ainsi que plusieurs correctifs destinés aux branches antérieures ont été distribués. Signe du niveau d’urgence, WordPress.org a également activé des mises à jour forcées par l’intermédiaire de son système d’actualisation automatique. Une mesure exceptionnelle qui devrait protéger une grande partie des installations, mais qui ne dispense pas les responsables de sites de contrôler la version réellement installée.

Pourquoi WordPress a déclenché des mises à jour forcées

Les failles concernent directement le cœur de WordPress et non une extension ou un thème particulier. Selon les chercheurs de Searchlight Cyber, l’attaque critique, baptisée « wp2shell », peut viser une installation standard de WordPress sans extension vulnérable et sans authentification préalable.

WordPress.org classe les deux problèmes corrigés comme une vulnérabilité critique et une vulnérabilité de gravité élevée. Leur combinaison peut permettre de passer d’une manipulation de requête en base de données à une exécution de code à distance, c’est-à-dire à l’exécution d’instructions malveillantes sur le serveur qui héberge le site.

C’est cette possibilité de compromettre un site sans compte utilisateur ni interaction de l’administrateur qui explique le recours aux mises à jour forcées. Les sites compatibles avec les actualisations automatiques en arrière-plan doivent normalement recevoir le correctif, même si leur propriétaire ne lance pas lui-même la procédure depuis le tableau de bord.

Deux vulnérabilités pouvant être combinées

La première vulnérabilité, référencée CVE-2026-60137, est une injection SQL affectant WordPress à partir de la version 6.8. Une entrée spécialement conçue peut altérer la manière dont une requête est transmise à la base de données.

La seconde, CVE-2026-63030, touche les versions 6.9 et ultérieures. Elle repose sur une confusion de route au sein du mécanisme de traitement groupé de l’API REST. Associée à la première faille, elle peut conduire à une exécution de code à distance sans authentification lorsqu’aucun cache objet persistant n’est utilisé.

La distinction est importante : WordPress 6.8 est concerné par l’injection SQL, mais pas par la chaîne complète permettant l’exécution de code à distance. Les versions 6.9 et 7.0 sont, en revanche, touchées par les deux vulnérabilités.

Quelles versions de WordPress faut-il installer ?

Le correctif dépend de la branche actuellement utilisée :

• WordPress 7.0 : mise à jour vers WordPress 7.0.2 ;
• WordPress 6.9 : mise à jour vers WordPress 6.9.5 ;
• WordPress 6.8 : mise à jour vers WordPress 6.8.6 ;
• WordPress 7.1 en version bêta : installation de WordPress 7.1 beta2.

WordPress.org précise que les versions antérieures à WordPress 6.8 ne sont pas affectées par ces deux vulnérabilités. Cela ne signifie toutefois pas qu’une ancienne installation est sûre : les branches obsolètes peuvent rester exposées à d’autres failles qui ne sont plus systématiquement corrigées.

Pourquoi il faut vérifier la mise à jour manuellement

Une mise à jour automatique forcée ne garantit pas que chaque installation a effectivement été corrigée. Le processus peut échouer en raison de droits d’écriture insuffisants, d’une configuration particulière du serveur, d’un espace de stockage saturé ou d’une politique de maintenance désactivant les mises à jour automatiques.

Les plateformes gérant plusieurs sites doivent aussi contrôler les environnements de préproduction, les sous-domaines, les sites archivés et les anciennes installations qui restent accessibles publiquement. Ces instances secondaires sont parfois oubliées alors qu’elles peuvent offrir un point d’entrée vers le même serveur ou la même infrastructure.

La version utilisée peut être vérifiée depuis la rubrique « Mises à jour » du tableau de bord WordPress. Pour un parc important, un outil de gestion centralisée ou une commande exécutée sur chaque serveur permet de confirmer plus rapidement que toutes les installations ont reçu le correctif adapté.

Cloudflare ajoute une protection temporaire à son WAF

Cloudflare a déployé le 17 juillet 2026 deux nouvelles règles pour son pare-feu applicatif, ou WAF. Elles visent les requêtes associées à l’injection SQL et à la tentative d’exécution de code à distance.

Les clients de l’offre gratuite sont protégés par le jeu de règles gratuit lorsque le trafic de leur site passe bien par le réseau Cloudflare. Les clients Pro, Business et Enterprise doivent vérifier que les règles gérées de Cloudflare sont activées et qu’aucune configuration personnalisée ne remplace le blocage par une simple journalisation.

Cette protection ne corrige cependant pas WordPress. Elle cherche à bloquer certaines requêtes avant qu’elles n’atteignent le site, mais son efficacité dépend de la configuration du domaine et des règles appliquées. Un environnement non relié à Cloudflare ou une adresse permettant de contourner le proxy reste potentiellement exposé.

Les contrôles à effectuer maintenant

1. Vérifier la version de WordPress installée sur chaque site et environnement accessible.
2. Installer immédiatement WordPress 7.0.2, 6.9.5 ou 6.8.6 selon la branche utilisée.
3. Tester les principales fonctionnalités du site après la mise à jour.
4. Examiner les journaux du serveur, du CDN ou du WAF à la recherche de requêtes inhabituelles.
5. Contrôler que les sauvegardes récentes sont disponibles et réellement restaurables.

Les sources officielles ne signalent pas, au moment de leur publication, de campagne globale d’exploitation active. L’absence de statistique publique ne doit toutefois pas être interprétée comme une absence de risque. Les détails techniques d’une vulnérabilité critique peuvent être analysés rapidement après la diffusion d’un correctif, ce qui réduit le délai dont disposent les administrateurs pour sécuriser les installations encore vulnérables.

Sources principales

• WordPress.org, annonce officielle de WordPress 7.0.2
• Cloudflare, protections WAF contre les vulnérabilités WordPress

Crédit image : WordPress.org