WordPress a corrigé vendredi, les exploits sont arrivés dimanche

Vendredi, six heures moins le quart du soir

WordPress a publié le 17 juillet 2026 une version de sécurité couvrant deux vulnérabilités du noyau. L'équipe de recherche de Searchlight Cyber, qui a découvert la plus grave des deux, lui a donné le nom wp2shell. Les identifiants suivis sont CVE-2026-63030, une confusion de routes dans le point de terminaison batch de l'API REST combinée à une injection SQL, et CVE-2026-60137, une injection SQL atteignable par le paramètre author__not_in de WP_Query.

À 17h45, heure de l'Est, le jour même du correctif, Rapid7 a publié son analyse et consigné deux choses. Les détails techniques de l'exploit n'avaient pas encore été publiés, et l'éditeur n'avait pas connaissance d'exploitation confirmée publiquement. Si vous avez lu cette évaluation le vendredi, vous aviez toutes les raisons de croire que vous disposiez d'une semaine de travail normale pour planifier la mise à jour.

Ce n'était pas le cas. PatchStack a commencé à signaler l'exploitation des deux CVE peu avant 19h, heure de l'Est, le même soir, environ une heure après l'instantané de Rapid7. Au dimanche 19 juillet, VulnCheck avait vérifié plus de deux douzaines de preuves de concept distinctes visant la faille.

Deux failles, et votre version a deux réponses différentes

La plupart des articles traitent l'affaire comme un événement unique portant un nom unique. Ce sont deux vulnérabilités de portée différente, et cette différence détermine ce que vous avez réellement à faire. Se tromper dans un sens comme dans l'autre coûte un week-end ou laisse un trou ouvert.

CVE-2026-63030, la chaîne d'exécution de code à distance, touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Elle est corrigée en 6.9.5 et 7.0.2, ainsi que dans la ligne bêta 7.1 à partir de la Bêta 2. CVE-2026-60137, l'injection SQL de WP_Query, remonte plus loin. Elle touche 6.8.0 à 6.8.5 en plus des mêmes plages 6.9 et 7.0, et le correctif pour la branche plus ancienne est la 6.8.6.

La conséquence pratique, c'est qu'un site resté en 6.8.x lit les titres consacrés à wp2shell, vérifie s'il se situe dans la plage 6.9 ou 7.0, en conclut qu'il n'est pas concerné et s'arrête là. Ce site n'est pas exposé à la chaîne complète d'exécution de code non authentifié, mais il est exposé à l'injection SQL, et il doit tout de même être mis à niveau en 6.8.6. Les vérifications de version menées face au mauvais CVE sont la manière la plus probable pour une organisation de se tromper cette semaine.

Le filet de sécurité couvre les sites qui comptent le moins

Les mainteneurs de WordPress ont réagi en imposant la mise à niveau aux installations concernées dont les mises à jour automatiques étaient activées. C'est la bonne décision, et elle aura protégé un très grand nombre de sites pendant le week-end sans que personne ait eu à y toucher.

Regardez maintenant les sites qu'elle n'a pas protégés. Les mises à jour automatiques sont coupées volontairement, et les raisons sont toujours les mêmes. Un processus de gestion du changement, une extension cassée par une version mineure précédente, une chaîne de préproduction vers la production, un contrat d'agence qui confie la responsabilité des mises à jour à une personne, un régime de conformité qui interdit toute modification non revue en production. Chacune de ces raisons signale une installation que quelqu'un juge assez importante pour la gérer.

Le filet automatique est donc corrélé à l'inverse de la criticité métier. Le blog de loisir s'est mis à jour tout seul le vendredi soir. Le portail client, le système de réservation et le site qui encaisse les paiements sont restés sur la version vulnérable pendant un week-end au cours duquel le code d'attaque fonctionnel est passé de zéro à plus de deux douzaines. Si votre organisation a désactivé les mises à jour automatiques par souci de maturité, c'est le week-end où cette décision vous a coûté cher.

Ce que mesure vraiment la courbe du week-end

Le chiffre utile ici n'est pas un score CVSS, et les éditeurs ne s'accordent d'ailleurs pas complètement sur la gravité. Rapid7 relève un CVSS de 7.5 pour la chaîne d'exécution de code à distance alors que l'avis correspondant la traite comme critique, et VulnCheck désigne l'injection SQL comme la critique des deux. Discuter du chiffre à inscrire dans le ticket est un mauvais emploi du temps dont vous disposez.

Le chiffre qui compte est l'intervalle entre le correctif et la mise en arme. Ici, il se mesure en heures pour les premiers signalements d'exploitation et en deux jours environ pour une large disponibilité publique d'exploits. C'est le niveau de service réel que votre processus de correctifs doit tenir, et la politique affichée de presque aucune organisation ne le tient. Une fenêtre de remédiation de trente jours, courante dans les référentiels de conformité, n'est pas une politique de correctifs pour une faille de ce type. C'est la description de la durée pendant laquelle vous êtes resté exposé.

Un second détail dans les exploits plus tardifs ferme le repli habituel. VulnCheck rapporte que, dès le dimanche, des implémentations supplémentaires d'exécution de code à distance étaient apparues, contournant entièrement l'authentification administrateur. Les équipes qui comptaient s'appuyer sur des comptes d'administration durcis, des pages de connexion restreintes ou un second facteur sur wp-admin comme mesure compensatoire doivent comprendre que ces mesures ne se trouvent pas sur le chemin de cette attaque.

Quatre choses à faire dès aujourd'hui

Premièrement, inventoriez avant d'appliquer le correctif. Trouvez chaque installation WordPress que votre organisation possède réellement, y compris les microsites marketing, les pages d'atterrissage de campagne, le site du colloque d'il y a deux ans et tout ce qu'a construit une agence depuis partie. L'installation vulnérable n'est presque jamais celle qui figure au registre des actifs. C'est celle dont plus personne ne se rappelait qu'elle servait encore du trafic.

Deuxièmement, vérifiez chacune d'elles face au bon CVE. Tout ce qui tourne en 6.8.x doit être mis à niveau en 6.8.6. Tout ce qui tourne en 6.9.x doit être mis à niveau en 6.9.5. Tout ce qui tourne en 7.0.x doit être mis à niveau en 7.0.2. Ne laissez pas une hypothèse unique de plage de versions couvrir tout le parc.

Troisièmement, traitez toute installation non corrigée qui a fait face à internet pendant le week-end comme potentiellement compromise et non comme simplement vulnérable, et cherchez les preuves au lieu d'en présumer l'absence. Le correctif ferme la porte. Il ne fait pas sortir ceux qui sont déjà à l'intérieur. Quatrièmement, et c'est le point durable, notez le délai de correction réel de votre organisation pour cet événement et comparez-le au chiffre que vous publiez dans votre politique. L'écart entre ces deux valeurs est ce qu'il faut corriger, car la prochaine vulnérabilité du noyau tournera sur la même horloge.

À lire ensuite: Le correctif nginx est là, l'exploit arrive en août  |  ServiceNow a corrigé son cloud d'abord, vous 103 jours plus tard