Une requête POST suffit à compromettre un site WordPress par défaut. Patchez vers la 7.0.2 sans attendre.

Le 17 juillet, WordPress a publié la version 7.0.2, et ce n'était pas une mise à jour mineure ordinaire. Elle corrige une chaîne que les chercheurs ont nommée wp2shell : deux failles qui, combinées, permettent à un attaquant anonyme d'exécuter du code sur une installation WordPress par défaut. Pas de connexion requise. Pas de plugin vulnérable. Pas de thème exotique. Une seule requête POST craftée vers l'API REST, et le serveur peut se retrouver avec un nouveau compte administrateur et un shell répondant aux commandes.
La chaîne repose sur deux CVE. CVE-2026-63030 est une confusion route/handler dans l'endpoint batch de l'API REST, jugée critique, introduite dans la version 6.9. CVE-2026-60137 est une injection SQL dans la gestion de author__not_in par WP_Query, jugée haute, et remonte jusqu'à la version 6.8. Séparément, chacune est un casse-tête. Combinées, la confusion de l'endpoint batch délie la validation de l'exécution et envoie des données non validées directement dans l'injection SQL — résultat : une exécution de code à distance avant authentification. WordPress a activé les mises à jour automatiques forcées pour les sites concernés, ce qui indique clairement comment l'équipe core a évalué le risque. Patchstack indique observer déjà des tentatives d'exploitation dans ses journaux.
Voici la carte des versions. La chaîne RCE complète touche les versions 6.9.0 à 7.0.1. La branche 6.8 ne porte que l'injection SQL, pas la confusion de route qui la rend accessible sans authentification. Les correctifs ont atterri dans les versions 6.8.6, 6.9.5 et 7.0.2, ainsi que dans une bêta 7.1 beta2 pour ceux qui testent la prochaine branche. La confusion de route a été signalée par Adam Kues chez Assetnote, la division recherche de Searchlight Cyber, via le programme HackerOne de WordPress. L'injection SQL a été signalée séparément par TF1T, dtro et haongo.
Pourquoi cette faille est pire que le CVE WordPress habituel
La plupart des vulnérabilités WordPress se trouvent dans les plugins. On peut les auditer, les verrouiller ou les supprimer. Celle-ci se trouve dans le core, sur une installation par défaut, accessible avant authentification. Cette combinaison est rare, et c'est exactement le profil que les attaquants automatisent en premier. Une faille core pre-auth sur la plateforme qui fait tourner une bonne partie du web, c'est un événement de scan massif, pas une attaque ciblée. Des scripts de preuve de concept publics sont apparus un ou deux jours après la divulgation, et les mises à jour forcées ne touchent que les sites avec la mise à jour automatique activée qui contactent effectivement les serveurs. Beaucoup ne le font pas.
Il y a un détail opérationnel qui mérite d'être souligné. Les rapports sur la faille indiquent que le chemin RCE est le plus facilement accessible quand un site ne dispose pas d'un cache d'objets persistant — ce qui est la configuration par défaut pour beaucoup de petites et moyennes installations. Ainsi, les sites les moins susceptibles d'avoir une configuration renforcée sont ceux les plus exposés. C'est cohérent avec ce que nous observons lors des missions de pentest pour des studios de gaming : le vrai risque se trouve généralement dans la configuration par défaut banale, pas dans le cas limite exotique sur lequel tout le monde passe son temps.
Ce que vous devez faire cette semaine
Premièrement, patcher. Si vous faites tourner WordPress 6.8 à 7.0.1 quelque part, passez à la 7.0.2 ou au backport correspondant 6.9.5 ou 6.8.6 dès maintenant, pas à la prochaine fenêtre de maintenance. Vérifiez ensuite que la mise à jour a bien été appliquée. Les mises à jour automatiques forcées peuvent échouer silencieusement derrière un reverse proxy ou sur un système de fichiers verrouillé — vérifiez la version rapportée plutôt que de faire confiance au mécanisme.
Deuxièmement, supposez que la période entre la sortie de la 6.9 et le 17 juillet était une fenêtre ouverte, et cherchez des signes que quelqu'un en a profité. Vérifiez les comptes administrateurs que vous ne reconnaissez pas, les fichiers inattendus dans wp-content/plugins/, et les connexions sortantes depuis l'hébergeur web que vous ne pouvez pas expliquer. Un patch propre n'annule pas une compromission déjà survenue, et cette faille laisse à l'attaquant exactement le type d'accès persistant qui survit à une mise à jour.
Troisièmement, mettez un contrôle devant l'application, pas seulement à l'intérieur. Cloudflare a déployé une règle WAF d'urgence le jour de la divulgation. Quand nous configurons Cloudflare pour des clients ayant besoin d'une protection DDoS et d'un WAF, une règle managée pour un nouveau CVE core comme celui-ci offre des heures ou des jours de couverture pendant qu'un patch se déploie sur un parc de sites. Avec les plateformes de voyage sur lesquelles nous avons travaillé, cette fenêtre de patch virtuel fait souvent la différence entre réagir en minutes et réagir après coup.
Pour les équipes qui développent en PHP plus largement, la vraie leçon concerne les frontières de confiance. Cette chaîne a fonctionné parce qu'une couche de validation et une couche d'exécution ne s'accordaient pas sur le contenu de la requête. Nous voyons la même classe de bug dans des applications custom tout le temps : une entrée est vérifiée à un endroit et consommée à un autre, et les deux divergent jusqu'à ce qu'un attaquant glisse quelque chose entre eux. Dans notre travail sur PHP et Docker, l'habitude qui permet de le détecter est de traiter chaque requête comme hostile jusqu'à ce que la couche exacte qui exécute la requête l'ait re-validée. Une validation qui se déroule trois fonctions avant la base de données n'est pas une validation sur laquelle vous pouvez compter.
Nous effectuons ce type d'audit pre-auth pour des clients enterprise avec de véritables enjeux de conformité, et le background de l'équipe consiste à trouver la requête qui ne devrait pas fonctionner mais qui fonctionne. Si « nous avons patché, mais nous ne sommes pas certains que rien n'est passé d'abord » vous semble familier, parlons-en.