Une chaîne de vulnérabilités du cœur de WordPress permet l’exécution de code à distance sans authentification

Des chercheurs en sécurité ont révélé deux vulnérabilités du cœur de WordPress pouvant être chaînées pour exécuter du code sans authentification. Ces failles affectent les installations de base, ce qui signifie que les sites n’utilisant aucun plugin tiers peuvent également être exposés.

Les vulnérabilités sont référencées sous les identifiants CVE-2026-63030 et CVE-2026-60137. La première concerne une confusion dans la route de traitement par lots de l’API REST de WordPress, tandis que la seconde est une injection SQL affectant le paramètre author__not_in utilisé par WP_Query. Combinées, ces failles permettent à un attaquant d’envoyer une requête anonyme qui atteint la requête de base de données vulnérable et peut potentiellement conduire à une exécution de code à distance.

Versions concernées

• WordPress 6.8.0 à 6.8.5 : affecté par l’injection SQL ; corrigé dans la version 6.8.6.
• WordPress 6.9.0 à 6.9.4 : affecté par la chaîne d’attaque complète ; corrigé dans la version 6.9.5.
• WordPress 7.0.0 et 7.0.1 : affectés par la chaîne complète ; corrigés dans la version 7.0.2.
• WordPress 7.1 bêta 2 inclut les deux correctifs.

Le chercheur Adam Kues, d’Assetnote, a signalé la faille de l’API REST via le programme HackerOne de WordPress. Des chercheurs distincts ont signalé l’injection SQL. Des détails techniques ainsi qu’une preuve de concept fonctionnelle ont depuis été publiés, ce qui accroît la probabilité que des attaquants tentent de reproduire l’exploit.

WordPress classe la vulnérabilité chaînée comme critique, bien que son score CVE associé soit de 7,5. L’injection SQL seule a reçu un niveau de gravité critique. Aucune exploitation confirmée n’avait été signalée au 18 juillet, et le problème ne figurait pas à cette date dans le catalogue des vulnérabilités exploitées connues de la CISA.

Mesures recommandées

Les administrateurs doivent vérifier la version installée et effectuer dès que possible la mise à jour vers une version corrigée, plutôt que de s’en remettre aux mises à jour automatiques. Le chemin d’exécution de code nécessiterait apparemment l’absence d’un cache d’objets persistant, mais Redis ou Memcached ne doivent pas être considérés comme un substitut à l’application du correctif.

En attendant l’installation des mises à jour, les organisations peuvent envisager de bloquer l’accès anonyme à /wp-json/batch/v1 ainsi qu’au chemin équivalent rest_route=/batch/v1 au niveau d’un pare-feu applicatif. La désactivation de l’accès non authentifié à l’API REST ou l’utilisation d’un filtre temporaire pour rejeter les requêtes par lots anonymes constituent d’autres options, bien que ces mesures puissent perturber les intégrations légitimes et n’éliminent pas l’injection SQL sous-jacente.