Premessa
Questo è uno scritto, articolo di tipo forense che prende fonti accreditate a livello internazionale su portali ad alto impatto e con consolidata reputazione. La ricostruzione dei fatti mette a confronto fonti primarie, database internazionali di vulnerabilità e analisi indipendenti prodotte da società specializzate in cybersecurity. Tutti i link e le fonti sono in calce a questa analisi.
Per ricostruire correttamente quanto accaduto bisogna prima mettere ordine nella cronologia e soprattutto separare ciò che è stato effettivamente documentato dalle interpretazioni successive. La prima vulnerabilità rilevante è CVE-2026-60137, una SQL Injection che interessa la gestione del parametro author__not_in all’interno di WP_Query quando vengono utilizzati dati non affidabili. Presa singolarmente è già una vulnerabilità seria, ma il vero elemento di rischio emerge quando viene concatenata con una seconda vulnerabilità del core. La seconda falla è CVE-2026-63030, relativa alla gestione delle richieste dell’endpoint batch della REST API e ad una condizione di route confusion. In determinate condizioni, un attaccante non autenticato può sfruttare questa debolezza per costruire una catena con la precedente SQL Injection e arrivare all’esecuzione remota di codice. La stessa documentazione del progetto WordPress descrive infatti la combinazione delle due vulnerabilità come una condizione capace di portare alla Remote Code Execution, mentre le analisi indipendenti di Akamai e Searchlight Cyber ricostruiscono la catena come un attacco pre-authentication, cioè realizzabile senza che l’attaccante disponga preventivamente di un account valido.
Ed è qui che il problema cambia natura e diventa un incubo: l’attaccante non deve necessariamente “indovinare la password”, forzare l’account “admin” o pushare la porta wp-login.php, ma può cercare di fare in modo che sia il sistema stesso a consegnargli, attraverso una sequenza di vulnerabilità concatenate, le condizioni necessarie per eseguire codice.
L’illusione della porta d’ingresso e il bypass delle credenziali
Ti attaccano e allora subito il dito viene puntato ad una password debole, al tuo account “admin” oppure al wp-login unhidden, ma esiste un grande equivoco nella sicurezza web: l’idea che proteggere l’accesso con nome utente e password sia sufficiente a fermare chiunque voglia compromettere un server. Quando si pensa ad un attacco a un CMS, la mente va subito ai bot che tentano l’accesso a ripetizione su wp-login.php, sperando di indovinare password deboli o l’intramontabile utente admin. Cambiare la rotta di login, impostare la doppia autenticazione e nascondere gli endpoint di autenticazione sono ottime prassi per evitare di sprecare risorse del server sotto attacchi brute force, ma contro le falle critiche del core possono essere del tutto inefficaci. Gli attacchi di livello architetturale non bussano alla porta principale per chiedere le chiavi: entrano direttamente dalla struttura, sfruttando il modo in cui il sistema interpreta e processa una richiesta prima ancora che venga chiesto chi sei. Se la vulnerabilità è sfruttabile prima dell’autenticazione, l’attaccante non deve necessariamente conoscere username e password dell’amministratore e non deve necessariamente passare da wp-login.php. Ed è proprio questo il punto più importante della vicenda che stiamo ricostruendo.
L’inizio della catena di compromissione in WordPress 6.9
La release 6.9 rappresenta una parte importante della superficie interessata dalla catena, ma anche qui è necessario essere precisi perché non tutte le versioni del ramo 6.9 risultano vulnerabili nello stesso modo. La documentazione tecnica relativa a CVE-2026-60137 identifica la SQL Injection nella gestione di author__not_in all’interno di WP_Query, mentre CVE-2026-63030 riguarda la route confusion dell’endpoint batch della REST API. Le versioni interessate dalla catena comprendono WordPress 6.9.x precedenti alla 6.9.5 e WordPress 7.0.x precedenti alla 7.0.2; la documentazione di sicurezza indica inoltre versioni interessate nel ramo 6.8, corrette con la successiva release di sicurezza. Il punto fondamentale è che non stiamo parlando di una vulnerabilità generica nella “deserializzazione dei token” della REST API, né di una semplice mancata validazione di oggetti arbitrari come potrebbe sembrare da una prima ricostruzione. Il problema documentato è più specifico e, proprio per questo, anche più interessante: una vulnerabilità nella gestione delle richieste batch della REST API può essere concatenata alla SQL Injection presente in WP_Query, trasformando una condizione che presa singolarmente potrebbe essere più difficile da sfruttare in una catena di attacco capace di arrivare alla Remote Code Execution. Searchlight Cyber ha descritto questa catena come una pre-authentication RCE, sottolineando inoltre che l’attacco può essere effettuato contro un’installazione WordPress di default senza richiedere plugin aggiuntivi o un account già compromesso.
Ed è proprio qui che la questione diventa seria: il problema non è più soltanto la presenza di una query manipolabile, ma la possibilità di concatenare più comportamenti del core fino a trasformare una richiesta proveniente da un utente anonimo in una condizione di compromissione molto più profonda.
La REST API come secondo anello della catena
La seconda vulnerabilità, CVE-2026-63030, riguarda l’endpoint batch della REST API e una condizione definita come route confusion. NVD descrive esplicitamente la vulnerabilità come una condizione che, combinata con la SQL Injection di author__not_in, può consentire ad un attaccante di eseguire SQL Injection e raggiungere la Remote Code Execution.
Questa distinzione è importante perché raccontare la vicenda come una singola “falla RCE” sarebbe tecnicamente impreciso. wp2shell non è una singola vulnerabilità, ma il nome con cui è stata indicata una catena composta da due vulnerabilità distinte che, sfruttate insieme, permettono ad un attaccante non autenticato di arrivare all’esecuzione di codice. Anche Akamai descrive l’evento proprio come una catena di RCE non autenticata composta da CVE-2026-63030 e CVE-2026-60137. Il passaggio è fondamentale perché ci ricorda una regola spesso dimenticata nella sicurezza informatica: una vulnerabilità non deve necessariamente essere devastante da sola per diventare devastante quando viene concatenata con un’altra. È la catena a fare la differenza.
La compromissione senza password
Ed è qui che torna il tema iniziale delle credenziali. Se l’attacco deve necessariamente passare da wp-login.php, l’amministratore può difendersi con password robuste, autenticazione a più fattori, limitazioni sull’accesso e altri meccanismi di protezione. Ma quando il vettore d’attacco si trova nel core e può essere raggiunto prima dell’autenticazione, queste difese possono semplicemente non entrare in gioco. L’attaccante non deve necessariamente “entrare” nel pannello amministrativo nel modo tradizionale: deve trovare un percorso attraverso il quale il software faccia per lui parte del lavoro.
Le analisi indipendenti pubblicate dopo la divulgazione di wp2shell descrivono proprio questa caratteristica: un attaccante anonimo può concatenare le due vulnerabilità del core e arrivare alla creazione di un contesto amministrativo non autorizzato e successivamente all’esecuzione di codice su un’installazione standard. Ed è questa, a mio avviso, la parte più inquietante della vicenda: non è necessario immaginare un attaccante che conosce già le nostre password, perché in determinate condizioni può essere il comportamento stesso del software a creare il percorso necessario per aggirare il modello di sicurezza che normalmente siamo abituati a considerare come prima linea di difesa.
La risposta con WordPress 7.0.2
A questo punto bisogna rimettere ordine anche nella cronologia delle release, perché la prima ricostruzione della vicenda può facilmente portare a confondere le versioni di manutenzione con le vere e proprie security release. WordPress 7.0.1 non è la release che corregge la catena wp2shell: la correzione arriva con WordPress 7.0.2, pubblicato il 17 luglio 2026. La stessa release viene presentata dal progetto come una security release destinata a risolvere un problema critico e uno ad alta gravità e, proprio in ragione della severità, il team WordPress.org dichiara di avere abilitato gli aggiornamenti forzati tramite il sistema di auto-update sulle installazioni interessate.
La parte interessante è che la stessa comunicazione ufficiale identifica una delle vulnerabilità come REST API batch-route confusion e SQL Injection con conseguente Remote Code Execution, mentre l’altra riguarda la SQL Injection facilitata nella gestione di WP_Query. Le correzioni sono state distribuite anche nel ramo 6.9 con la versione 6.9.5. E questo dettaglio cambia anche il modo in cui bisogna leggere l’intera vicenda. Non abbiamo davanti una singola patch che corregge un singolo bug, ma una situazione nella quale due difetti indipendentemente identificati possono essere concatenati per produrre un risultato molto più grave.
L’inefficacia delle difese tradizionali
Il tentativo di contenimento non può quindi essere valutato soltanto in termini di “abbiamo chiuso la porta”. La vulnerabilità non era una semplice esposizione del pannello amministrativo e non era necessario che l’attaccante conoscesse un account privilegiato. La questione riguardava il comportamento del core nell’elaborazione delle richieste e la possibilità di concatenare più condizioni fino ad arrivare all’esecuzione di codice.
In sintesi:
Una password più lunga non corregge una SQL Injection.
Una seconda autenticazione non corregge una route confusion.
Cambiare l’URL di wp-login.php non corregge una vulnerabilità nella REST API.
E nascondere l’endpoint di amministrazione non rende automaticamente sicuro un core vulnerabile.
Sono tutte misure che hanno un loro valore e che continuano ad essere consigliabili, ma non possono essere vendute come una protezione universale contro una vulnerabilità architetturale del software come quella descritta in questo abstract.
Il blocco dei processi di background in WordPress 7.0.3
La versione 7.0.3 è effettivamente una nuova security release di WordPress e arriva dopo la crisi di luglio con ulteriori correzioni di sicurezza, ma non sarebbe corretto attribuirle senza una fonte specifica un blocco generalizzato di WP-Cron, un loop infinito di wp-admin o un’interruzione irreversibile del sistema di aggiornamento automatico. Queste sono affermazioni molto precise e, in un nostro articolo che vuole mantenere un’impostazione forense e neutra, devono essere sostenute da evidenze indipendenti altrettanto precise attualmente non pubblicate (le prenderemo in considerazioni nelle prossime release di questo scritto nda.)
WordPress ha continuato a pubblicare security release ravvicinate mentre il ramo successivo era già in sviluppo, dimostrando quanto complesso sia gestire una superficie software di queste dimensioni quando emergono vulnerabilità direttamente nel core. La risposta non può quindi essere ridotta al semplice concetto di “rilascio della patch” come in qualche forum si è bisbigliato perché, per sua natura tecnologica, una patch deve essere distribuita, installata e verificata su un numero enorme di installazioni differenti prima di darle un voto.
La svolta verso WordPress 7.1
Anche il passaggio a WordPress 7.1 deve essere raccontato con attenzione. Non abbiamo elementi sufficienti per sostenere che il core-team abbia improvvisamente “saltato” il ramo 7.0 perché ormai impossibile da stabilizzare o che abbia riscritto integralmente l’architettura come risposta emergenziale alla crisi. Quello che possiamo documentare è che il ciclo di sviluppo di WordPress 7.1 era già in corso e che le versioni beta del nuovo ramo erano state coinvolte nella gestione delle vulnerabilità. La stessa comunicazione relativa a WordPress 7.0.2 indicava infatti che anche la beta di 7.1 era interessata dalle vulnerabilità e che la correzione era stata integrata nella successiva beta. Insomma la falla era proprio strutturale!
Ed ora?
Con le correzioni distribuite l’emorragia più immediata è certamente sotto controllo, ma questo non significa automaticamente che ogni installazione precedentemente esposta possa essere considerata innocua. Una patch corregge una vulnerabilità; non può cancellare retroattivamente ciò che un eventuale attaccante potrebbe avere fatto prima dell’aggiornamento.
E qui arriviamo alla domanda che, a nostro avviso, dovrebbe interessare maggiormente chi amministra un WordPress: il mio sito è semplicemente vulnerabile oppure è già stato compromesso?
Il problema dell’open-source
Un evento di questa portata non può che aprire un tavolo di discussione serio ed oggettivo sul valore dei contenuti open-source. Certamente liberi, certamente utilizzabili da tutte e tutti, certamente sottoposti ad una comunità enorme di sviluppatori e ricercatori, ma proprio per questo esposti ad una superficie di analisi altrettanto enorme da parte di chi cerca vulnerabilità per finalità offensive.
Open-source non significa automaticamente sicuro ma non significa nemmeno automaticamente insicuro. Insomma, un serpente che si mangia la coda.
Il vero punto è la qualità del processo che sta intorno al codice: revisione, audit, ricerca offensiva, gestione delle vulnerabilità, rapidità delle patch, capacità di distribuzione e soprattutto capacità di verificare che la correzione abbia realmente chiuso il problema e non soltanto il vettore osservato per primo. In questo senso la vicenda wp2shell è interessante proprio perché dimostra quanto possa diventare potente una catena composta da vulnerabilità differenti quando entrambe si trovano nel core del sistema.
E adesso tocca anche al core-team
Il core-team di WordPress, se vuole continuare a sostenere il ruolo centrale che il progetto ricopre nel web mondiale, dovrà necessariamente continuare ad alzare il livello del proprio lavoro sulla sicurezza, non soltanto attraverso patch rapide ma anche attraverso audit indipendenti, ricerca offensiva interna, threat modeling, revisione delle correzioni e una comunicazione sempre più trasparente nei confronti di chi gestisce le installazioni.
E qui non serve necessariamente cercare un colpevole ma serve pretendere che ogni passaggio possa essere verificato.
Serve che il vendor, il ricercatore indipendente, i database delle vulnerabilità e la comunità possano confrontarsi sullo stesso problema senza che una sola voce venga considerata sufficiente per chiudere la discussione. Perché quando una vulnerabilità del core può diventare una RCE pre-authentication, la domanda non è soltanto quanto rapidamente sia stata pubblicata la patch.
La domanda è quanto rapidamente sia stata compresa, quanto rapidamente sia stata distribuita e soprattutto quante installazioni siano rimaste esposte nel frattempo. Il dato spesso ripetuto sulla diffusione di WordPress rende questa domanda ancora più importante. Più grande è la superficie, maggiore è il prezzo di ogni errore.
E qui torniano alla frase che consideriamo più importante di tutta questa vicenda durante una call fra noi autori di questo scritto:
Sospettare è un bene, aspettare è saggio, risolvere senza sapere mediante AI è deficit tecnico.
L’intelligenza artificiale può aiutare a leggere codice, individuare anomalie, accelerare analisi e supportare gli sviluppatori, ma non può sostituire la comprensione tecnica del problema che si sta cercando di risolvere perché in sicurezza informatica la velocità è importante ma sapere esattamente cosa stai correggendo lo è molto di più. Decisamente!
Nel frattempo, controlla il tuo WordPress
Nel frattempo, chi gestisce un’installazione WordPress dovrebbe verificare immediatamente la versione del core e assicurarsi che il sistema sia stato aggiornato alla release corretta per il proprio ramo. La catena wp2shell è stata resa pubblica il 17 luglio 2026 e diversi operatori di sicurezza hanno successivamente pubblicato analisi, rilevazioni e indicazioni di mitigazione. Per una verifica pratica dell’esposizione è disponibile anche wp2shell.com, il sistema di controllo messo a disposizione dai ricercatori che hanno individuato e analizzato la catena. Un controllo automatico può dirti se l’installazione presenta le condizioni di esposizione note.
Fonti
NVD
CVE-2026-60137 — NVD
CVE-2026-63030 — NVD
Searchlight Cyber Security Research
wp2shell — Pre-Authentication RCE in WordPress Core
Akamai Security Intelligence Group
CVE-2026-63030 e CVE-2026-60137 — Mitigating a Critical Unauthenticated RCE Chain in WordPress
WordPress
WordPress 7.0.2 Security Release
wp2shell
Sistema di verifica wp2shell
Release abstract: 1.3.2 (ultimo aggiornamento 20 Agosto 2026 alle ore 12:36)
1.0: pubblicazione
1.1: correzione da parte di @msdvc e @falcogius della cronologia di catena bug
1.2: formattazione testo e controllo refusi ed errori di battitura mediante AI
1.3: correzione testo
1.3.1: pubblicazione con testo corretto da @msdvc su forma e linguaggio
1.3.2: upload @falcogius immagine schema di concatenazione degli eventi malevoli a mo’ dì riassunto
————
Ringrazio @john_bug @falcogius @joker_joint1312 per avermi aiutato a redigere questo documento. Questo articolo è stato corretto solamente per forma e per formattazione testuale da intelligenze artificiali partendo da un testo scritto dal team citato e dal sottoscritto, senza in alcun modo mettere al centro l’esperienza insufficiente degli strumenti free basati su prompt di intelligenze artificiali.
