Tabella di confronto

[1] Solo timing/blind come canale di lettura; la primitiva UNION del finto post esiste all'interno del ponte ma non è esposta come oracolo di estrazione. [2] La sonda di disponibilità ingenua (0) UNION SELECT …) viene silenziosamente scartata durante l'idratazione della cache degli oggetti, available() restituisce false e l'intero ponte pre-autenticazione si interrompe - vedi §1. [3] Il README del progetto stesso elenca "nessuna cache degli oggetti persistente (Redis/Memcached)" tra le Precondizioni. [4] Variante pubblica rispecchiata su Sploitus (link sotto): lettura blind più un dropper INTO OUTFILE come passo RCE, usando un carrier di categorie per_page=-1. [5] Il percorso RCE OUTFILE non dipende dal rendering del finto post, quindi le cache degli oggetti non lo bloccano - a bloccarlo sono il privilegio MySQL FILE e una directory scrivibile condivisa. L'hosting gestito non concede quasi mai FILE all'utente DB di WordPress, e secure_file_priv è comunemente impostato.

1. Il problema della cache degli oggetti (il vero elemento distintivo)

La primitiva UNION del finto post dipende da come WP_Query restituisce le righe:

• Modalità riga intera - la SQL restituisce intere righe di wp_posts; una riga iniettata con UNION diventa direttamente un WP_Post. Il falso viene renderizzato.
• Modalità suddivisa (solo ID) - la SQL restituisce solo gli ID, e ogni ID viene idratato successivamente tramite la cache degli oggetti (persistente) / il database. L'ID della riga falsificata non esiste, quindi l'idratazione lo scarta silenziosamente. Nessun errore, nessun post falsificato.

Su host con cache degli oggetti persistente, un set di base popolato spinge WP_Query in modalità suddivisa. La sonda standard usata dai PoC pubblici -

• lascia il set di base popolato (post_author NOT IN (0) corrisponde a ogni riga), quindi dietro una cache degli oggetti la riga falsificata evapora: la sonda di disponibilità dà un falso negativo, available() restituisce false e l'intero ponte pre-autenticazione viene segnalato come "morto" su un host che in realtà è pienamente sfruttabile. L'unificatore pubblico documenta lo stesso confine elencando "nessuna cache degli oggetti persistente" come precondizione rigida.

Questo repository invece svuota il set di base:

Con zero righe di base, la riga falsificata è l'unica riga; la query resta in modalità riga intera; nessuna lookup di idratazione viene mai eseguita. Una singola parola chiave iniettata (AND 1=0) è l'intera differenza tra "canale UNION morto" e "RCE pre-autenticazione completa" su host con cache degli oggetti - che sono la maggioranza degli ambienti di produzione WordPress gestiti. La diagnosi, la matrice di sondaggio (per_page × forma di iniezione).

Nota sull'ambito: il canale di lettura blind/timing non è sensibile alla cache degli oggetti (contare le righe in SQL non coinvolge l'idratazione del finto post), quindi la lettura blind di ogni PoC funziona ovunque. Ciò che la cache degli oggetti uccide negli altri PoC è specificamente la parte dipendente da UNION: l'estrazione in-band e il ponte SQLi→admin.

Una seconda lezione correlata documentata nel case study: quando entrambi i canali funzionano, considera la lettura UNION in-band come autorevole - l'oracolo timing in produzione ha prodotto bit flippati in condizioni di jitter su un valore che la lettura in-band ha risolto senza ambiguità.

2. Scelta del percorso RCE

Esistono tre percorsi RCE pre-autenticazione nei PoC pubblici:

Questo repository implementa il ponte: non richiede privilegi di database oltre a quelli che WordPress ha già, funziona quando i livelli DB e web non condividono nulla e non lascia alcun file dietro di sé su cui il percorso basato sul privilegio FILE possa dipendere. Il compromesso è la complessità - il ponte è un grafo di post avvelenati di sette righe - che è esattamente il punto in cui il falso negativo della cache degli oggetti di §1 nascondeva il percorso.

3. Impostazioni di sicurezza predefinite per l'uso autorizzato

Progettato per essere eseguito contro sistemi in produzione sotto autorizzazione, non solo laboratori:

• check è non distruttivo di default - fingerprint passiva più un batch benigno di marker; nessun payload SQL viene inviato a meno che non venga fornito --confirm-sqli. Dopo la patch, la tripletta di marker che scompare funge anche da validazione della correzione.
• Tag di attribuzione - --user-agent su ogni comando così che tutto il traffico di exploit sia identificabile nei log (una regola pratica degli engagement che gli strumenti pubblici non applicano di default).
• Pulizia automatica - la webshell è bloccata da token su un percorso randomizzato e si rimuove da sola; un amministratore creato tramite il ponte viene eliminato successivamente con i suoi contenuti riassegnati all'account admin preso in prestito. Il fallimento della pulizia viene segnalato chiaramente, non ignorato.
• Contabilità delle richieste - ogni comando stampa quante richieste ha inviato.

4. Cosa questo repository non sostiene

• Nessuna nuova vulnerabilità. Entrambi i bug sono le CVE divulgate pubblicamente; la forma di batch doppiamente annidato, il sink author_exclude → author__not_in, la primitiva UNION del finto WP_Post e il concetto di customizer-bridge sono tutte tecniche pubbliche (discendenza riconosciuta sotto).
• Nessuna nuova primitiva di sfruttamento. Il delta rispetto al panorama pubblico è: la correzione killed-base per la cache degli oggetti con evidenze di produzione, le impostazioni predefinite sicure per la produzione e la documentazione del rilevamento - robustezza e sicurezza operativa, non novità di tecnica.
• Le stringhe IoC sono arbitrarie. I prefissi di login, gli slug dei plugin, i marker di shell e i valori User-Agent differiscono tra ogni variante e per ogni esecuzione;

Riferimenti

• Icex0/wp2shell-poc - implementazione full-chain condivisa dalla discendenza di questo repository - https://github.com/Icex0/wp2shell-poc
• sergiointel/wp2shell-poc - primo PoC pubblico; origine della tecnica di creazione admin senza crack - https://github.com/sergiointel/wp2shell-poc
• 0xsha/wp2shell - unificatore a file singolo di sei PoC pubblici, con lab Docker e una matrice versione×DB (documenta la precondizione della cache degli oggetti) - https://github.com/0xsha/wp2shell
• Variante OUTFILE (lettura blind + dropper INTO OUTFILE), rispecchiata su Sploitus - https://sploitus.com/exploit?id=7CD079AD-E27B-5C54-A696-60635BFDB241
• Elenco curato di PoC e checker pubblici (per i difensori) - https://www.cyberkendra.com/2026/07/wp2shell-guide.html
• GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf; annuncio di rilascio di WordPress 7.0.2 - vedi i riferimenti in README.md.