- Un ricercatore ha guidato un modello AI alla scoperta di una catena di exploit zero-day su WordPress in circa 10 ore, con un costo di 25 dollari in token AI.
- L'attacco combinava un bypass della sanitizzazione nella batch API, una SQL injection pre-autenticata e una serie di comportamenti interni di WordPress per creare un account amministratore arbitrario.
- Il ricercatore umano è rimasto essenziale, ma l'esperimento mostra che il costo del lavoro investigativo preliminare è sceso in modo drastico, spostando l'equilibrio tra chi cerca vulnerabilità e chi deve correggerle.
Un ricercatore di sicurezza ha consegnato il codice sorgente di WordPress a un modello AI con un obiettivo preciso: trovare un percorso da una richiesta non autenticata fino all’esecuzione di codice remoto. Dopo poco più di 10 ore, il modello aveva assemblato una catena di exploit completa contro un’installazione predefinita del sistema di gestione dei contenuti più usato al mondo. Il costo dell’elaborazione: circa 25 dollari. Il valore di mercato di una vulnerabilità paragonabile, secondo quanto indicato da alcuni broker specializzati, può arrivare fino a 500.000 dollari.
Come un modello AI ha trovato l’exploit WordPress passo dopo passo
Il ricercatore Adam Kues non ha puntato uno scanner su un sito e atteso un’icona rossa. Ha scaricato il codice sorgente attuale di WordPress, rimosso la cronologia Git per impedire al modello di consultare patch o report di vulnerabilità noti e imposto un vincolo preciso: l’attacco doveva funzionare senza autenticazione su un’installazione MySQL standard. Questo ha escluso molte vulnerabilità che si attivano solo dopo il login o in configurazioni di database insolite.
Il primo punto critico riguardava la batch API di WordPress. Il sistema usa array separati per tracciare i gestori di richieste e i relativi risultati di validazione, e questi array possono essere disallineati inserendo una richiesta malformata. Il risultato pratico era un bypass della sanitizzazione: un input non sicuro poteva viaggiare oltre i limiti previsti dal sistema. Il modello ha poi collegato questo comportamento a un secondo errore nella gestione degli input, che permetteva a un valore non sanificato di raggiungere una query SQL. Con una tecnica di nesting, annidando una batch request dentro un’altra e sfruttando due volte il disallineamento di validazione, il modello ha prodotto una SQL injection pre-autenticazione capace di leggere valori arbitrari dal database.
Questo tipo di ricerca non è distante da quello che avviene con gli agenti AI autonomi: GPT-5.6 Sol ha aggirato i server di Hugging Face per manipolare i risultati di un test, un caso che mostra quanto questi sistemi siano già in grado di ragionare su contesti tecnici complessi.
Dalla lettura del database all’accesso amministratore: la parte più difficile
Una SQL injection è già un risultato serio, ma in questo caso forniva inizialmente solo accesso in lettura. Le password in WordPress sono memorizzate come hash, e forzarle può essere impraticabile. Il modello ha dovuto trovare un altro percorso.
Quello che è venuto dopo è la parte più difficile da seguire. La SQL injection poteva costruire record di post fittizi e inserirli nella cache temporanea in memoria di WordPress. Il modello ha poi usato il comportamento degli embed per trasformare alcuni di questi oggetti temporanei in record persistenti nel database. Creando una discrepanza tra il post in cache e quello salvato, l’exploit poteva influenzare il modo in cui WordPress riconciliava e aggiornava i due. Da lì, il modello ha collegato i changeset di personalizzazione del tema, la correzione dei cicli post-genitore e il sistema di hook dinamici di WordPress.
Il risultato finale: l’exploit spingeva WordPress a operare temporaneamente con i privilegi dell’amministratore principale, poi usava il hook parse_request per ripetere la richiesta batch originale durante quella finestra privilegiata. Una richiesta di creazione di un nuovo account amministratore falliva al primo passaggio perché veniva eseguita come ospite, ma riusciva quando ripetuta dentro quel contesto privilegiato. Una volta creato quell’account, era possibile caricare un plugin backdoor ed eseguire codice sul server.
Il ruolo del ricercatore umano: non è una dimostrazione di hacking automatico
Sarebbe semplice raccontare questa storia come: un’AI ha guardato WordPress, trovato uno zero-day e stampato un exploit funzionante. Non è quello che è successo. Kues ha scritto un prompt dettagliato, adattato idee da una ricerca esistente, fornito il codice sorgente, imposto vincoli precisi e diretto più agenti su parti diverse del problema per almeno sei ore. Il modello ha fatto molto lavoro, ma non è stato lasciato solo in una chat vuota con l’indicazione vaga di “bucare WordPress”.
Il risultato ha richiesto anche una verifica umana attenta. Kues ha riprodotto la SQL injection su un’installazione WordPress remota, ha confermato che poteva recuperare l’email dell’amministratore usata durante la configurazione, poi ha guidato il modello verso l’escalation. La SQL injection era relativamente comprensibile, ma i passaggi successivi gli hanno richiesto molto più tempo per essere compresi rispetto al tempo che il modello aveva impiegato per generarli. Questo divario è importante: una persona meno esperta avrebbe potuto ricevere lo stesso output senza alcun modo affidabile per distinguere se fosse brillante, difettoso o semplicemente plausibile.
Cosa cambia davvero nell’economia della ricerca sulle vulnerabilità
Il limite dell’esperienza umana rimane reale, ma perde molto del suo valore come barriera d’ingresso quando il lavoro investigativo sottostante diventa così economico. Un attaccante non ha bisogno che ogni tentativo vada a buon fine quando un’esecuzione lunga costa circa 25 dollari. Può puntare più run su applicazioni diverse, adattare i prompt, conservare i risultati intermedi utili e scartare i fallimenti.
Il modello ha anche aiutato con una delle parti più difficili della ricerca sugli exploit: tenere traccia di abbastanza comportamenti disconnessi in un codebase grande da costruire una catena completa. Questa vulnerabilità attraversava validazione API, costruzione di query SQL, caching degli oggetti, embed, riconciliazione dei post, changeset di personalizzazione, correzione della gerarchia, hook dinamici e dispatch delle richieste. Nessuno di questi elementi produceva l’esecuzione di codice remoto da solo. Il risultato dipendeva dall’individuare come potevano essere combinati in una sequenza molto specifica.
I vendor di software già faticano a processare i report sulle vulnerabilità, riprodurre bug complessi, costruire patch, testare le regressioni e convincere gli utenti ad aggiornarsi. L’AI può rendere la scoperta più economica senza rendere più facile nessuno di quei passaggi difensivi. Un ricercatore potrebbe spendere 25 dollari e mezza giornata per trovare una falla, mentre il vendor spende giorni a capire la catena e settimane a correggerla senza rompere altro. Questo squilibrio diventa problematico se il numero di report seri inizia a crescere.
WordPress rende il rischio più visibile perché il suo software core sta sotto un numero enorme di siti web. Kues ha ritardato la pubblicazione per dare agli utenti il tempo di aggiornarsi, ma altri ricercatori sono riusciti a riprodurre la catena prima che apparisse il proof-of-concept pubblico. Questo è utile per la validazione indipendente, ma mostra anche con quale velocità una scoperta custodita può diventare comprensibile a più persone.
L’aspetto più difficile da liquidare non è il dato dei 25 dollari in sé. È il divario tra il valore di un exploit e il costo della ricerca che lo porta alla luce. Quando quella ricerca diventa abbastanza economica da essere ripetuta senza troppa esitazione, i difensori non possono permettersi di continuare a lavorare ai ritmi di prima. Le vulnerabilità software sono sempre state un problema di risorse: ora quella bilancia si è spostata in modo misurabile e non a favore di chi deve tenere i sistemi al sicuro.
Soprattutto se aggiungiamo al dibattito un altro tema, quello dei guardrail dei modelli AI, che hanno dimostrato di poter frenare anche i ricercatori di sicurezza legittimi, creando un paradosso in cui chi lavora in modo responsabile viene rallentato mentre chi non ha intenzioni altrettanto trasparenti può aggirare quei limiti con meno difficoltà.
