wp2shell

💙 Soutenez le projet

Si vous appréciez mon travail, envisagez de soutenir le projet via USDT (TRC20) : TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN

Chaîne RCE pré-authentification du cœur de WordPress

wp2shell est une preuve de concept de recherche en sécurité démontrant une chaîne de vulnérabilités pré-authentification dans le cœur de WordPress combinant :

CVE-2026-63030 — Confusion de route Batch de l'API REST
CVE-2026-60137 — Injection SQL dans WP_Query

La chaîne démontre comment ces vulnérabilités peuvent être combinées pour passer d'une requête non authentifiée à l'API REST à une injection SQL, une élévation de privilèges, la création d'un compte administrateur et, finalement, une exécution de code à distance authentifiée.

[!WARNING]

Recherche en sécurité autorisée uniquement

Ce projet est destiné à :

La recherche de vulnérabilités

La validation défensive

Le PoC est implémenté comme un outil de recherche Python et utilise la bibliothèque standard de Python sans nécessiter de packages Python tiers. --- # Chaîne de vulnérabilités Le projet combine deux vulnérabilités de WordPress Core.```text Unauthenticated Request | v +----------------------+ | CVE-2026-63030 | | REST Batch Route | | Confusion | +----------+-----------+ | v Validation Confusion | v +----------------------+ | CVE-2026-60137 | | WP_Query SQLi | +----------+-----------+ | v Blind SQLi | v Application-State Abuse | v Privilege Escalation | v Administrator Access | v Authenticated RCE ``` La propriété de sécurité importante est l'interaction entre les deux vulnérabilités plutôt que chaque vulnérabilité prise isolément. --- # CVE-2026-63030 ## Confusion de routage de lot dans l'API REST La première vulnérabilité affecte le traitement des requêtes via le point de terminaison Batch de l'API REST de WordPress. L'implémentation du lot conserve les informations de correspondance et de validation des requêtes dans des structures parallèles indexées par la position de la requête. Une sous-requête malformée peut entraîner une désynchronisation de ces structures. Cela crée une condition de répartition décalée d'un élément (off-by-one) où une requête ultérieure peut être traitée à l'aide d'un gestionnaire ou d'un contexte de validation associé à une autre requête. Sur le plan conceptuel :```text Request A | +-- validation entry +-- matching entry | v Malformed request | +-- internal state becomes desynchronized | v Request B | +-- unexpected handler / validation context ``` La preuve de concept effectue des vérifications comportementales pour déterminer si la confusion de route est réellement atteignable. --- # CVE-2026-60137 ## Injection SQL dans WP_Query La deuxième vulnérabilité affecte un chemin de traitement SQL de `WP_Query`. Une fois la primitive de confusion de route établie, une entrée contrôlée par l'attaquant peut atteindre le chemin de requête vulnérable. La preuve de concept démontre l'injection SQL résultante par test différentiel aveugle. Les fonctionnalités de recherche incluent : * Confirmation booléenne aveugle * Corroboration facultative basée sur le temps * Empreinte de base de données * Extraction scalaire prise en charge * Recherche de données utilisateur WordPress --- # Comment fonctionne la chaîne ## 1. Confusion de route par lot REST Une requête non authentifiée atteint le point de terminaison REST Batch de WordPress. Une sous-requête de lot malformée provoque la désynchronisation de l'état interne de correspondance et de validation des requêtes. Une requête ultérieure peut par conséquent être traitée dans un contexte non prévu. --- ## 2. Injection SQL La primitive de confusion de route fournit le chemin nécessaire à la deuxième vulnérabilité. Une valeur contrôlée par l'attaquant peut atteindre le chemin de traitement vulnérable de `WP_Query`. Cela crée une primitive d'injection SQL aveugle. --- ## 3. Extraction SQL aveugle L'injection SQL peut être utilisée comme canal d'extraction booléenne aveugle. La preuve de concept contient des fonctionnalités pour rechercher des informations de base de données et des informations utilisateur WordPress prises en charge. --- ## 4. Manipulation de l'état de l'application La chaîne utilise des résultats contrôlés par la base de données pour influencer les objets d'application WordPress et le traitement ultérieur. Cela fournit les primitives nécessaires à l'étape d'élévation de privilèges. --- ## 5. Escalade de changeset La chaîne utilise le traitement des changesets WordPress pour établir un contexte d'exécution administrateur. Un objet `customize_changeset` fabriqué peut participer à la séquence d'élévation de privilèges. --- ## 6. Ré-entrée de hook La chaîne ré-intègre le traitement des requêtes WordPress via le cycle de vie des requêtes applicatives. Cela permet au traitement ultérieur de l'API de se produire sous le contexte élevé. --- ## 7. Création de compte administrateur La preuve de concept de recherche implémente une étape de création d'administrateur pré-authentification. C'est la principale raison pour laquelle le Mode 3 est utile pour la validation de sécurité : il démontre l'impact de l'élévation de privilèges sans poursuivre vers l'étape webshell/RCE. --- ## 8. Exécution de code authentifiée Le Mode 4 étend la chaîne de recherche au-delà de la création d'administrateur jusqu'à l'étape d'exécution de code authentifiée. Cette étape ne doit être utilisée que dans un laboratoire isolé ou lors d'une évaluation explicitement autorisée. --- # Versions affectées ## Chaîne complète de pré-authentification | Version WordPress | Statut | | ----------------- | -------------- | | 6.9.0 – 6.9.4 | **Vulnérable** | | 7.0.0 – 7.0.1 | **Vulnérable** | | 6.9.5 | **Corrigé** | | 7.0.2+ | **Corrigé** | La preuve de concept identifie `6.9.0–6.9.4` et `7.0.0–7.0.1` comme les versions vulnérables documentées pour la chaîne complète. ## Injection SQL Le composant d'injection SQL a une limite de version corrigée différente de celle de la chaîne complète. L'implémentation de recherche identifie `6.8.6` comme le correctif de l'injection SQL. La chaîne complète non authentifiée dépend en outre du comportement vulnérable de REST Batch. Vérifiez toujours les versions affectées et corrigées par rapport à l'avis de sécurité officiel pertinent avant de prendre des décisions de production. --- # Conditions préalables La preuve de concept documente ces conditions pour la chaîne complète : * L'API REST WordPress est accessible * Pas de cache d'objets Redis/Memcached * Au moins un article publié D'autres composants de déploiement peuvent affecter la reproductibilité : * Proxys inversés * Pare-feu d'application Web * Restrictions de l'API REST * Plugins de sécurité * Mise en cache d'objets * Filtrage HTTP * Configuration d'hébergement Une installation WordPress correspondant à la plage de versions ne signifie pas automatiquement que la chaîne complète fonctionnera dans tous les environnements. --- # Fonctionnalités `wp2shell` fournit un menu interactif contenant les fonctions de recherche suivantes :```text [1] Fingerprint + confirm vulnerability (non-destructive) [2] Blind SQL extraction (fingerprint / dump users) [3] Pre-Auth Admin creation [4] Full RCE chain → admin creation + webshell [5] Facilitated sink SQLi (WordPress 6.8.x / custom) [6] Threaded scan over URL list [7] Transport settings (proxy, TLS, timeout, delay) [8] Change target URL [0] Quit ``` --- # Menu interactif Le menu principal est conçu pour prendre en charge à la fois : * Le test d'une seule installation WordPress autorisée * Le test d'une liste autorisée d'URLs WordPress Le flux de travail peut donc être utilisé à la fois pour des cibles de recherche individuelles et des ensembles de données d'évaluation autorisés plus importants. --- # Mode recommandé — Mode 3 ## Pourquoi le Mode 3 ? Pour la recherche de vulnérabilités, **le Mode 3 est le mode recommandé lorsque l'objectif est de démontrer l'impact sur la sécurité sans déployer de webshell**. Le Mode 3 est :```text Pre-Auth Admin Creation ``` Le PoC décrit cette étape comme suit :```text Unauthenticated UNION SQLi → new WordPress administrator ``` et le distingue explicitement de l'étape complète de webshell/RCE :```text No password cracking. No webshell. Non-destructive admin only. ``` Cela rend le Mode 3 particulièrement utile lorsque vous souhaitez prouver que la chaîne de vulnérabilités atteint une compromission au niveau administrateur tout en évitant l'étape supplémentaire d'exécution de code. --- # Mode 3 — Création d'un administrateur sans authentification La sélection du Mode 3 ouvre :```text ──────────────────────────────────────────────────────────── CREATE ADMIN — Pre-Auth Admin RCE Chain ──────────────────────────────────────────────────────────── ⚠ Unauthenticated UNION SQLi → new WordPress administrator. ⚠ No password cracking. No webshell. Non-destructive admin only. ``` Le PoC demande ensuite plusieurs options d'environnement et de sortie. ## SQLite```text → Target uses SQLite? (WP-SQLite plugin) (y/N) [n]: ``` Définissez ceci sur `y` lorsque la cible autorisée utilise une configuration WordPress SQLite prise en charge par le PoC. Pour les installations WordPress normales MySQL/MariaDB, la valeur par défaut est :```text n ``` --- ## Vérification des identifiants Le PoC peut éventuellement vérifier les identifiants générés en tentant une connexion authentifiée :```text → Verify the generated credentials by logging in? (Y/n) [y]: ``` La valeur par défaut est :```text y ``` Ceci est utile lorsque vous souhaitez que le résultat inclue la confirmation que les identifiants d'administrateur générés s'authentifient réellement. --- ## Fichier de sortie Le mode 3 peut enregistrer les résultats dans un fichier local :```text → Output file (blank = skip, e.g. result.txt): ``` Par exemple :```text logs.txt ``` Laisser le champ vide ignore la sortie du fichier. L'option de sortie est utile lors de recherches autorisées sur plusieurs cibles et lorsque l'on souhaite conserver les résultats pour une analyse ultérieure. --- ## Confusion Carrier Le PoC fournit deux variantes de porteur :```text → Confusion carrier variant (posts/categories) [posts]: ``` Choix disponibles :```text posts categories ``` La valeur par défaut est:```text posts ``` La variante `posts` est le chemin principal documenté. --- # Mode 1 — Empreinte et confirmation Le mode 1 est :```text [1] Fingerprint + confirm vulnerability (non-destructive) ``` C'est le point de départ le plus sûr pour la validation de vulnérabilités. Il se concentre sur la détermination de savoir si la cible présente les conditions comportementales associées à la chaîne de vulnérabilités. L'étape de vérification peut inclure : * Empreinte WordPress * Vérifications du point de terminaison REST Batch * Confirmation de la confusion d'itinéraire * Confirmation de l'injection SQL * Tests différentiels par aveugle booléen * Corroboration facultative basée sur le temps Utilisez le Mode 1 lorsque l'objectif est principalement :```text "Is this target potentially vulnerable?" ``` plutôt que de démontrer l'impact administrateur. --- # Mode 2 — Extraction SQL aveugle Mode 2 est :```text [2] Blind SQL extraction (fingerprint / dump users) ``` Ce mode démontre la primitive d'injection SQL par extraction aveugle. Les fonctionnalités de recherche incluent : * Empreinte de la base de données * Version de la base de données * Utilisateur de la base de données * Nom de la base de données * Expressions scalaires SQL prises en charge * Informations sur les utilisateurs WordPress N'utilisez ce mode que dans un environnement autorisé, car il démontre un impact d'accès aux données plutôt qu'une simple détection de la vulnérabilité. --- # Mode 3 — Création d'un administrateur pré-authentification Le mode 3 est :```text [3] Pre-Auth Admin creation ``` Ce mode démontre l'impact d'élévation de privilèges de la chaîne. La distinction importante est :```text Mode 3 | +-- Pre-authentication chain +-- Administrator creation +-- Optional login verification +-- No password cracking +-- No webshell ``` Pour les chercheurs en sécurité qui doivent prouver l'impact de la vulnérabilité au niveau administrateur sans déployer de webshell, c'est le mode privilégié. --- # Mode 4 — Chaîne RCE complète Le mode 4 est :```text [4] Full RCE chain → admin creation + webshell ``` Cela étend la chaîne au-delà de la création d'administrateur vers une exécution de code authentifiée. Conceptuellement :```text Unauthenticated ↓ Route Confusion ↓ SQL Injection ↓ Privilege Escalation ↓ Administrator Creation ↓ Administrator Authentication ↓ Webshell ↓ Code Execution ``` Ce mode doit être réservé aux laboratoires isolés et aux tests d'intrusion explicitement autorisés. Pour la validation de vulnérabilités ordinaires, le mode 3 est préférable car il démontre la limite de l'impact administrateur sans déployer de webshell. --- # Mode 5 — SQLi Sink facilité Le mode 5 est :```text [5] Facilitated sink SQLi (WordPress 6.8.x / custom) ``` Ce mode est destiné à la recherche impliquant le sink d'injection SQL en dehors de la chaîne complète de pré-authentification. Il est utile pour les chercheurs qui étudient : * les environnements WordPress 6.8.x * les configurations personnalisées * la primitive d'injection SQL de manière indépendante * la reproduction de vulnérabilités * la validation défensive --- # Mode 6 — Analyse d'URL en file d'attente (Threaded URL Scan) Le mode 6 est :```text [6] Threaded scan over URL list ``` Ce mode est destiné aux évaluations autorisées impliquant plusieurs cibles WordPress. Au lieu de tester manuellement une URL à la fois, l'outil peut traiter une liste d'URL à l'aide de worker threads. Conceptuellement :```text urls.txt | +-- URL 1 +-- URL 2 +-- URL 3 +-- URL 4 +-- ... | v Threaded vulnerability checks | v Results ``` La fonctionnalité de scan peut utiliser des options telles que : * Nombre de threads de travail * Délai de confirmation * Preuve de version facultative * Sortie de rapport JSON * Variante de porteur de confusion Utilisez ceci uniquement avec des listes d'URL pour lesquelles vous disposez d'une autorisation explicite. --- # Cible unique vs liste d'URL `wp2shell` peut être utilisé de deux manières générales. ## Cible WordPress unique Utilisez une cible unique lorsque vous étudiez une installation. Cas d'utilisation typiques : * Laboratoire local * Environnement de préproduction * Test d'intrusion approuvé par le client * Reproduction de vulnérabilité * Vérification de CVE La cible doit être une URL de base WordPress. --- ## Liste d'URL Pour plusieurs cibles autorisées, le Mode 6 peut traiter une liste d'URL. Exemple de fichier conceptuel :```text https://wordpress-lab-01.example https://wordpress-lab-02.example https://wordpress-lab-03.example https://wordpress-lab-04.example ``` Le scanner multithreadé peut ensuite traiter la liste et enregistrer les résultats. L'implémentation du scan prend également en charge une option de sortie/rapport pour conserver les résultats. --- # Guide de sélection du mode | Objectif | Mode recommandé | | -------------------------------------- | ---------------- | | Vérifier si une cible est vulnérable | **Mode 1** | | Démontrer une injection SQL | **Mode 2** | | Démontrer un impact de niveau administrateur | **Mode 3** | | Démontrer une chaîne RCE complète | **Mode 4** | | Rechercher le sink SQLi indépendamment | **Mode 5** | | Tester une liste d'URL autorisées | **Mode 6** | | Configurer proxy/TLS/timeout/delay | **Mode 7** | | Changer la cible actuelle | **Mode 8** | ### Workflow de recherche recommandé Pour la plupart des évaluations de sécurité :```text Mode 1 ↓ Confirm vulnerability ↓ Mode 3 ↓ Demonstrate administrator impact ``` Ne passez au mode 4 que lorsque la validation complète de l'exécution de code est explicitement requise et autorisée. --- # Mode 7 — Paramètres de transport Le mode 7 est :```text [7] Transport settings (proxy, TLS, timeout, delay) ``` Cette section contrôle le comportement du transport HTTP utilisé par l'outil. Les paramètres de recherche pris en charge incluent : * Configuration du proxy * Comportement TLS * Délai d'expiration de la requête * Délai entre les requêtes * Comportement de connexion/nouvelle tentative Ces options sont utiles lors des tests d'installations WordPress derrière : * Proxies * Configurations TLS * Connexions lentes * Infrastructure de limitation de débit * Environnements de laboratoire contrôlés --- # Mode 8 — Changer l'URL cible Le mode 8 est :```text [8] Change target URL ``` Cela permet de modifier la cible actuellement sélectionnée sans redémarrer l'ensemble du flux de travail interactif. C'est utile lors du passage entre des installations de laboratoire autorisées. --- # Logique de détection Le PoC utilise des vérifications comportementales plutôt que de se fier exclusivement à une chaîne de version WordPress. ## Détection par lot REST L'outil vérifie que le point de terminaison REST Batch est accessible. ## Détection de confusion de route L'outil peut utiliser : * Des marqueurs de réponse * Le comportement structurel de la réponse L'approche structurelle vérifie si une requête destinée à une collection REST est traitée comme une autre collection. ## Détection d'injection SQL L'outil peut effectuer un différentiel booléen aveugle. Un canal basé sur le temps peut également être utilisé en corroboration. --- # Chaîne technique La chaîne de recherche complète peut se résumer comme suit :```text 1. REST API reachable | v 2. Batch route confusion | v 3. Validation / dispatch confusion | v 4. SQL injection reaches WP_Query | v 5. Blind SQL channel | v 6. Application-state manipulation | v 7. Changeset privilege escalation | v 8. Administrator context | v 9. Administrator account creation | v 10. Authenticated code execution ``` --- # Variantes de route Le PoC prend en charge deux variantes de porteurs de confusion :```text posts categories ``` La valeur par défaut est :```text posts ``` La variante `posts` est le principal vecteur de bout en bout documenté. La variante `categories` offre un chemin alternatif de confusion de routes pour la recherche. --- # Prise en charge de SQLite Le PoC contient un support de compatibilité SQLite pour les environnements utilisant une configuration WordPress SQLite. Le mode 3 expose cette option sous la forme:```text Target uses SQLite? (WP-SQLite plugin) ``` Par défaut:```text n ``` Utilisation :```text y ``` when the authorized target uses the supported SQLite configuration. --- # Installation Le PoC utilise la bibliothèque standard de Python. Aucun paquet Python tiers n'est requis. Environnement requis :```text Python 3.x ``` Clonez le dépôt et exécutez l'outil de recherche dans un environnement isolé ou explicitement autorisé. --- # Structure du projet Une structure de dépôt recommandée est :```text wp2shell/ │ ├── wp2shell.py ├── README.md ├── LICENSE └── screenshots/ ``` La principale implémentation de recherche est :```text wp2shell.py ``` --- # Impact sur la sécurité Une chaîne d'exploitation réussie peut potentiellement entraîner : * Injection SQL non authentifiée * Divulgation d'informations de la base de données * Exposition des informations des utilisateurs WordPress * Élévation de privilèges * Création de compte administrateur * Accès administratif complet à WordPress * Exécution de code arbitraire authentifiée * Compromission potentielle au niveau du système d'exploitation selon l'environnement d'hébergement La chaîne complète a donc un impact nettement plus important que les vulnérabilités individuelles considérées indépendamment. --- # Détection défensive Les administrateurs doivent examiner toute activité suspecte impliquant : * Points de terminaison REST Batch de WordPress * Requêtes batch imbriquées anormales * Chemins de requête batch malformés * Paramètres de requête suspects * Création inattendue de compte administrateur * Activité `customize_changeset` inattendue * Installations de plugins inattendues * Fichiers PHP inattendus * Modifications de plugins suspectes * Comportement de type webshell Examen : ---```text Web server logs + WordPress logs + Database audit logs + File integrity monitoring ``` especially around the time of suspected exploitation. --- # Atténuation La principale mesure d'atténuation consiste à mettre à niveau WordPress vers une version corrigée. Les installations concernées devraient également : 1. Examiner tous les comptes administrateur. 2. Supprimer les comptes administrateur non autorisés. 3. Examiner les extensions récemment installées ou modifiées. 4. Examiner les journaux de l'API REST de WordPress. 5. Examiner les journaux d'accès du serveur web. 6. Rechercher les fichiers PHP inattendus. 7. Vérifier les répertoires des extensions pour détecter des modifications non autorisées. 8. Faire pivoter les identifiants si une compromission est suspectée. 9. Vérifier l'intégrité de la base de données. 10. Supprimer les mécanismes de persistance. 11. Réinstaller les composants WordPress compromis à partir de sources fiables lorsque cela est approprié. --- # Flux de travail de recherche responsable Pour une évaluation autorisée normale, la progression recommandée est :```text START | v ┌─────────────────┐ │ MODE 1 │ │ Detect / Confirm│ └────────┬────────┘ | Vulnerable? / \ No Yes | | STOP v ┌───────────────┐ │ MODE 3 │ │ Admin Impact │ └───────┬───────┘ | Need full RCE? / \ No Yes | | STOP v ┌───────────────┐ │ MODE 4 │ │ Full RCE Lab │ └───────────────┘ ``` Mode 3 est généralement le point de démonstration d'impact privilégié, car il établit un compromis au niveau administrateur sans déployer l' étape webshell. --- # Recherche vs Production Ce projet est destiné à la recherche en sécurité contrôlée. Ne traitez pas l'outil comme un scanner Internet à usage général. Pour les environnements de production : * Obtenez une autorisation écrite. * Définissez le périmètre cible. * Définissez les actions autorisées. * Privilégiez une vérification non destructive. * Arrêtez-vous une fois que des preuves suffisantes ont été collectées. * Conservez les journaux et les preuves. * Suivez le processus de divulgation de vulnérabilité applicable. --- # Crédits Recherche / découverte de vulnérabilité : **Adam Kues** Assetnote / Searchlight Cyber Projet : **wp2shell** L'implémentation de recherche identifie la chaîne de vulnérabilité comme :```text CVE-2026-63030 + CVE-2026-60137 ``` --- # Références * CVE-2026-63030 * CVE-2026-60137 * GHSA-ff9f-jf42-662q * GHSA-fpp7-x2x2-2mjf * WordPress Core * WordPress REST API * WordPress `WP_Query` --- # Avertissement Ce dépôt contient des recherches en sécurité démontrant une chaîne de vulnérabilités affectant WordPress Core. Le logiciel et la documentation sont fournis pour : * Fins éducatives * Recherche en sécurité * Vérification de vulnérabilités * Tests défensifs * Tests d'intrusion autorisés Les auteurs ne sont pas responsables de l'utilisation non autorisée ou malveillante de ce matériel. **Ne testez que les systèmes dont vous êtes propriétaire ou pour lesquels vous disposez d'une autorisation explicite.** --- # Mots-clés```text wp2shell WordPress WordPress Core WordPress Security WordPress Vulnerability WordPress RCE Pre-Auth RCE Pre-Authentication RCE CVE-2026-63030 CVE-2026-60137 REST API REST Batch REST API Batch Route Confusion WP_Query SQL Injection SQLi Blind SQL Injection Privilege Escalation Administrator Creation Remote Code Execution RCE Proof of Concept PoC Security Research Penetration Testing ``` --- ## Topics du dépôt Topics GitHub recommandés pour le dépôt :```text wp2shell wordpress wordpress-core wordpress-security wordpress-vulnerability wordpress-rce cve cve-2026-63030 cve-2026-60137 poc proof-of-concept rce sql-injection sqli blind-sqli rest-api security-research penetration-testing privilege-escalation ``` --- ## Résumé du projet```text wp2shell is a WordPress Core pre-authentication vulnerability-chain PoC combining CVE-2026-63030 (REST API Batch route confusion) and CVE-2026-60137 (WP_Query SQL injection), demonstrating the progression from unauthenticated access to SQL injection, privilege escalation, administrator creation, and authenticated code execution. ``` Veuillez fournir le contenu Markdown à traduire.``` disclaimer: this project is for educational purposes only ```

wp2shell-poc

Populaires

Table des matières

Vue d'ensemble