Détecteur de PoC et validateur sécurisé pour la chaîne de vulnérabilités WP2Shell WordPress : CVE-2026-63030 (confusion REST batch-route) + CVE-2026-60137 (injection SQL author__not_in). Pour tests de sécurité autorisés uniquement.
Couverture CVE : CVE-2026-63030 et CVE-2026-60137
Utilisation prévue : Tests de sécurité autorisés, validation défensive et laboratoires locaux jetables uniquement
WP2Shell est une chaîne de vulnérabilités du noyau WordPress combinant un bug de confusion de route batch de l'API REST sans authentification (CVE-2026-63030) avec une primitive d'injection SQL WP_Query author__not_in (CVE-2026-60137). Ce dépôt fournit un scanner de preuve de concept et un validateur sécurisé en Python afin que les défenseurs puissent identifier les installations WordPress affectées, confirmer le comportement vulnérable dans un laboratoire isolé et vérifier la correction — sans avoir besoin d'extraire des données ou d'obtenir une exécution de code.
Ce projet identifie les installations WordPress et valide les deux primitives de vulnérabilité associées à la chaîne de vulnérabilité du noyau WordPress WP2Shell :
WP_Query::author__not_in, pouvant entraîner une injection SQL lorsque des entrées contrôlées par l'attaquant atteignent le paramètre.Lorsque les deux conditions sont présentes, une requête non authentifiée peut atteindre la construction SQL vulnérable via le point de terminaison batch de l'API REST de WordPress. Les avis publics décrivent l'impact combiné comme pouvant conduire à une exécution de code à distance.
Ce dépôt ne doit être utilisé que sur des systèmes que vous possédez ou pour lesquels vous êtes explicitement autorisé à tester. Préférez un laboratoire Docker ou machine virtuelle isolé lié à 127.0.0.1.
Le fichier source actuel contient des fonctionnalités modifiant l'état, notamment des tentatives d'extraction de données de la base de données, des tentatives d'écriture de fichiers, des workflows d'authentification, la création d'administrateurs, le téléchargement de plugins et l'exécution de commandes.
Les versions affectées de WordPress peuvent perdre l'alignement entre les tableaux internes utilisés pour suivre :
Lorsqu'un membre batch malformé est accepté dans un tableau interne mais pas dans un autre, les requêtes ultérieures peuvent être associées au mauvais gestionnaire. Une requête peut donc être validée comme une route mais exécutée en utilisant le rappel d'une autre route.
Impact sur la sécurité :
author__not_inL'implémentation de WP_Query affectée ne normalise pas systématiquement author__not_in avant de l'utiliser pour construire une condition SQL NOT IN (...).
Le paramètre attend normalement une liste d'ID d'auteurs entiers. Si une chaîne scalaire atteint la construction de requête vulnérable sans la validation de schéma REST prévue, une structure SQL non sécurisée peut survivre dans la requête de base de données.
Impact sur la sécurité :
| Branche WordPress | Affectée | Version corrigée |
|---|---|---|
| 6.8.x | CVE-2026-60137 uniquement : 6.8.0–6.8.5 | 6.8.6 |
| 6.9.x | Les deux problèmes : 6.9.0–6.9.4 | 6.9.5 |
| 7.0.x | Les deux problèmes : 7.0.0–7.0.1 | 7.0.2 |
| 7.1 pré-version | Beta 1 affectée | Beta 2 |
| Antérieure à 6.8 | Non affectée par ces deux CVE | N/A |
WordPress a publié des correctifs le 17 juillet 2026 et a activé les mises à jour automatiques forcées pour les installations affectées en raison de la gravité.
Unauthenticated client | v WordPress REST batch endpoint | v Malformed batch member creates request/handler misalignment | v Later request is validated against one route but dispatched using another route's handler | v Scalar author_exclude reaches WP_Query as author__not_in | v Unsafe value reaches SQL NOT IN (...) construction | v Blind SQL timing or Boolean oracle | v Potential database compromise | v Potential application-level compromise and RCE
Le détecteur doit s'arrêter après avoir confirmé les primitives de confusion de route et d'injection SQL. Il n'est pas nécessaire d'extraire des données ou d'exécuter des commandes pour établir qu'une installation affectée est vulnérable.
---
## Workflow de détection
### Phase 1 — Normaliser la cible
L'outil :
1. Ajoute un schéma `http` ou `https` par défaut s'il manque.
2. Normalise le chemin d'installation de WordPress.
3. Rejette les schémas d'URL non pris en charge et les informations d'identification intégrées.
4. Applique les politiques de redirection, de proxy, de TLS et de timeout.
### Phase 2 — Identifier WordPress
Le scanner vérifie :
- Références `wp-content/`.
- Références `wp-includes/`.
- Métadonnées du générateur WordPress.
- Liens de découverte de l'API REST.
- Structure de l'index REST WordPress.
- L'espace de noms `wp/v2`.
- Empreintes facultatives du flux et de `readme.html`.
### Phase 3 — Déterminer la version
Les preuves de version peuvent provenir de :
- Métadonnées du générateur HTML.
- Métadonnées du générateur de flux.
- Chaînes de requête des ressources principales WordPress.
- En-têtes HTTP du générateur.
- `readme.html`.
- Un fichier local `wp-includes/version.php`.
Les preuves sont notées et conciliées. Les indicateurs de version distante contradictoires réduisent la confiance.
### Phase 4 — Vérifier l'exposition des routes par lots
Le scanner tente de découvrir `/batch/v1` via :```text
/?rest_route=/
/wp-json/
La route peut être adressée en utilisant soit :```text /?rest_route=/batch/v1 /wp-json/batch/v1
### Phase 5 — Sonde de confusion de routage sécurisée
La sonde sécurisée contient :
1. Un chemin interne volontairement malformé.
2. Une requête vers un ID de publication invalide avec un `GET` public imbriqué inoffensif.
3. Une requête `/batch/v1` suivante.
Un serveur vulnérable renvoie une réponse externe `207 Multi-Status` dans laquelle la requête de publication invalide est traitée comme une requête batch imbriquée.
Le détecteur rapporte :```text
route-confusion-observed
when it sees: