mrx-arafat/cve-2026-63030-poc
📖 Lisez d'abord l'analyse technique complète : CVE-2026-63030 : Explication de la RCE WordPress pré-authentification
Ce dépôt contient l'exploit proof-of-concept référencé dans cet article. Commencez par le blog pour comprendre la vulnérabilité, ses limites et le processus de reproduction.
| Aspect | Détails |
|---|---|
| Vulnérabilité | CVE-2026-63030 (confusion de route) + CVE-2026-60137 (injection SQL) |
| Type | Exécution de code à distance pré-authentification |
| Score CVSS | 9.8 (Critique) |
| Versions affectées | WordPress 6.9.0–6.9.4, 7.0.0–7.0.1 |
| Corrigé dans | WordPress 6.9.5, 7.0.2+ |
| Impact | Plus de 500 millions de sites WordPress potentiellement affectés |
| Prérequis | Aucun — fonctionne sur des installations WordPress standard |
Ce dépôt contient :
wordpress-rest-exploit.py — Outil d'exploitation Python en un seul fichier (1 005 lignes, aucune dépendance)README.md — Ce fichier avec l'installation et l'utilisationPOC.md — Guide de reproduction détaillé étape par étape avec des exemples réelsLICENSE — Licence MITAvant d'utiliser cet exploit, comprenez la limitation critique qui rend cette vulnérabilité différente de ce qui a été rapporté :
La chaîne de vulnérabilités est réelle et critique. Cependant :
Pourquoi ? WordPress permet des préfixes de tables de base de données personnalisés. La valeur par défaut est wp_, mais la plupart des sites durcis utilisent bw1w_, wordpress_ ou des chaînes aléatoires. Sans connaître le préfixe, l'extraction des hash échoue silencieusement.
L'article de blog explique :
./wordpress-rest-exploit.py
L'outil vous guidera à travers :
CVE-2026-63030: WordPress REST Batch Route-Confusion SQLi
------------------------------------------------------------
Target URL: https://example.com/
[*] Checking if target is vulnerable to CVE-2026-63030...
[+] WordPress 7.0 detected (AFFECTED VERSION)
[+] VULNERABLE - batch route-confusion behavior confirmed
What would you like to do?
1) Read database fingerprint
2) Extract WordPress user logins and password hashes
3) Execute custom SQL query
4) Deploy plugin webshell (requires admin credentials)
5) Confirm SQL injection with timing payload
6) Exit
Select option [1]:
Ce point est essentiel à comprendre avant d'utiliser l'exploit.
WordPress permet des préfixes de tables personnalisés pour le durcissement de la sécurité. L'outil d'exploitation ne peut pas détecter automatiquement le préfixe.
✅ Default prefix (wp_): Exploitation works
❌ Custom prefix (bw1w_, etc.): Exploitation fails silently
Lorsque l'outil demande le préfixe de table :
Option 1 : Vous connaissez le préfixe
Database table prefix [wp_]: bw1w_
[+] Querying bw1w_users...
[+] Found credentials!
Option 2 : Deviner les préfixes courants
wp_ (défaut)wordpress_bw1w_ (durcissement populaire)wpdb_Option 3 : Accès direct
Si vous avez un accès SSH ou pouvez lire wp-config.php :
$table_prefix = 'bw1w_'; // Found it!
Option 4 : Force brute via SQLi
L'outil peut tenter des préfixes courants via une injection SQL aveugle (lent mais possible).
SLEEP(3)wp_users (ou un préfixe personnalisé)Pour une reproduction détaillée avec de véritables sorties de commandes et des exemples, consultez :
👉 POC.md — Procédure complète en 8 étapes
Ce guide comprend :
Mettez à jour immédiatement (priorité absolue) :
# Update to patched versions
WordPress 7.0.2 or 6.9.5
Si une mise à jour immédiate est impossible :
Bloquez le endpoint batch au niveau du WAF/proxy inverse :
Block: /wp-json/batch/v1
Block: /?rest_route=/batch/v1
Ou désactivez complètement l'API REST (moins idéal) :
// Add to wp-config.php or mu-plugins
add_filter('rest_endpoints_enabled', '__return_false');
Ou exigez une authentification :
add_filter('rest_pre_dispatch', function($response) {
if (strpos($_SERVER['REQUEST_URI'], '/batch/v1') !== false) {
if (!is_user_logged_in()) {
return new WP_Error('rest_batch_unauthenticated', 'Forbidden', ['status' => 401]);
}
}
return $response;
}, 10, 1);
Uniquement pour des tests de sécurité autorisés. À utiliser exclusivement contre des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de test. Aucune garantie n'est fournie et aucune responsabilité n'est acceptée en cas de mauvaise utilisation.
Recherche et développement : Easin Arafat
GitHub : @mrx-arafat
Site web : arafatops.com
Cette preuve de concept démontre la chaîne de vulnérabilités wp2shell de WordPress avec des techniques d'exploitation pratiques, la détection de vulnérabilités et des résultats de tests réels. Commencez par l'article de blog pour comprendre le contexte complet.
Dernière mise à jour : juillet 2026
Licence : MIT
| Constat | Impact |
|---|
| La détection de la vulnérabilité fonctionne parfaitement | Facile d'identifier les sites affectés |
| L'injection SQL est fiable | L'accès à la base de données est garanti (si le préfixe est connu) |
| Le préfixe de table est le goulot d'étranglement | 70 % des sites en production sont protégés |
| La SQLi aveugle est lente | Plus de 30 minutes pour une extraction complète |
| La RCE post-authentification fonctionne parfaitement | Compromission totale du système après authentification |
| RCE pré-authentification non divulguée | Searchlight Cyber n'a pas publié la technique |