> ## Documentation Index
> Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.
# wp2shell (CVE-2026-63030) : exécution de code à distance non authentifiée dans WordPress
> Une confusion de routage dans l'API batch, chaînée à une injection SQL, donne le contrôle du site sans identifiants. Corrigé en 6.9.5 et 7.0.2, déjà exploité.
*Publié le 8 août 2026*
**CVE-2026-63030, « wp2shell », CVSS 9.8.** Aucun compte, aucun mot de passe, aucune interaction : une seule chaîne de requêtes prend le contrôle du site. L'exploitation est confirmée dans la nature et la faille figure au catalogue KEV de la CISA. Si vous êtes en WordPress 6.9.x ou 7.0.x, mettez à jour avant de lire la suite.
## Ce qui est touché
Il s'agit d'une faille du cœur, pas d'une extension. Aucune hygiène de plugins ne vous en protège.
| Branche | Vulnérable | Corrigé |
| ------------- | ------------------------------------------- | --------- |
| WordPress 6.9 | 6.9.0 → 6.9.4 | **6.9.5** |
| WordPress 7.0 | 7.0.0 → 7.0.1 | **7.0.2** |
| WordPress 7.1 | Beta 1 et antérieures | Beta 2 |
| WordPress 6.8 | 6.8.0 → 6.8.5, pour la CVE-2026-60137 seule | 6.8.6 |
Les sites en 6.8.x ne sont pas exposés à la chaîne complète — la faille de l'API batch est apparue en 6.9 — mais ils ont besoin de la 6.8.6 pour la moitié « injection SQL ».
## Comment la chaîne fonctionne
Deux failles, dont aucune ne suffit seule.
**CVE-2026-63030** est un défaut de logique dans le processeur batch de l'API REST, sur `/wp-json/batch/v1`. La validation et l'exécution tournent dans deux boucles distinctes. Quand `wp_parse_url()` échoue sur le chemin d'une sous-requête, l'erreur est ajoutée au tableau de validation mais pas au tableau des correspondances. Les deux tableaux se désalignent, et à partir de là chaque sous-requête suivante est dispatchée vers le mauvais gestionnaire.
Ce désalignement est toute l'astuce : une requête finit exécutée par un gestionnaire qui n'a jamais validé ses paramètres.
**CVE-2026-60137** est une injection SQL dans le paramètre `author__not_in` de `WP_Query`, cotée 5,9 prise isolément — le genre de trouvaille qui dort d'ordinaire dans un backlog.
Chaînées, la confusion de routage livre des paramètres non validés à la requête injectable. Le chemin publié va de là à la création d'un compte administrateur, puis de ce compte à l'exécution de code via l'installateur d'extensions. Contrôle total du site, sans identifiants à aucune étape.
Bonne illustration du fait qu'une faille de sévérité moyenne n'est pas une faille de faible priorité. La CVE-2026-60137 seule vaut 5,9. Associée au bon défaut de routage, elle devient la moitié d'une 9,8.
## Chronologie, et pourquoi elle compte
* **17 juillet 2026** — divulgation publique via un GitHub Security Advisory. Des preuves de concept publiques sont apparues sur GitHub en quelques heures.
* **21 juillet 2026** — la CISA ajoute les deux CVE à son catalogue des vulnérabilités activement exploitées.
* **22 juillet 2026** — publication de l'analyse technique complète de la chaîne.
Une entrée au KEV signifie que l'exploitation a été observée sur des systèmes réels, pas seulement anticipée. L'écart entre divulgation et exploit public fonctionnel s'est compté en heures : cela ne laisse aucune place au « on corrigera au prochain sprint ».
## Mettre à jour
WordPress.org a poussé des mises à jour automatiques forcées sur les installations concernées dont les mises à jour auto étaient actives. Ne supposez pas que cela vous couvre : les sites aux mises à jour auto désactivées, ceux sous gestion de version, et ceux dont les fichiers du cœur ne sont pas inscriptibles n'ont pas été mis à jour.
Vérifiez ce que vous exécutez réellement :
```bash theme={null}
# Depuis la racine du site, avec WP-CLI
wp core version
# Sans WP-CLI, la version se trouve dans ce fichier
grep "wp_version =" wp-includes/version.php
```
Puis mettez à jour :
```bash theme={null}
# Mettre le cœur à jour vers la dernière version de votre branche
wp core update
# Migration du schéma de base, requise après une mise à jour du cœur
wp core update-db
# Contrôler
wp core version
```
Si vous gérez votre site depuis cPanel, WordPress Toolkit et [Softaculous](https://help.onetsolutions.net/fr/web-hosting/softaculous) proposent tous deux la mise à jour du cœur en un clic et la liste des versions par site — le moyen le plus rapide d'auditer plusieurs sites d'un coup.
Faites une sauvegarde avant la mise à jour, pas après. Si la mise à jour se passe mal, vous voulez un point de retour ; s'il s'avère que vous étiez compromis, vous voulez une copie des preuves.
## Vérifier si vous avez été touché
Corriger ferme la porte. Cela ne fait rien contre quelqu'un déjà entré. Trois contrôles, par ordre d'utilité :
**Comptes administrateurs inattendus.** La chaîne publiée en crée un. Passez en revue chaque compte à droits élevés et sa date de création.
```bash theme={null}
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
```
**Requêtes vers l'endpoint batch.** L'endpoint a des usages légitimes : le volume et la source comptent davantage que la simple présence.
```bash theme={null}
# Adaptez le chemin à votre journal d'accès
grep "batch/v1" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
```
**Fichiers modifiés récemment.** Un webshell déposé via l'installateur d'extensions atterrit dans `wp-content`.
```bash theme={null}
# Fichiers PHP modifiés dans les 30 derniers jours, du plus récent au plus ancien
find wp-content -name "*.php" -mtime -30 -printf "%TY-%Tm-%Td %p\n" | sort -r | head -40
```
Comparez cette liste à vos propres déploiements. Un fichier PHP dans `wp-content/uploads` n'est pour ainsi dire jamais légitime.
Si l'un de ces contrôles remonte quelque chose, traitez le site comme compromis : restaurez une sauvegarde antérieure au premier événement suspect, mettez à jour, puis faites tourner tous les mots de passe et clés d'API. Nettoyer fichier par fichier un site compromis en production finit rarement bien — voyez notre [checklist pour durcir WordPress après cet incident](/fr/securiser-wordpress-apres-wp2shell).
## Le point plus large
Les failles du cœur de WordPress de cette gravité sont rares — la surface d'attaque habituellement exploitée, ce sont les extensions et les thèmes. Cette rareté coupe dans les deux sens : parce que le cœur inspire confiance, ses mises à jour sont plus souvent repoussées sur les sites de production « stables », et le site qu'on n'a pas touché depuis un an est précisément celui qui est resté en 6.9.2.
Les mises à jour automatiques des versions mineures du cœur sont actives par défaut pour une raison. Si vous les avez désactivées, c'est l'incident qui devrait vous faire revenir dessus.
Une question sur un site hébergé chez nous ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client.