CVE-2026-60137 : injection SQL dans le noyau de WordPress, déjà répertoriée dans la liste KEV de la CISA
CVE-2026-60137 est une injection SQL dans WordPress Core intégrée au catalogue KEV de la CISA. Que faire dès aujourd'hui pour protéger votre site.
CVE-2026-60137 : injection SQL dans le noyau de WordPress, déjà répertoriée dans la liste KEV de la CISA
En bref
Une vulnérabilité d'injection SQL a été publiée dans le noyau de WordPress, identifiée comme CVE-2026-60137, qui figure déjà dans le catalogue des vulnérabilités activement exploitées (KEV) de la CISA [2]. Elle touche des installations WordPress sur plusieurs branches de version [1]. Si vous gérez un site WordPress, l'action à mener aujourd'hui est simple : vérifier la version de votre noyau et mettre à jour au plus vite.
De quoi s'agit-il et pourquoi est-ce important
CVE-2026-60137 est une faille de sanitisation dans le paramètre author__not_in de WP_Query, un composant interne du noyau de WordPress. Selon la description officielle, le problème permet une injection SQL lorsqu'un plugin ou un thème transmet une entrée non fiable à ce paramètre [1]. Elle est classée avec un score CVSS de 5.9 et une sévérité « moyenne » selon NVD [1], publiée le 17 juillet 2026 [1].
Ce qui augmente l'urgence, ce n'est pas le score isolé, mais deux facteurs : premièrement, la CISA l'a déjà intégrée à son catalogue KEV, ce qui indique une exploitation active constatée dans le monde réel [2]. Deuxièmement, notre radar de renseignement OCIRIA a détecté que cette faille peut être enchaînée avec une autre vulnérabilité, CVE-2026-63030, pour obtenir une exécution de code à distance sans authentification préalable [3]. Autrement dit : même si l'injection SQL seule est déjà sérieuse, le risque réel pour de nombreux sites est plus élevé que ne le suggère le CVSS pris isolément, car un attaquant pourrait parvenir à prendre le contrôle du serveur en combinant les deux failles [3].
Il convient de souligner que ce dernier point — l'enchaînement avec CVE-2026-63030 — est une conclusion de notre propre analyse et non une donnée recensée dans NVD ou dans le registre KEV [3] ; nous le partageons car nous pensons qu'il apporte un contexte utile pour prioriser la réponse.
Qui est concerné
Selon les données officielles, les versions de WordPress suivantes sont concernées : 6.8.x antérieures à 6.8.6, 6.9.x antérieures à 6.9.5 et 7.0.x antérieures à 7.0.2 [1]. Le fournisseur concerné est WordPress [1]. Dans la pratique, cela englobe une part très large de l'écosystème, car WordPress est l'un des systèmes de gestion de contenu les plus utilisés par des entreprises de toutes tailles : boutiques en ligne, sites institutionnels, blogs, intranets et portails de génération de leads.
Le risque se matérialise surtout lorsque des plugins ou des thèmes installés transmettent une saisie utilisateur (par exemple, des paramètres de recherche, des filtres ou des formulaires) directement à la fonction WP_Query concernée, comme le décrit la fiche technique elle-même [1]. Plus une installation compte de plugins tiers, plus la surface d'exposition potentielle est importante.
Comment savoir si vous êtes vulnérable
Il n'est pas nécessaire d'être un profil technique pour effectuer une première vérification :
- Connectez-vous au panneau d'administration de WordPress et vérifiez la version du noyau dans le panneau « Mises à jour ». Si elle est antérieure à 6.8.6, 6.9.5 ou 7.0.2, votre installation entre dans la plage concernée [1].
- Vérifiez quels plugins et thèmes sont actifs, en particulier ceux qui affichent des listes, des recherches ou des filtres de contenu, car ce sont les plus susceptibles d'interagir avec
WP_Query. - Si vous gérez plusieurs sites ou domaines (agences, franchises, groupes d'entreprises), il convient de disposer d'un inventaire à jour indiquant quel CMS et quelle version fonctionne sur chaque actif public. Il est fréquent de découvrir des installations « oubliées » que personne ne met à jour.
- Vérifier la surface réellement exposée à internet — quels domaines, sous-domaines et panneaux d'administration sont visibles depuis l'extérieur — est la première étape avant de décider des priorités de correction.
Comment se protéger
1. Mettez à jour WordPress Core vers la version la plus récente de votre branche (6.8.6, 6.9.5, 7.0.2 ou ultérieures) dès que possible [1].
2. Vérifiez les plugins et thèmes qui interagissent avec des listes ou des requêtes dynamiques, et mettez-les également à jour, car la faille s'active lorsqu'ils transmettent des données non filtrées au noyau [1].
3. Priorisez les sites exposés publiquement et dotés de panneaux d'administration accessibles depuis internet, étant donné que ce CVE est déjà activement exploité selon la CISA [2].
4. Effectuez une sauvegarde avant la mise à jour, comme bonne pratique standard pour tout correctif de sécurité.
5. Si vous gérez plusieurs sites, automatisez le contrôle des versions afin de ne pas dépendre de vérifications manuelles périodiques.
FAQ rapide
S'agit-il d'une vulnérabilité critique ? Selon NVD, la sévérité est « moyenne » avec un CVSS de 5.9 [1]. Cependant, son inclusion dans le catalogue KEV de la CISA indique une exploitation active confirmée [2], et notre analyse interne pointe vers un risque d'exécution de code à distance en combinaison avec une autre faille [3], c'est pourquoi nous recommandons de la traiter en priorité élevée malgré le score modéré.
Cela affecte-t-il tous les sites WordPress ? Uniquement ceux qui font tourner des versions comprises dans les plages indiquées (6.8.x antérieures à 6.8.6, 6.9.x antérieures à 6.9.5, 7.0.x antérieures à 7.0.2) [1]. La mise à jour du noyau résout le problème.
Suffit-il de mettre à jour le noyau ? C'est l'étape essentielle, mais il convient également de vérifier les plugins et thèmes actifs, car ce sont eux qui exposent la voie d'attaque en transmettant des données non validées au composant concerné [1].
Sources
- [1] https://nvd.nist.gov/vuln/detail/CVE-2026-60137
- [2] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json