WordPress wp2shell: RCE pre-auth, aggiorna alla 7.0.2 ora

Il 17 luglio, WordPress ha rilasciato la versione 7.0.2, e non si è trattato di un normale aggiornamento minore. Questo chiude una catena che i ricercatori hanno chiamato wp2shell: due bug che, combinati, permettono a un aggressore anonimo di eseguire codice su un'installazione WordPress predefinita. Nessun accesso. Nessun plugin vulnerabile. Nessun tema strano. Una singola richiesta POST alle REST API, e il server può ritrovarsi con un nuovo account admin e una shell che risponde ai comandi.

La catena coinvolge due CVE. CVE-2026-63030 è una confusione di route/handler nell'endpoint batch delle REST API, classificato come critico, introdotto nella versione 6.9. CVE-2026-60137 è un'iniezione SQL nella gestione di author__not_in da parte di WP_Query, classificata come alta, e risale fino alla versione 6.8. Presi singolarmente, ciascuno costituisce già un problema. Combinati, la confusione dell'endpoint batch separa la validazione dall'esecuzione e alimenta l'input non validato direttamente nell'iniezione SQL, permettendo l'esecuzione remota di codice senza autenticazione. WordPress ha abilitato gli aggiornamenti automatici forzati per i siti interessati, il che dice tutto su come il team core abbia valutato il rischio. Patchstack afferma di stare già osservando tentativi di sfruttamento nei propri log.

Ecco la mappa delle versioni. La catena RCE completa colpisce le versioni dalla 6.9.0 alla 7.0.1. Il ramo 6.8 porta solo l'iniezione SQL, non la confusione di route che la rende raggiungibile senza autenticazione. Le correzioni sono state rilasciate nelle versioni 6.8.6, 6.9.5 e 7.0.2, più una 7.1 beta2 per chi sta testando il ramo successivo. La confusione di route è stata segnalata da Adam Kues di Assetnote, il braccio di ricerca di Searchlight Cyber, tramite il programma HackerOne di WordPress. L'iniezione SQL è stata segnalata separatamente da TF1T, dtro e haongo.

Perché questa vulnerabilità è peggiore di un normale CVE WordPress

La maggior parte delle vulnerabilità di WordPress risiede nei plugin. È possibile fare un audit, bloccarli o rimuoverli. Questa è nel core, su un'installazione predefinita, raggiungibile prima dell'autenticazione. Questa combinazione è rara, ed è esattamente il profilo che gli aggressori automatizzano per primi. Un bug del core pre-autenticazione nella piattaforma che gestisce una buona fetta del web è un evento di scansione di massa, non mirato. Script pubblici di proof-of-concept sono apparsi entro un giorno o due dalla divulgazione, e gli aggiornamenti forzati raggiungono solo i siti che hanno gli aggiornamenti automatici attivi e che si connettono effettivamente. Molti non lo fanno.

C'è un dettaglio operativo degno di nota. Le segnalazioni relative al bug indicano che il percorso RCE è più facilmente raggiungibile quando un sito non utilizza una cache persistente degli oggetti, che è la configurazione predefinita per molte installazioni di piccole e medie dimensioni. Quindi i siti con minor probabilità di avere una configurazione sicura sono quelli più esposti. Questo corrisponde a quanto vediamo durante i test di penetrazione per studi di sviluppo di videogiochi: il rischio reale di solito risiede nella configurazione predefinita ordinaria, non nei casi limite esotici su cui tutti si concentrano.

Cosa fare questa settimana

Prima di tutto, applicare la patch. Se si utilizza WordPress dalla versione 6.8 alla 7.0.1 in qualsiasi ambiente, passare subito alla 7.0.2 o al backport corrispondente 6.9.5 o 6.8.6, senza aspettare la prossima finestra di manutenzione. Quindi verificare che l'aggiornamento sia stato effettivamente applicato. Gli aggiornamenti automatici forzati possono fallire silenziosamente dietro un reverse proxy o su un filesystem con permessi limitati, quindi controllare la versione riportata invece di fidarsi del fatto che il meccanismo abbia fatto il suo lavoro.

In secondo luogo, considerare che il periodo tra il rilascio della versione 6.9 e il 17 luglio sia stato una finestra aperta e cercare segni di una possibile intrusione. Verificare la presenza di utenti admin non riconosciuti, file imprevisti nella cartella wp-content/plugins/, e connessioni in uscita dall'host web che non si riescono a spiegare. Una patch pulita non annulla una compromissione già avvenuta, e questo bug lascia un aggressore con esattamente il tipo di accesso persistente che sopravvive a un aggiornamento.

In terzo luogo, mettere un controllo davanti all'applicazione, non solo al suo interno. Cloudflare ha rilasciato una regola WAF di emergenza il giorno della divulgazione. Quando configuriamo Cloudflare per clienti che necessitano di protezione DDoS e un WAF, una regola gestita per un CVE core recente come questo offre ore o giorni di copertura mentre una patch si distribuisce su una flotta di siti. Dal lavoro svolto su piattaforme di viaggio, quel periodo di virtual patch è spesso la differenza tra reagire in pochi minuti e reagire dopo i fatti.

Per i team che sviluppano in PHP in modo più generale, la vera lezione riguarda i confini di fiducia. Questa catena ha funzionato perché un livello di validazione e un livello di esecuzione non concordavano su cosa contenesse la richiesta. Vediamo la stessa classe di bug nelle applicazioni personalizzate in continuazione: l'input viene verificato in un posto e consumato in un altro, e i due si discostano finché un aggressore non riesce a inserire qualcosa nel mezzo. Nel nostro lavoro con PHP e Docker, l'abitudine che intercetta questo problema è trattare ogni richiesta come ostile finché il layer esatto che esegue la query non l'ha ri-validata. La validazione che avviene tre funzioni lontano dal database non è una validazione su cui si può fare affidamento.

Conduciamo questo tipo di revisione pre-autenticazione per clienti enterprise con reali requisiti di conformità, e il background del team consiste nel trovare la richiesta che non dovrebbe funzionare ma lo fa. Se «abbiamo applicato la patch, ma non siamo certi che nulla sia entrato prima» suona familiare, parliamone.