WordPress : deux failles combinées, une prise de contrôle sans compte ni mot de passe

Deux failles WordPress corrigées le 20 juillet sont exploitées activement moins d'une semaine plus tard. CISA les a ajoutées à son catalogue des vulnérabilités exploitées connues (KEV) le 21 juillet, avec une échéance de correction fixée au 24 pour les agences fédérales américaines. Cette date est déjà passée. Le CERT-FR, de son côté, confirme dans son avis CERTFR-2026-AVI-0904 avoir connaissance d'une preuve de concept publique.

Les chercheurs qui ont documenté la chaîne l'ont surnommée « wp2shell ». Elle a été découverte par Adam Kues, de Searchlight Cyber.

Ce que les deux failles font, l'une avec l'autre

CVE-2026-63030 est une faille de logique dans le traitement par lots de l'API REST de WordPress (/wp-json/batch/v1). Selon l'analyse de Rapid7, la validation des requêtes et leur exécution tournent dans deux boucles séparées ; quand une URL mal formée fait échouer wp_parse_url(), les deux tableaux se désynchronisent et WordPress finit par traiter une requête différente de celle qu'il a validée.

CVE-2026-60137 est une injection SQL dans le paramètre author__not_in de l'API des articles (WP_Query), qui s'interpole directement dans une requête SQL brute quand il est fourni sous forme de chaîne. Seule, elle demande une validation que WordPress applique normalement. Combinée à la désynchronisation de CVE-2026-63030, cette validation saute.

Le résultat : un attaquant non authentifié peut enchaîner les deux failles pour obtenir l'exécution de code sur le serveur. Pas de compte à créer, pas de mot de passe à deviner.

Versions concernées

La chaîne complète (les deux CVE combinées pour l'exécution de code) touche les branches 6.9 et 7.0. La faille d'injection SQL seule remonte plus loin, jusqu'à la branche 6.8.

Pour vérifier votre version, l'administration WordPress l'affiche en bas de la colonne de droite du tableau de bord. En ligne de commande sur le serveur :

wp core version

Ce qui se passe une fois le site compromis

D'après Qualys et SOCRadar, l'exploitation observée dans la nature sert à poser des webshells persistants, installer des extensions malveillantes, extraire les empreintes des mots de passe administrateur pour les casser hors ligne, et exécuter des commandes arbitraires sur le serveur.

Ce qui compte pour une PME dont le site est confié à un prestataire ou géré en interne sans personne dédiée : la mise à jour seule referme la porte, elle ne dit rien de ce qui a pu entrer avant. WordPress applique de son côté la mise à jour automatique forcée sur les installations qui l'ont activée, mais cette automatisation ne prévient pas d'une compromission déjà en place.

Ce qu'il faut faire aujourd'hui

1. Relevez la version exacte du site et comparez-la au tableau ci-dessus.
2. Si vous êtes dans une plage vulnérable, mettez à jour vers 6.8.6, 6.9.5 ou 7.0.2 sans attendre une fenêtre de maintenance : la faille est exploitée depuis au moins une semaine.
3. En attendant la mise à jour, si votre hébergeur ou votre pare-feu applicatif le permet, bloquez l'accès anonyme à /wp-json/batch/v1.
4. Une fois à jour, cherchez des traces : fichiers PHP récents que vous n'avez pas déposés, comptes administrateur inconnus, extensions apparues sans qu'on les ait installées.
5. Si votre site est resté vulnérable plusieurs jours avec un accès public à Internet, ne partez pas du principe qu'il ne s'est rien passé sous prétexte qu'aucun symptôme n'est visible. Un webshell bien posé ne se voit pas depuis l'interface d'administration.

La majorité des sites vitrines de PME tournent sur des offres d'hébergement mutualisé où les mises à jour de cœur WordPress sont automatiques par défaut. Ça ne dispense pas de vérifier : un thème ou une extension qui bloque la mise à jour, un mode de maintenance mal configuré, une automatisation désactivée après un incident passé, et le site reste exposé sans que personne ne le sache.