wp2shell: una RCE su WordPress standard, scoperta in dieci ore per 25 dollari

Il 17 luglio 2026 Searchlight Cyber ha pubblicato wp2shell, una catena di esecuzione di codice remoto pre-autenticazione nel core di WordPress che non richiede alcun plugin, alcun tema e alcun accesso. È sufficiente una richiesta anonima contro un'installazione standard: "L'attacco non ha precondizioni e può essere sfruttato da un utente anonimo in un'installazione standard di WordPress senza plugin", afferma l'avviso dell'azienda. La catena unisce due bug — CVE-2026-63030, un difetto di confusione di route nell'endpoint batch dell'API REST di WordPress, che l'avviso del progetto classifica come critico, e CVE-2026-60137, un'iniezione SQL nel parametro author__not_in di WP_Query, che classifica come moderato. WordPress ha rilasciato WordPress 7.0.2 lo stesso giorno, e gli avvisi del progetto elencano WordPress 6.9.5, WordPress 6.8.6 e WordPress 7.1 beta2 come versioni contenenti le stesse correzioni. Searchlight cita stime di oltre 500 milioni di siti WordPress. Il ricercatore dietro la catena, Adam Kues, afferma che è emersa da un'esecuzione di GPT-5.6 Sol Ultra basata su un prompt che OpenAI aveva pubblicato per un problema di matematica: fino a quattro agenti, almeno sei ore di ricerca e circa altre quattro per l'escalation, circa 25 dollari di utilizzo del modello. Il record è registrato come un risultato di ricerca — gravità alta sulla scala dell'archivio stesso, affidabilità di grado A, nessun danno reale registrato, datato a un singolo giorno — e l'Orca AI Incident Archive lo riporta con i documenti primari collegati sotto.

La divulgazione è stata coordinata. Searchlight ha taciuto i meccanismi il 17 luglio e ha concesso ai difensori il fine settimana per aggiornare; Kues ha pubblicato il resoconto tecnico completo il 20 luglio. A quel punto l’exploit a catena era già stato riprodotto in modo indipendente: Searchlight afferma che Calif e Hacktron hanno ricostruito l’intera catena prima che altre proof of concept emergessero su GitHub. I due avvisi di sicurezza di WordPress indicano le stesse versioni corrette, e CISA ha aggiunto entrambe le CVE al suo catalogo Known Exploited Vulnerabilities il 21 luglio.

Due bug e gli array che perdono il passo

Il punto di ingresso è una funzionalità, non un errore. WordPress 5.6 ha introdotto l'endpoint batch nel 2020 affinché un client potesse inviare diverse richieste REST virtuali all'interno di un'unica richiesta HTTP, ad esempio per cambiare il titolo a una serie di post in una sola volta. L'endpoint è raggiungibile indipendentemente dal fatto che il chiamante sia autenticato, e ciascuna sotto-richiesta trasporta l'autenticazione fornita dal chiamante. Una richiesta diretta a una route REST di WordPress esegue una pipeline in quattro fasi: verifica i parametri obbligatori e validi, li sanitizza, esegue il callback di autorizzazione, quindi esegue il callback dell'endpoint. Gli endpoint si affidano a quella pipeline per le proprie assunzioni sui tipi: che un ID di post sia un intero, che un titolo sia una stringa.

L'API batch divide la pipeline in due fasi, convalidando ogni sotto-richiesta in un ciclo ed eseguendole in un secondo, e mantiene due array, $matches e $validation, le cui voci dovrebbero corrispondersi indice per indice. In class-wp-rest-server.php, come lo descrive Kues, una sotto-richiesta che è essa stessa un errore di WordPress viene aggiunta a $validation e poi incontra un continue, saltando la riga che aggiunge a $matches. Da quel momento ogni corrispondenza è spostata indietro di una posizione. Il ciclo di esecuzione abbina la sotto-richiesta a un indice con la convalida registrata a quell'indice, ma il gestore corrisponde a una route diversa — quindi un parametro viene verificato secondo le regole di un endpoint e poi eseguito dal codice di un altro.

È questo che trasforma un parametro di elenco dall'aspetto ordinario in un'iniezione. La route della raccolta dei post mappa il suo argomento pubblico author_exclude su author__not_in. Quando il valore è un array, WordPress applica absint a ogni elemento e li ordina; quando il valore è uno scalare, viene concatenato senza modifiche nel frammento SQL che diventa NOT IN ($author__not_in). Una stringa come 0) OR 1=1 -- finisce quindi nel testo della query. Chiamata normalmente, la route la rifiuterebbe, perché author_exclude deve essere un array di interi; è la chiamata batch desincronizzata a lasciar passare una stringa.

Restavano due ostacoli, ed entrambi sono stati risolti annidando il trucco. L'API batch rifiuta le richieste GET, e l'iniezione risiede su una rotta GET; inoltre, la validazione del metodo della richiesta è essa stessa implementata come validazione dei parametri, che la stessa desincronizzazione può aggirare. Il payload pubblicato da Kues invia una sottorichiesta esterna malformata per desincronizzare il controllo del metodo, poi un batch interno la cui seconda sottorichiesta trasporta l'author_exclude malevolo contro un handler che non lo convalida, poi la GET che esegue l'iniezione. Un'iniezione basata su UNION restituisce valori arbitrari del database all'interno di righe strutturate come post ordinari.

L'esecuzione del modello: un prompt matematico, indirizzato a una base di codice

Kues non ha scritto il prompt da zero. OpenAI aveva pubblicato il prompt che aveva usato mentre lavorava alla congettura Cycle Double Cover, e Kues ha scritto di aver letto che il modello aveva recentemente risolto quella congettura e che nessuno nella comunità della sicurezza sembrava parlare di quel prompt. Il suo ragionamento era che se andava bene per la matematica difficile, probabilmente andava bene anche per la ricerca sulla sicurezza. Lo ha adattato e lo ha indirizzato a WordPress.

La configurazione era deliberatamente ristretta. Clonò l'ultima versione stabile di WordPress in una directory chiamata main/ ed eliminò la sua directory .git, dicendo al modello di non usare changelog, cronologia git o Internet aperto per confrontare il codice con una versione con patch — la sua motivazione dichiarata era che, per la scoperta di vulnerabilità nuove, consultare la cronologia o il web è uno spreco di token. Fu messa a disposizione una directory vuota third_party/ affinché il modello potesse clonare dipendenze come il codice sorgente di PHP o MySQL se riteneva che la catena necessitasse di bug nelle librerie sottostanti a WordPress. Il compito era specificato come RCE pre-autenticazione in una tipica distribuzione di produzione su MySQL, con un massimo di quattro agenti e almeno sei ore. Kues scrisse che dichiara esplicitamente il requisito di configurazione perché altrimenti i modelli "barano" — scegliendo opzioni di configurazione estremamente improbabili o fabbricando precondizioni che un attaccante non potrebbe mai raggiungere.

Ciò che è emerso, nell'output in esecuzione, era l'affermazione di un'iniezione SQL pre-autenticazione. Kues ne dubitava: WordPress è tra gli obiettivi più intensamente verificati di sempre, scrisse, e non aveva avuto una vulnerabilità pre-autenticazione significativa in quel decennio. Installò un'istanza standard di WordPress su un server remoto e chiese al modello di rubare l'email dell'amministratore; nel giro di un paio di minuti il modello stampò l'indirizzo che aveva usato per configurare l'istanza. Poi chiese se l'iniezione di sola lettura potesse essere escalata, e circa quattro ore dopo il modello rispose che poteva — a livello di amministratore, senza craccare alcuna password e senza calcolo offline.

Il suo calcolo dei costi: il 50% di una quota di utilizzo settimanale, che ha stimato in circa 25 dollari pro rata su un abbonamento da 200 dollari, per un exploit prodotto in poco più di dieci ore. La parte umana non è stata gratuita — Kues ha trascorso il giorno successivo a decifrare ciò che aveva fatto il modello, e ha scritto che il lavoro di post-sfruttamento gli richiese molto più tempo per essere compreso di quanto ne fosse servito per generarlo. Il suo verdetto è insolitamente schietto e rigorosamente circoscritto: «Non faccio affermazioni generali, ma posso dire con assoluta certezza che nessun ricercatore di sicurezza avrebbe potuto individuare e completare questa catena di exploit in 10 ore senza l'IA.»

Da una SELECT di sola lettura ad amministratore

L'escalation è la parte del resoconto che conta di più, perché è il punto in cui una lettura del database è diventata il controllo del server. Il resoconto di Kues la presenta come una sequenza di sei mosse, ciascuna delle quali usa una normale funzionalità di WordPress contro un'altra.

Per prima cosa, avvelena la cache in memoria dei post. WordPress mantiene una cache per richiesta di oggetti WP_Post, così che lo stesso post a cui si fa riferimento più volte in una richiesta costi un solo round trip al database. L'iniezione SQL può fabbricare post, quindi l'attaccante controlla esattamente ciò che viene messo in cache — ma quei post fabbricati non sono righe nel database, e la cache muore con la richiesta.

In secondo luogo, trasformare i post fabbricati in righe reali.La funzionalità di embed di WordPress memorizza nella cache gli embed risolti nel database come post di tipo oembed_cache. L'incorporamento di un post locale tramite percorso relativo, come in [embed]/?p=S[/embed], fa sì che WordPress salti il recupero HTTP e non verifichi mai che il post a cui si fa riferimento esista, quindi viene creata una riga. Tre embed di questo tipo con token di query string diversi producono tre hash della cache diversi, ed è così che l'attaccante ottiene diverse righe con cui lavorare.

Terzo, aggira l'unico campo che resta fisso. Quando la versione in memoria e quella nel database di un post non concordano, WordPress le riconcilia con una chiamata che imposta esplicitamente post_content a partire dall'output dell'embed. Ogni aspetto del post è controllato dall'attaccante tranne il suo contenuto, che è precisamente il campo che un customize_changeset usa per memorizzare il JSON delle modifiche in sospeso al tema e al sito.

Quarto, il congegno del ciclo. I post hanno un genitore, e WordPress rifiuta i cicli: il wp_insert_post_parent filtro risale l'albero e, quando trova un ciclo, chiama un aggiornamento che imposta post_parent a zero. Quella chiamata non sovrascrive post_content, quindi la versione fabbricata in memoria sopravvive alla riconciliazione — un changeset, con il suo JSON intatto, supportato da una riga reale.

Quinto, prendi in prestito l'autorità dell'amministratore. Un changeset il cui stato indica che è programmato per il futuro ma la cui data è nel passato viene applicato immediatamente. Ogni voce nel suo JSON indica un user_id, e la voce nella catena di Kues indica user_id 1, l'amministratore, quindi WordPress adotta temporaneamente tale identità per applicare la modifica. La prima modifica è un aggiornamento apparentemente innocuo a nav_menus_created_posts.

Sesto, riproduci la richiesta con quell'identità. La pubblicazione di un post attiva un'azione dal nome dinamico, {status}_{post_type}. Poiché il post è forgiato, quello status e quel tipo possono essere qualsiasi cosa — incluso parse e request, il che produce l'hook parse_request e riavvia la pipeline della richiesta dall'inizio mentre l'identità amministratore presa in prestito è ancora attiva. La richiesta batch originale conteneva una sotto-richiesta che creava un nuovo amministratore; è fallita al primo passaggio come ospite e riesce durante la riproduzione. Da lì l'attaccante accede come quel nuovo account e carica un plugin backdoor da un file ZIP, il che equivale a esecuzione di codice.

La tecnica ha una condizione associata. The Hacker News, citando Cloudflare, ha riportato che CVE-2026-63030 consente l'esecuzione di codice remoto solo quando non è in uso una cache degli oggetti persistente; l'iniezione stessa è presente a partire da WordPress 6.8, mentre la catena completa richiede la versione 6.9 o successiva. Un'installazione standard non dispone di una cache degli oggetti persistente, motivo per cui la formulazione "senza precondizioni" di Searchlight e la precisazione di Cloudflare descrivono lo stesso caso predefinito da prospettive diverse.

Ciò che stabiliscono i documenti primari

Gli avvisi di WordPress stesso sono la conferma più forte, perché rappresentano il fornitore che ammette i meccanismi e distribuisce la correzione. GHSA-ff9f-jf42-662q, classificato critico, descrive una debolezza di confusione tra route batch dell'API REST in WordPress 6.9 e versioni successive che, combinata con l'iniezione, consente di arrivare all'esecuzione di codice, e riconosce il merito ad Adam Kues di Assetnote e Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, classificato moderato, descrive l'iniezione tramite author__not_in a partire da WordPress 6.8 e versioni successive, e afferma che entrambi i problemi sono corretti in WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 e WordPress 7.1 beta2. I record NVD per le due CVE, con punteggi assegnati dal CNA di WPScan anziché da NIST, riportano 9,8 per CVE-2026-63030 con il vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, e 5,9 per CVE-2026-60137 con AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — una vulnerabilità raggiungibile dalla rete e che non richiede privilegi nel primo caso, e una che richiede elevata complessità di attacco e produce solo un impatto sulla riservatezza nel secondo. Il campo di gravità dell'archivio per questa voce riporta alta mentre WordPress classifica critica la falla batch; le due sono scale separate applicate a una catena completa e a un singolo componente, non un disaccordo sulle vulnerabilità stesse.

Le voci del catalogo della CISA, come riportate nei campi di arricchimento dell'NVD, sono state aggiunte il 21 luglio 2026 con scadenze di correzione fissate al 24 luglio per CVE-2026-63030 e al 4 agosto per CVE-2026-60137. La CISA denomina la prima "WordPress Core Interpretation Conflict Vulnerability" e la seconda "WordPress Core SQL Injection Vulnerability". Searchlight ha inoltre pubblicato uno strumento di verifica pubblico su wp2shell.com affinché gli operatori potessero testare un'istanza senza attendere una firma dello scanner.

La riproduzione indipendente è documentata da Searchlight stesso e costituisce quindi un’affermazione riguardante terzi anziché un resoconto di terzi: secondo l’articolo del 20 luglio, Calif e Hacktron hanno ricostruito l’intera catena prima che altre proof of concept comparissero su GitHub. Ciò che è verificabile in modo indipendente è l’effetto: proof of concept, traffico di sfruttamento e telemetria dei fornitori nel giro di pochi giorni, descritti di seguito.

Ciò che è affermato ma non stabilito

Due attribuzioni per una sola iniezione non concordano nella documentazione pubblica. L'avviso di WordPress per CVE-2026-60137 afferma che la vulnerabilità è stata «scoperta e divulgata in modo responsabile come team da TF1T, dtro e haongo». Il resoconto di Searchlight presenta la stessa iniezione pre-autenticazione come quanto emerso dall'esecuzione del suo modello, e non menziona quel team; l'avviso di WordPress attribuisce a Kues solo la confusione della route batch, e non menziona alcun modello. Nessuno dei due documenti spiega la sovrapposizione, e nulla di quanto individuato in questo articolo la risolve: non è esclusa la possibilità che i due siano stati ritrovamenti indipendenti dello stesso bug, né è stabilita la possibilità che uno dei due report sia una riscoperta successiva. La documentazione non lo dirime, e nemmeno questo articolo lo fa.

La cifra in evidenza nel post del 20 luglio di Searchlight non è supportata dal testo stesso. Si legge: «I broker di exploit pagano 500.000 dollari per un RCE di WordPress. Ne ho trovato uno con GPT5.6 Sol Ultra e 25 dollari». Il testo documenta i 25 dollari e le dieci ore in termini specifici; non riporta nomi di broker, offerte, corrispondenza né una fonte per la cifra di 500.000 dollari. Non è stato individuato alcun report indipendente su questo pezzo che corrobori un prezzo pagato o offerto per wp2shell. La cifra di 500.000 dollari va letta come impostazione del titolo, non come prezzo di mercato consolidato.

La portata della voce d'archivio è più ristretta della storia che la circonda. Registra un risultato di ricerca il giorno della divulgazione, non segnala alcun danno nel mondo reale ed è datata a un unico giorno, il 17 luglio 2026. Ciò non significa che dopo non sia successo nulla: il traffico di sfruttamento è stato segnalato entro poche ore dall'avviso e CISA ha catalogato entrambe le CVE quattro giorni dopo. Il flag copre ciò che la voce descrive — la scoperta e la divulgazione coordinata — e il successivo sfruttamento è documentato da altre parti sulla base delle proprie prove, di seguito.

Sfruttamento dopo l'avviso

Jake Knott, ricercatore principale per la sicurezza presso watchTowr, ha dichiarato a The Hacker News che «nelle prime ore di sabato mattina (UTC), lo sfruttamento era già ampiamente in corso, inizialmente con l'uso di codice exploit pubblico per esfiltrare credenziali con hash, seguito dall'esecuzione di codice remoto una volta resi pubblici ulteriori dettagli». Lo stesso report cita la telemetria di KEVIntel che collega 13 indirizzi IP unici, provenienti da Svizzera, Germania, Regno Unito, Indonesia, Lituania, Paesi Bassi e Singapore, allo sfruttamento di CVE-2026-63030, e cita Ryan Dewhurst, fondatore di KEVIntel, secondo cui le richieste corrispondevano a proof of concept disponibili pubblicamente e sono stati usati payload di tipo blind, basati su UNION e basati su boolean.

I ricercatori di Wiz Shahar Dorfman e Gili Tikochinski, in un articolo pubblicato il 20 luglio, hanno quantificato la portata: il 60% delle organizzazioni che usano WordPress aveva almeno un'istanza vulnerabile al momento della pubblicazione delle CVE e il 25% stava esponendo un server vulnerabile a Internet, scendendo al 50% e al 10% entro 24 ore dall'inizio dell'applicazione delle patch. Hanno registrato caricamenti malevoli di plugin tramite l'installer dell'amministratore, enumerazione degli utenti contro l'endpoint users, tentativi di local file inclusion ai danni di wp-config, e l'accesso al pannello di amministrazione che restituiva HTTP 200 — la firma di un accesso riuscito anziché di una sonda. Il malware che hanno trovato spaziava da una backdoor PHP minima di una riga a una webshell da 150 KB mascherata da plugin di sicurezza WordPress legittimo chiamato CMSmap, con moduli per la gestione dei file, l'accesso al database, la scansione delle porte e l'escalation dei privilegi.

Wiz ha anche registrato un limite a ciò che si può concludere. Le scansioni ad alto volume senza post-exploitation erano comuni, coerenti con una scansione di massa opportunistica e con una scansione di sicurezza legittima, e la società ha dichiarato di non aver identificato movimento laterale né esfiltrazione di dati. Questa è un'affermazione su ciò che ha mostrato la telemetria di un fornitore, non una constatazione che non sia stato sottratto nulla.

Cosa è cambiato in seguito, e cosa è rimasto aperto

Per gli operatori, il percorso di risposta era breve. L'aggiornamento a WordPress 7.0.2, WordPress 6.9.5 o WordPress 6.8.6 è la soluzione. Le alternative di emergenza di Searchlight, per i siti che non potevano aggiornare immediatamente, consistevano nel bloccare l'accesso anonimo all'API batch — o installando un plugin che blocchi completamente l'accesso anonimo all'API REST, oppure bloccando /wp-json/batch/v1 e ?rest_route=/batch/v1 a livello di un web application firewall. L'azienda ha avvertito che entrambe possono incidere sull'uso legittimo del sito e dovrebbero essere considerate misure temporanee fino alla distribuzione dell'aggiornamento. Il verificatore pubblico su wp2shell.com testa direttamente un'istanza. Le voci del catalogo CISA hanno introdotto una scadenza per la conformità: correzione entro il 24 luglio per CVE-2026-63030 ed entro il 4 agosto per CVE-2026-60137.

La parte della domanda di ricerca che non è stata risolta è ciò che il modello ha effettivamente contribuito rispetto al suo operatore. Kues è preciso sulla divisione: il modello ha prodotto la catena in circa dieci ore, e capirla gli ha richiesto più tempo di quanto ne avesse impiegato a generarla. Rifiuta affermazioni generali e dice soltanto che il risultato delle dieci ore non era raggiungibile da un essere umano senza assistenza. Il prompt stesso non è un segreto — deriva da uno pubblicato da OpenAI, e Searchlight ne ha riprodotto la struttura nel resoconto, inclusa l'istruzione di ignorare la cronologia delle versioni e il requisito che l'exploit funzioni in una tipica configurazione di produzione. Se quella ricetta si trasferisca ad altre basi di codice è esattamente la domanda a cui Kues dice di non rispondere, e nessuna seconda esecuzione è stata pubblicata.

Ciò che il verbale lascia non stabilito è quindi limitato ma rilevante: quale dei due soggetti accreditati abbia individuato per primo l’iniezione, se qualche broker abbia mai pagato la cifra indicata nel titolo e cosa, ammesso che vi sia qualcosa, le webshell osservate da Wiz abbiano effettivamente sottratto ai siti su cui sono atterrate. Sull’ultimo punto l’unica dichiarazione pubblica è quella di Wiz, secondo cui non ha identificato alcun movimento laterale né esfiltrazione di dati: un’assenza di prove da un unico punto di osservazione, presentata come tale.