wp2shell

💙 Sostieni il progetto

Se apprezzi il mio lavoro, considera di sostenere il progetto tramite USDT (TRC20): TQBA72kakjCZLnJt8fJYcD7dyQCEpzNtVN

Catena RCE pre-autenticazione di WordPress Core

wp2shell è un Proof-of-Concept di ricerca sulla sicurezza che dimostra una catena di vulnerabilità pre-autenticazione in WordPress Core combinando:

CVE-2026-63030 — confusione di route del batch REST API
CVE-2026-60137 — iniezione SQL in WP_Query

La catena dimostra come queste vulnerabilità possano essere combinate per passare da una richiesta REST API non autenticata a un'iniezione SQL, escalation dei privilegi, creazione di un account amministratore e, infine, esecuzione remota di codice autenticata.

[!WARNING]

Solo ricerca sulla sicurezza autorizzata

Questo progetto è destinato a:

Ricerca di vulnerabilità

Validazione difensiva

Test di penetrazione autorizzati

Il PoC è implementato come strumento di ricerca Python e usa la libreria standard di Python senza richiedere pacchetti Python di terze parti. --- # Catena di vulnerabilità Il progetto combina due vulnerabilità del core di WordPress.```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 proprietà di sicurezza importante è l'interazione tra le due vulnerabilità piuttosto che ciascuna vulnerabilità isolatamente. --- # CVE-2026-63030 ## Confusione del percorso Batch nell'API REST La prima vulnerabilità riguarda l'elaborazione delle richieste attraverso l'endpoint Batch dell'API REST di WordPress. L'implementazione batch mantiene le informazioni di corrispondenza e validazione delle richieste in strutture parallele indicizzate per posizione della richiesta. Una sotto-richiesta malformata può causare la desincronizzazione di tali strutture. Ciò crea una condizione di dispatch off-by-one in cui una richiesta successiva può essere elaborata utilizzando un handler o un contesto di validazione associato a un'altra richiesta. Concettualmente:```text Request A | +-- validation entry +-- matching entry | v Malformed request | +-- internal state becomes desynchronized | v Request B | +-- unexpected handler / validation context ``` Il PoC esegue controlli comportamentali per determinare se la confusione di route è effettivamente raggiungibile. --- # CVE-2026-60137 ## WP_Query SQL Injection La seconda vulnerabilità interessa un percorso di elaborazione SQL di `WP_Query`. Una volta stabilita la primitiva di confusione di route, l'input controllato dall'attaccante può raggiungere il percorso di query vulnerabile. Il PoC dimostra l'iniezione SQL risultante tramite test differenziali ciechi. Le funzionalità di ricerca includono: * Conferma booleana cieca * Corroborazione opzionale basata sul tempo * Fingerprinting del database * Estrazione di scalari supportati * Ricerca dei dati utente di WordPress --- # Come Funziona la Catena ## 1. Confusione di Route nel REST Batch Una richiesta non autenticata raggiunge l'endpoint REST Batch di WordPress. Una sotto-richiesta batch malformata causa la desincronizzazione dello stato di corrispondenza e convalida delle richieste interne. Una richiesta successiva può di conseguenza essere elaborata utilizzando un contesto non previsto. --- ## 2. SQL Injection La primitiva di confusione di route fornisce il percorso necessario per la seconda vulnerabilità. Un valore controllato dall'attaccante può raggiungere il percorso di elaborazione vulnerabile di `WP_Query`. Ciò crea una primitiva di iniezione SQL cieca. --- ## 3. Estrazione SQL Cieca L'iniezione SQL può essere utilizzata come canale di estrazione booleano cieco. Il PoC contiene funzionalità per ricercare informazioni sul database e informazioni supportate sugli utenti WordPress. --- ## 4. Manipolazione dello Stato dell'Applicazione La catena utilizza risultati controllati dal database per influenzare gli oggetti applicativi WordPress e l'elaborazione successiva. Ciò fornisce le primitive necessarie alla fase di elevazione dei privilegi. --- ## 5. Escalation del Changeset La catena utilizza l'elaborazione dei changeset di WordPress per stabilire un contesto di esecuzione amministratore. Un oggetto `customize_changeset` fabbricato può partecipare alla sequenza di elevazione dei privilegi. --- ## 6. Ri-ingresso negli Hook La catena rientra nell'elaborazione delle richieste WordPress attraverso il ciclo di vita delle richieste dell'applicazione. Ciò consente all'elaborazione API successiva di avvenire nel contesto elevato. --- ## 7. Creazione di un Account Amministratore Il PoC di ricerca implementa una fase di creazione di un amministratore in pre-autenticazione. Questo è il motivo principale per cui la Modalità 3 è utile per la validazione della sicurezza: dimostra l'impatto dell'elevazione dei privilegi senza proseguire nella fase webshell/RCE. --- ## 8. Esecuzione di Codice Autenticata La Modalità 4 estende la catena di ricerca oltre la creazione dell'amministratore, entrando nella fase di esecuzione di codice autenticata. Questa fase dovrebbe essere utilizzata solo in un laboratorio isolato o in una valutazione esplicitamente autorizzata. --- # Versioni Interessate ## Catena Completa di Pre-Autenticazione | Versione di WordPress | Stato | | ----------------- | -------------- | | 6.9.0 – 6.9.4 | **Vulnerabile** | | 7.0.0 – 7.0.1 | **Vulnerabile** | | 6.9.5 | **Risolto** | | 7.0.2+ | **Risolto** | Il PoC identifica `6.9.0–6.9.4` e `7.0.0–7.0.1` come le versioni documentate vulnerabili all'intera catena. ## SQL Injection Il componente dell'iniezione SQL ha un confine di versione corretta diverso dalla catena completa. L'implementazione di ricerca identifica `6.8.6` come correzione dell'iniezione SQL. L'intera catena non autenticata dipende inoltre dal comportamento vulnerabile del REST Batch. Verificare sempre le versioni interessate e corrette rispetto all'avviso di sicurezza ufficiale pertinente prima di prendere decisioni di produzione. --- # Precondizioni Il PoC documenta queste condizioni per l'intera catena: * L'API REST di WordPress è raggiungibile * Nessuna cache di oggetti Redis/Memcached * Almeno un post pubblicato Altri componenti di distribuzione possono influire sulla riproducibilità: * Proxy inversi * Firewall per applicazioni web * Restrizioni delle API REST * Plugin di sicurezza * Caching degli oggetti * Filtraggio HTTP * Configurazione dell'hosting Un'installazione WordPress che rientra nell'intervallo di versioni non significa automaticamente che l'intera catena funzionerà in ogni ambiente. --- # Funzionalità `wp2shell` fornisce un menu interattivo contenente le seguenti funzioni di ricerca:```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 Interattivo Il menu principale è progettato per supportare entrambe le possibilità: * Testare una singola installazione WordPress autorizzata * Testare un elenco autorizzato di URL WordPress Il flusso di lavoro può quindi essere utilizzato sia per obiettivi di ricerca individuali sia per set di dati di valutazione autorizzati più ampi. --- # Modalità Consigliata — Modalità 3 ## Perché la Modalità 3? Per la ricerca di vulnerabilità, **la Modalità 3 è quella consigliata quando l'obiettivo è dimostrare l'impatto sulla sicurezza senza distribuire una webshell**. La Modalità 3 è:```text Pre-Auth Admin Creation ``` Il PoC descrive questa fase come:```text Unauthenticated UNION SQLi → new WordPress administrator ``` e lo distingue esplicitamente dalla fase completa di webshell/RCE:```text No password cracking. No webshell. Non-destructive admin only. ``` Questo rende Mode 3 particolarmente utile quando si vuole dimostrare che la catena di vulnerabilità raggiunge un compromesso a livello di amministratore evitando la fase aggiuntiva di esecuzione del codice. --- # Mode 3 — Creazione Amministratore Pre-Auth Selezionando Mode 3 si apre:```text ──────────────────────────────────────────────────────────── CREATE ADMIN — Pre-Auth Admin RCE Chain ──────────────────────────────────────────────────────────── ⚠ Unauthenticated UNION SQLi → new WordPress administrator. ⚠ No password cracking. No webshell. Non-destructive admin only. ``` Il PoC chiede quindi diverse opzioni di ambiente e di output. ## SQLite```text → Target uses SQLite? (WP-SQLite plugin) (y/N) [n]: ``` Imposta questo su `y` quando il target autorizzato utilizza una configurazione WordPress SQLite supportata dal PoC. Per le normali installazioni WordPress MySQL/MariaDB, il valore predefinito è:```text n ``` --- ## Verifica delle credenziali Il PoC può opzionalmente verificare le credenziali generate tentando un accesso autenticato:```text → Verify the generated credentials by logging in? (Y/n) [y]: ``` L'impostazione predefinita è:```text y ``` Questo è utile quando si vuole che il risultato includa la conferma che le credenziali amministrative generate autentichino realmente. --- ## File di output Mode 3 può salvare i risultati in un file locale:```text → Output file (blank = skip, e.g. result.txt): ``` Per esempio:```text logs.txt ``` Lasciando il campo vuoto si salta l'output su file. L'opzione di output è utile quando si esegue una ricerca autorizzata su più target e si vogliono conservare i risultati per un'analisi successiva. --- ## Confusion Carrier La PoC fornisce due varianti di carrier:```text → Confusion carrier variant (posts/categories) [posts]: ``` Opzioni disponibili:```text posts categories ``` Il valore predefinito è:```text posts ``` La variante `posts` è il percorso documentato principale. --- # Modalità 1 — Fingerprint e Conferma La Modalità 1 è:```text [1] Fingerprint + confirm vulnerability (non-destructive) ``` Questo è il punto di partenza più sicuro per la validazione delle vulnerabilità. Si concentra sul determinare se il target presenta le condizioni comportamentali associate alla catena di vulnerabilità. La fase di verifica può includere: * Fingerprinting di WordPress * Controlli degli endpoint REST Batch * Conferma della route-confusion * Conferma dell'iniezione SQL * Test differenziali boolean-blind * Corroborazione opzionale basata sul tempo Usa Mode 1 quando l'obiettivo è principalmente:```text "Is this target potentially vulnerable?" ``` piuttosto che dimostrare l'impatto a livello di amministratore. --- # Modalità 2 — Estrazione SQL cieca La modalità 2 è:```text [2] Blind SQL extraction (fingerprint / dump users) ``` Questa modalità dimostra la primitiva di SQL injection tramite estrazione cieca. Le funzionalità di ricerca includono: * Fingerprinting del database * Versione del database * Utente del database * Nome del database * Espressioni SQL scalari supportate * Informazioni sugli utenti WordPress Usa questa modalità solo in un ambiente autorizzato perché dimostra l'impatto sull'accesso ai dati piuttosto che limitarsi a rilevare la vulnerabilità. --- # Modalità 3 — Creazione Admin Pre-Autenticazione La modalità 3 è:```text [3] Pre-Auth Admin creation ``` Questa modalità dimostra l'impatto di escalation dei privilegi della catena. La distinzione importante è:```text Mode 3 | +-- Pre-authentication chain +-- Administrator creation +-- Optional login verification +-- No password cracking +-- No webshell ``` Per i ricercatori di sicurezza che devono dimostrare l'impatto a livello di amministratore della vulnerabilità senza distribuire una webshell, questa è la modalità preferita. --- # Modalità 4 — Catena RCE completa La Modalità 4 è:```text [4] Full RCE chain → admin creation + webshell ``` Questo estende la catena oltre la creazione dell'amministratore, fino all'esecuzione di codice autenticata. Concettualmente:```text Unauthenticated ↓ Route Confusion ↓ SQL Injection ↓ Privilege Escalation ↓ Administrator Creation ↓ Administrator Authentication ↓ Webshell ↓ Code Execution ``` Questa modalità dovrebbe essere limitata a laboratori isolati e test di penetrazione esplicitamente autorizzati. Per la validazione ordinaria delle vulnerabilità, la Modalità 3 è preferibile perché dimostra il confine dell'impatto a livello di amministratore senza distribuire una webshell. --- # Modalità 5 — Facilitated Sink SQLi La Modalità 5 è:```text [5] Facilitated sink SQLi (WordPress 6.8.x / custom) ``` Questa modalità è pensata per la ricerca che coinvolge il sink di SQL injection al di fuori dell'intera catena di pre-autenticazione. È utile per i ricercatori che indagano su: * Ambienti WordPress 6.8.x * Configurazioni personalizzate * La primitiva di SQL injection in modo indipendente * Riproduzione delle vulnerabilità * Validazione difensiva --- # Modalità 6 — Scansione URL multithread La modalità 6 è:```text [6] Threaded scan over URL list ``` Questa modalità è pensata per valutazioni autorizzate che coinvolgono più target WordPress. Invece di testare manualmente un URL alla volta, lo strumento può elaborare una lista di URL utilizzando worker threads. Concettualmente:```text urls.txt | +-- URL 1 +-- URL 2 +-- URL 3 +-- URL 4 +-- ... | v Threaded vulnerability checks | v Results ``` The scan functionality can use options such as: * Worker thread count * Confirmation delay * Optional version proof * JSON report output * Confusion carrier variant Use this only with URL lists for which you have explicit authorization. --- # Single Target vs URL List `wp2shell` can be used in two general ways. ## Single WordPress Target Use a single target when researching one installation. Typical use cases: * Local laboratory * Staging environment * Customer-approved penetration test * Vulnerability reproduction * CVE verification The target should be a WordPress base URL. --- ## URL List For multiple authorized targets, Mode 6 can process a URL list. Example conceptual file:```text https://wordpress-lab-01.example https://wordpress-lab-02.example https://wordpress-lab-03.example https://wordpress-lab-04.example ``` Lo scanner multithread può quindi elaborare l'elenco e registrare i risultati. L'implementazione della scansione supporta anche un'opzione di output/report per conservare i risultati. --- # Guida alla selezione della modalità | Obiettivo | Modalità consigliata | | -------------------------------------- | ---------------- | | Verificare se un target è vulnerabile | **Modalità 1** | | Dimostrare SQL injection | **Modalità 2** | | Dimostrare un impatto a livello di amministratore | **Modalità 3** | | Dimostrare una catena RCE completa | **Modalità 4** | | Studiare il sink SQLi in modo indipendente | **Modalità 5** | | Testare un elenco di URL autorizzati | **Modalità 6** | | Configurare proxy/TLS/timeout/ritardo | **Modalità 7** | | Cambiare il target corrente | **Modalità 8** | ### Flusso di lavoro di ricerca consigliato Per la maggior parte delle valutazioni di sicurezza:```text Mode 1 ↓ Confirm vulnerability ↓ Mode 3 ↓ Demonstrate administrator impact ``` Procedi alla Modalità 4 solo quando la validazione completa dell'esecuzione del codice è esplicitamente richiesta e autorizzata. --- # Modalità 7 — Impostazioni di trasporto La Modalità 7 è:```text [7] Transport settings (proxy, TLS, timeout, delay) ``` Questa sezione controlla il comportamento del trasporto HTTP utilizzato dallo strumento. Le impostazioni di ricerca supportate includono: * Configurazione del proxy * Comportamento TLS * Timeout della richiesta * Ritardo della richiesta * Comportamento di connessione/retry Queste opzioni sono utili quando si testano installazioni WordPress dietro: * Proxy * Configurazioni TLS * Connessioni lente * Infrastrutture con limitazione della velocità * Ambienti di laboratorio controllati --- # Mode 8 — Cambia URL di destinazione Mode 8 è:```text [8] Change target URL ``` Questo consente di modificare il target attualmente selezionato senza riavviare l'intero flusso di lavoro interattivo. È utile quando ci si sposta tra installazioni di laboratorio autorizzate. --- # Logica di Rilevamento Il PoC utilizza controlli comportamentali invece di affidarsi esclusivamente a una stringa della versione di WordPress. ## Rilevamento REST Batch Lo strumento verifica che l'endpoint REST Batch sia raggiungibile. ## Rilevamento della Confusione di Route Lo strumento può utilizzare: * Marcatori di risposta * Comportamento strutturale della risposta L'approccio strutturale verifica se una richiesta destinata a una raccolta REST viene elaborata come un'altra raccolta. ## Rilevamento di SQL Injection Lo strumento può eseguire un'analisi differenziale boolean-blind. Un canale basato sul tempo può inoltre essere utilizzato come elemento di conferma. --- # Catena Tecnica L'intera catena di ricerca può essere riassunta come:```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 ``` --- # Route Variants La PoC supporta due varianti di carrier di confusione:```text posts categories ``` L'impostazione predefinita è:```text posts ``` La variante `posts` è il vettore end-to-end principale documentato. La variante `categories` fornisce un percorso alternativo di route-confusion per la ricerca. --- # Supporto SQLite Il PoC contiene il supporto di compatibilità SQLite per ambienti che utilizzano una configurazione SQLite di WordPress. Mode 3 espone questa opzione come:```text Target uses SQLite? (WP-SQLite plugin) ``` Predefinito:```text n ``` Uso:```text y ``` quando il target autorizzato utilizza la configurazione SQLite supportata. --- # Installazione Il PoC utilizza la libreria standard di Python. Non sono richiesti pacchetti Python di terze parti. Ambiente richiesto:```text Python 3.x ``` Clona il repository ed esegui lo strumento di ricerca in un ambiente isolato o esplicitamente autorizzato. --- # Struttura del Progetto Una struttura del repository consigliata è:```text wp2shell/ │ ├── wp2shell.py ├── README.md ├── LICENSE └── screenshots/ ``` La principale implementazione della ricerca è:```text wp2shell.py ``` # Impatto sulla sicurezza Una catena di sfruttamento riuscita può potenzialmente comportare: * Iniezione SQL non autenticata * Divulgazione di informazioni dal database * Esposizione delle informazioni degli utenti di WordPress * Escalation dei privilegi * Creazione di account amministratore * Accesso amministrativo completo a WordPress * Esecuzione arbitraria di codice autenticato * Potenziale compromissione a livello di sistema operativo a seconda dell'ambiente di hosting L'intera catena ha quindi un impatto significativamente maggiore rispetto alle singole vulnerabilità considerate singolarmente. --- # Rilevamento difensivo Gli amministratori dovrebbero indagare su attività sospette che coinvolgono: * Endpoint REST Batch di WordPress * Richieste batch annidate anomale * Percorsi di richiesta batch malformati * Parametri di query sospetti * Creazione imprevista di account amministratore * Attività `customize_changeset` imprevista * Installazioni impreviste di plugin * File PHP imprevisti * Modifiche sospette ai plugin * Comportamento simile a webshell Revisione:```text Web server logs + WordPress logs + Database audit logs + File integrity monitoring ``` especially around the time of suspected exploitation. --- # Mitigazione La mitigazione principale consiste nell'aggiornare WordPress a una versione corretta. Le installazioni interessate dovrebbero anche: 1. Rivedere tutti gli account amministratore. 2. Rimuovere gli account amministratore non autorizzati. 3. Esaminare i plugin installati o modificati di recente. 4. Controllare i log dell'API REST di WordPress. 5. Controllare i log di accesso del server web. 6. Cercare file PHP inattesi. 7. Verificare che le directory dei plugin non presentino modifiche non autorizzate. 8. Ruotare le credenziali se si sospetta una compromissione. 9. Verificare l'integrità del database. 10. Rimuovere i meccanismi di persistenza. 11. Reinstallare i componenti WordPress compromessi da fonti attendibili quando opportuno. --- # Flusso di lavoro per la ricerca responsabile Per una valutazione autorizzata normale, la progressione consigliata è:```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 è generalmente il punto preferito per la dimostrazione dell'impatto, poiché stabilisce la compromissione a livello di amministratore senza distribuire lo stage webshell. --- # Ricerca vs Produzione Questo progetto è destinato a una ricerca di sicurezza controllata. Non trattare lo strumento come uno scanner Internet generico. Per gli ambienti di produzione: * Ottenere l'autorizzazione scritta. * Definire l'ambito del target. * Definire le azioni consentite. * Preferire la verifica non distruttiva. * Fermarsi dopo aver raccolto prove sufficienti. * Conservare log e prove. * Seguire il processo di divulgazione delle vulnerabilità applicabile. --- # Crediti Ricerca / scoperta della vulnerabilità: **Adam Kues** Assetnote / Searchlight Cyber Progetto: **wp2shell** L'implementazione della ricerca identifica la catena di vulnerabilità come:```text CVE-2026-63030 + CVE-2026-60137 ``` --- # Riferimenti * CVE-2026-63030 * CVE-2026-60137 * GHSA-ff9f-jf42-662q * GHSA-fpp7-x2x2-2mjf * WordPress Core * WordPress REST API * WordPress `WP_Query` --- # Dichiarazione di non responsabilità Questo repository contiene una ricerca di sicurezza che dimostra una catena di vulnerabilità che interessa WordPress Core. Il software e la documentazione sono forniti per: * Scopi educativi * Ricerca sulla sicurezza * Verifica delle vulnerabilità * Test difensivi * Test di penetrazione autorizzati Gli autori non sono responsabili dell'uso non autorizzato o malevolo di questo materiale. **Testa solo sistemi di tua proprietà o sistemi per i quali hai esplicita autorizzazione.** --- # Parole chiave```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 ``` --- ## Argomenti del repository Argomenti consigliati per il repository GitHub:```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 ``` ## Riepilogo del progetto```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. ``` Nessun contenuto fornito per la traduzione.``` disclaimer: this project is for educational purposes only ```

wp2shell-poc

Più Popolari

Indice

Panoramica