Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
A metà luglio 2026 il panorama WordPress è stato scosso da una vulnerabilità critica soprannominata “wp2shell“: una Remote Code Execution (RCE) pre-autenticazione presente nel core del CMS, con potenziale impatto su oltre 500 milioni di siti web.
La falla, tracciata con due identificativi distinti (CVE-2026-60137 e CVE-2026-63030) nasce da un difetto nella gestione dell’endpoint REST /batch/v1, che consente a un attaccante non autenticato di manipolare la validazione delle sotto-richieste fino ad ottenere una SQL Injection e, da lì, l’esecuzione di codice arbitrario sul server.
L’obiettivo di questo articolo è puramente didattico. Vogliamo ricostruire, passo dopo passo, l’intero percorso che porta dalla scoperta della vulnerabilità alla compromissione completa di un’istanza WordPress in laboratorio, così da comprendere il meccanismo dell’attacco, la sua reale pericolosità e l’importanza di applicare tempestivamente le patch di sicurezza.
Tutte le attività descritte sono state condotte in un laboratorio isolato e controllato, su un’installazione WordPress dedicata e priva di dati reali, appositamente predisposta per l’analisi della vulnerabilità.
Il punto di partenza è l’articolo pubblicato da Red Hot Cyber, a firma di Luigi Zullo, che ha dato risalto alla scoperta: “Massimo allarme per WordPress: RCE critica nel core, 500 milioni di siti potenzialmente vulnerabili”. La sintesi editoriale inquadra bene la portata del problema.
Dall’articolo emergono le informazioni chiave necessarie per orientare l’analisi:
Queste informazioni pubbliche costituiscono la base di partenza per verificare se la nostra installazione di laboratorio rientri tra le versioni vulnerabili.
Il primo passo operativo è controllare la versione di WordPress effettivamente installata sul target di test, tramite il pannello di amministrazione (wp-admin → Aggiornamenti).
Il pannello di WordPress indica “You have the latest version of WordPress” con versione 6.9.1. Va precisato che il laboratorio è volutamente isolato dalla rete Internet, quindi questo messaggio riflette semplicemente l’assenza di connettività verso i server di WordPress.org e non un reale fallimento del meccanismo di auto-update.
Il dato resta comunque utile a fini didattici per un motivo diverso: dimostra che la sola dicitura “aggiornato” mostrata da un pannello, senza un riscontro attivo con i bollettini di sicurezza più recenti, non garantisce affatto l’assenza di vulnerabilità note, specialmente quando queste vengono scoperte dopo il rilascio della versione stessa.
Per confermare che la versione 6.9.1 rientri effettivamente nel perimetro vulnerabile, è stato consultato il repository pubblico Icex0/wp2shell-poc su GitHub, che documenta in modo dettagliato la catena di exploit completa (“full RCE chain”).
La tabella riportata nella repository conferma quanto ipotizzato:
La documentazione della PoC spiega anche la causa tecnica alla radice: l’endpoint REST /batch/v1 non è autenticato ed esegue più sotto-richieste in un’unica chiamata, basandosi sul fatto che ciascuna sotto-richiesta venga validata singolarmente.
Le funzioni serve_batch_request_v1() e la logica di validazione costruiscono due array paralleli (i match delle richieste e i risultati di validazione) che vengono poi indicizzati usando lo stesso offset al momento del dispatch.
Quando il path di una sotto-richiesta fallisce la normalizzazione tramite wp_parse_url(), viene comunque aggiunto all’array dei risultati di validazione ma non a quello dei match: questo disallineamento tra i due array è il cuore del bug, e permette a una richiesta malevola di “ereditare” l’esito di validazione di una richiesta legittima precedente ed eseguirla.
Con la conferma teorica in mano, si è passati alla fase di ricognizione attiva sul target di laboratorio, utilizzando lo script Python fornito dalla PoC in modalità di check preliminare.
L’output mostra con chiarezza il processo di fingerprinting: la versione 6.9.1 viene identificata passivamente tramite il generator esposto nei feed RSS (/?feed=rss2), dopodiché lo strumento segnala la presenza di due vulnerabilità concatenate:
Viene inoltre enumerato il tema attivo (Twenty Twenty-Five) con relativa versione e directory listing abilitato: informazioni di contorno utili in una ricognizione più ampia, ma non centrali per lo sfruttamento di wp2shell.
Prima di mostrare l’exploit in azione è opportuna una precisazione metodologica: lo script della PoC pubblica, nella sua versione originale, è stato scritto per l’esecuzione di comandi su server Linux (come mostra il commento “for linux server (original)” nel codice, con la costruzione della shell tramite shlex.quote e printf per delimitare l’output).
Il target di laboratorio, invece, gira su stack XAMPP in ambiente Windows: la sezione di esecuzione comandi è stata quindi adattata di conseguenza (“for windows server”), rimuovendo le costruzioni di shell tipiche di Linux non compatibili con cmd.exe.
Si tratta di una modifica minima, circoscritta al solo wrapper di esecuzione dei comandi lato client, che non altera in alcun modo la logica della vulnerabilità né la catena SQLi-to-RCE, ma è necessaria per adattare la PoC al sistema operativo del target di test.
È stata fatta un ulteriore modifica per stampare la password auto generata del utente che andra a creare.
In una prima esecuzione, con l’opzione –confirm-sqli, lo script conferma concretamente la vulnerabilità inviando una sonda sulla rotta batch e verificando la risposta HTTP e i marcatori attesi, fino a confermare la SQL Injection tramite una UNION su un fake-post di lettura.
Confermata la vulnerabilità, si è passati alla fase di exploitation vera e propria, lanciando lo script in modalità shell. È importante sottolineare che l’attacco parte senza credenziali: l’intero processo, dalla creazione dell’utente amministratore al caricamento della webshell, avviene sfruttando esclusivamente la catena SQLi-to-RCE pre-autenticazione.
La sequenza osservata nel terminale è la seguente:
Questo passaggio rappresenta il cuore della dimostrazione: da una richiesta HTTP non autenticata si arriva, in pochi secondi e senza alcuna interazione manuale, all’esecuzione di comandi con i privilegi del processo web.
Per completare il quadro, è utile osservare gli effetti dell’attacco anche dal punto di vista dell’amministratore legittimo, accedendo al pannello wp-admin con l’utenza compromessa.
Nella sezione Utenti compare il nuovo account amministratore, con email fittizia (@wp2shell.invalid) generata automaticamente dal processo di exploitation. Il secondo account (wp2shell) è l’amministratore legittimo dell’installazione di test.
Nella sezione Plugin è presente il plugin wp2shell, con la laconica descrizione “Temporary command runner”: si tratta della webshell caricata dall’exploit, camuffata come un plugin ordinario e attivabile/disattivabile come qualsiasi altra estensione.
Questo dettaglio è particolarmente istruttivo per chi si occupa di incident response: un plugin sconosciuto con un nome insolito e una descrizione generica è spesso il primo indicatore di compromissione da cercare durante un’analisi forense su un sito WordPress.
Il percorso ricostruito mostra in modo lineare come una vulnerabilità apparentemente circoscritta a un endpoint REST poco noto (/batch/v1) possa trasformarsi, attraverso una catena di errori di validazione, in una compromissione totale del sistema: dalla SQL Injection alla creazione di un amministratore, fino all’esecuzione di comandi arbitrari tramite webshell. L’intero processo, come dimostrato, non richiede credenziali né interazione da parte della vittima, il che spiega la gravità con cui la community di sicurezza ha accolto la scoperta di wp2shell.
Dal punto di vista difensivo, gli elementi chiave da portare a casa sono tre. Primo: la dicitura “aggiornato” mostrata dal pannello di WordPress non è una garanzia assoluta di assenza di vulnerabilità, è necessario monitorare attivamente i bollettini di sicurezza (come quello di Red Hot Cyber) e verificare la propria versione anche quando il sistema la dichiara aggiornata, specialmente in presenza di CVE critiche scoperte dopo il rilascio.
Secondo: endpoint REST che aggregano più operazioni in un’unica chiamata (batch endpoint) meritano un’attenzione particolare in fase di validazione, perché un disallineamento anche minimo tra strutture dati parallele può avere conseguenze catastrofiche.
Terzo: la presenza di plugin non riconosciuti, anche con nomi e descrizioni apparentemente innocue, deve sempre destare sospetto e innescare una verifica di integrità del sito.
Il video completo, che accompagnerà questo articolo, mostrerà l’intera sequenza in azione end-to-end, dalla ricognizione iniziale fino alla shell interattiva sul sistema compromesso, offrendo una dimostrazione pratica e riproducibile in ambiente di laboratorio a scopo esclusivamente didattico e di sensibilizzazione.
Nota: attività condotta esclusivamente in ambiente di laboratorio isolato, a scopo didattico e di awareness. Nessuna delle informazioni qui riportate va utilizzata su sistemi privi di autorizzazione esplicita.
Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione.
Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica.
C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale.
Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/