WordPress Core CVE-2026-60137 + 63030 : SQLi chaînée vers RCE non authentifiée

La très grande majorité des compromissions WordPress passe par un plugin ou un thème tiers. Ce n'est pas le cas ici. Le 21 juillet 2026, la CISA a ajouté au catalogue KEV deux vulnérabilités du cœur de WordPress qui, chaînées, permettent une exécution de code à distance non authentifiée sur une installation par défaut — sans plugin, sans thème particulier, sans compte.

Sur un CMS qui motorise environ 43 % du web, cela place la barre au niveau des incidents les plus graves de son histoire.

Les versions corrigées sont 6.9.5 et 7.0.2. Si tu n'es pas sur l'une des deux, arrête de lire et va mettre à jour.

Les deux CVE

CVE-2026-63030 dispose de données NVD complètes. Pour CVE-2026-60137, NVD n'a pas encore publié de score ni de vecteur au moment de la rédaction — mais la description de 63030 nomme précisément le paramètre concerné, ce qui suffit à comprendre la chaîne.

Détails techniques

CVE-2026-60137 — La SQL injection, seule, est conditionnelle

Description CISA :

WordPress Core contains a SQL injection vulnerability when a plugin or theme passes untrusted input to the parameter. This vulnerability can be chained with CVE-2026-63030 to allow an unauthenticated attacker to gain remote code execution on default WordPress installations.

Le paramètre en question, identifié dans la description de CVE-2026-63030, est author__not_in de WP_Query — l'argument qui permet d'exclure les contenus de certains auteurs d'une requête.

Prise isolément, cette CVE a une portée limitée : il faut qu'un plugin ou un thème transmette une entrée non fiable à author__not_in. C'est un scénario réel mais pas universel. Beaucoup d'équipes auraient légitimement conclu « nous ne sommes probablement pas concernés ».

CVE-2026-63030 — La confusion de routes qui rend la SQLi universelle

Description NVD :

WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the author__not_in WP_Query SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution.

Vecteur : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — réseau, complexité faible, aucune authentification, aucune interaction utilisateur, impact maximal. CWE-436 (Interpretation Conflict).

WordPress expose depuis la version 5.6 un endpoint de traitement par lot, /wp-json/batch/v1, qui permet de soumettre plusieurs requêtes REST dans un seul appel HTTP. Une « confusion de routes » sur cet endpoint signifie que la résolution de route par le mécanisme de batch ne produit pas le même résultat que la même requête envoyée directement.

Concrètement, la conséquence est que le batch permet d'atteindre un gestionnaire interne et de lui transmettre des paramètres qui, par la voie normale, auraient été filtrés, validés ou refusés faute d'authentification. La SQLi de author__not_in devient alors joignable sans qu'aucun plugin ni thème n'ait besoin de coopérer — ce que la description résume par « on default WordPress installations ».

C'est le point qui fait toute la gravité : la CVE-2026-63030 transforme une SQLi conditionnelle en SQLi universelle.

De la SQL injection au RCE

Le catalogue KEV affirme l'aboutissement en exécution de code. Les chemins classiques pour passer d'une SQLi à un RCE sur WordPress sont bien documentés :

• Injection dans la table wp_options — de nombreuses options sont stockées sérialisées et désérialisées à la lecture. Écrire un objet PHP forgé dans une option ouvre la voie à une PHP object injection, exploitable avec une gadget chain présente dans le cœur ou une dépendance
• Création d'un compte administrateur via INSERT dans wp_users et wp_usermeta, puis upload d'un plugin malveillant depuis l'interface d'administration
• Écriture de fichier via INTO OUTFILE si le compte MySQL dispose du privilège FILE

Je ne sais pas laquelle de ces voies l'exploit réel emploie — ni WordPress ni la CISA ne l'ont détaillée. Ça ne change rien à la conduite à tenir.

Produits et versions affectés

Vérifie ta version :

# WP-CLI
wp core version

# Ou dans l'admin : Tableau de bord → Mises à jour

Les branches antérieures (6.8 et avant) ne sont pas nommées dans l'advisory. Si tu es sur une branche non maintenue, tu as un problème plus large que ces deux CVE : passe sur une version supportée.

Exploitation et impact

Pourquoi il faut considérer l'exploitation comme massive

Cette chaîne réunit toutes les conditions d'une exploitation industrialisée :

• Aucune authentification, aucune interaction utilisateur — un simple POST suffit
• Cible triviale à identifier — la version de WordPress est souvent exposée dans le <meta name="generator">, dans les paramètres ?ver= des assets, ou déductible du hash de fichiers statiques
• Installation par défaut suffisante — pas besoin de deviner quel plugin est installé
• Population cible immense — chaque site WordPress non mis à jour est exploitable de façon identique

L'échéance CISA de trois jours (24 juillet pour CVE-2026-63030) indique une exploitation constatée. À l'échelle de WordPress, cela signifie du scan automatisé de masse.

Après la compromission

• Injection de spam SEO et de redirections conditionnelles (le visiteur venant de Google est redirigé, l'administrateur voit un site normal)
• Webshell persistant dans les répertoires de thèmes ou d'uploads
• Exfiltration de la base : comptes utilisateurs, hash de mots de passe, données clients, et pour un site e-commerce, l'historique de commandes
• Comptes administrateurs dormants créés pour un retour ultérieur
• Pivot en hébergement mutualisé vers les autres sites du même compte

Un rappel qui vaut pour tout le monde ici : une compromission WordPress abîme durablement le référencement. Google détecte l'injection, déclasse le site, et parfois l'affiche comme dangereux dans les résultats. Le dommage SEO survit largement au nettoyage technique.

Détection et IOC

Journaux serveur web — l'endpoint batch

C'est le point de contrôle principal. En usage normal, /wp-json/batch/v1 est très peu sollicité : il sert surtout à l'éditeur de blocs Gutenberg et à quelques intégrations. Un volume significatif de requêtes vers cet endpoint est anormal.

# Apache / Nginx — requêtes vers l'endpoint batch
grep -E "POST .*/wp-json/batch/v1" /var/log/nginx/access.log | tail -100

# Croisé avec des motifs d'injection SQL
grep -E "wp-json/batch/v1" /var/log/nginx/access.log | \
  grep -iE "union|select|sleep\(|benchmark\(|author__not_in"

Journaux MySQL

Si tu peux activer le log des requêtes (même temporairement), cherche les signatures d'injection sur les requêtes issues du compte WordPress :

-- MySQL : activer le log des requêtes modifiantes
SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

Motifs à chasser : UNION SELECT sur wp_users, INSERT dans wp_users / wp_usermeta, UPDATE sur wp_options hors opération légitime.

Comptes administrateurs

Le contrôle le plus rapide et le plus révélateur :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Tout compte non reconnu — surtout enregistré après le 17 juillet — doit être traité comme une compromission confirmée.

Fichiers

# Fichiers PHP récents dans uploads (ne devrait jamais rien retourner)
find wp-content/uploads -name "*.php" -o -name "*.phtml" -o -name "*.phar" 2>/dev/null

# Fichiers du cœur modifiés
wp core verify-checksums

wp core verify-checksums compare tes fichiers du cœur aux sommes officielles. C'est un excellent détecteur de backdoor injectée dans le cœur, et il est instantané.

Intégrité des options sérialisées

SELECT option_name, LEFT(option_value, 120) AS extrait
FROM wp_options
WHERE option_value LIKE 'O:%' OR option_value LIKE 'a:%:{%O:%';

Un objet PHP sérialisé (O:) dans une option qui n'en contenait pas est un signal fort de tentative d'object injection.

Mitigation et patch

1. Mettre à jour — immédiatement

wp core update --version=6.9.5
# ou
wp core update --version=7.0.2

Puis vérifie :

wp core version && wp core verify-checksums

Si tu gères une flotte de sites, WP-CLI en boucle sur ton parc est la voie la plus rapide. Les mises à jour automatiques du cœur, si elles sont actives, ont normalement déjà appliqué le correctif — vérifie plutôt que de supposer, elles échouent silencieusement plus souvent qu'on ne le croit (permissions de fichiers, mode maintenance bloqué, WP_AUTO_UPDATE_CORE désactivé).

2. Si tu ne peux pas patcher tout de suite

Bloque l'endpoint batch au niveau du serveur web. C'est une mitigation ciblée qui casse peu de choses (l'éditeur Gutenberg peut perdre quelques optimisations) :

location = /wp-json/batch/v1 {
    deny all;
    return 403;
}

<Location "/wp-json/batch/v1">
    Require all denied
</Location>

C'est une mesure d'attente, pas une solution : la SQLi de author__not_in reste présente et exploitable si un plugin lui transmet une entrée non fiable.

3. Après le patch — traiter l'hypothèse de compromission

Les CVE ont été publiées le 17 juillet et ajoutées au KEV le 21. Si ta mise à jour est postérieure au 20 juillet, mène une chasse :

1. wp core verify-checksums — intégrité du cœur
2. Liste des administrateurs et des comptes créés depuis le 15 juillet
3. Recherche de .php dans wp-content/uploads
4. Revue des wp_options sérialisées inattendues
5. Vérification des tâches planifiées : wp cron event list
6. Rotation des mots de passe administrateurs et des credentials de base de données
7. Google Search Console → section Problèmes de sécurité, puis demande de réexamen après nettoyage

4. Durcissement durable

• Interdire l'exécution de PHP dans wp-content/uploads — neutralise toute une classe d'attaques, indépendamment de ces CVE
• DISALLOW_FILE_EDIT dans wp-config.php pour bloquer l'éditeur de fichiers de l'admin
• Privilèges MySQL minimaux : le compte WordPress n'a pas besoin de FILE, GRANT ni SUPER
• Mises à jour automatiques du cœur activées et surveillées — avec une alerte si elles échouent

Pourquoi surveiller en continu, même le cœur des CMS

Cet épisode brise une intuition confortable : « les CVE WordPress, c'est toujours un plugin obscur, on n'est pas concernés ». Ici, l'installation par défaut suffit, et la chaîne combine une faille jugée conditionnelle avec une autre qui lève la condition. C'est aussi un rappel que le score d'une CVE isolée ne dit rien de sa chaînabilité — CVE-2026-60137 seule ressemblait à un problème de plugin, elle est devenue le maillon d'une RCE universelle.

Avec cveo.tech, inventorie tes sites WordPress avec leur version exacte du cœur et de leurs extensions, et reçois une alerte automatique dès qu'une CVE critique — surtout ajoutée au CISA KEV — les concerne. Sur une population de sites où les bots de scan arrivent en quelques heures, savoir le jour même quelles installations sont exposées fait la différence entre une mise à jour et une réponse à incident.