WordPress ha corretto venerdì, gli exploit sono arrivati domenica

Venerdì, alle sei meno un quarto di sera

Il 17 luglio 2026 WordPress ha rilasciato un aggiornamento di sicurezza per due vulnerabilità del core. Il team di ricerca di Searchlight Cyber, che ha individuato la più grave delle due, l'ha battezzata wp2shell. Gli identificativi assegnati sono CVE-2026-63030, una route confusion nell'endpoint batch della REST API combinata con una SQL injection, e CVE-2026-60137, una SQL injection raggiungibile attraverso il parametro author__not_in di WP_Query.

Alle 17:45 ora della costa orientale degli Stati Uniti, lo stesso giorno della patch, Rapid7 ha pubblicato la propria analisi mettendo a verbale due cose. I dettagli tecnici dell'exploit non erano ancora stati resi pubblici, e non risultava sfruttamento confermato pubblicamente in the wild. Chi ha letto quella valutazione venerdì aveva ottime ragioni per credere di avere davanti una normale settimana lavorativa in cui pianificare l'aggiornamento.

Non era così. PatchStack ha iniziato a segnalare lo sfruttamento di entrambi i CVE poco prima delle 19, ora della costa orientale, la stessa sera, circa un'ora dopo l'istantanea scattata da Rapid7. Entro domenica 19 luglio VulnCheck aveva verificato oltre due dozzine di exploit proof of concept distinti che prendevano di mira la falla.

Due bug, e la vostra versione ha due risposte diverse

Quasi tutta la copertura mediatica tratta la vicenda come un evento solo, con un nome solo. Sono invece due vulnerabilità con portata diversa, ed è quella differenza a stabilire che cosa dovete fare davvero. Sbagliare in un senso o nell'altro costa un fine settimana buttato oppure un buco lasciato aperto.

CVE-2026-63030, la catena che porta all'esecuzione di codice da remoto, riguarda WordPress dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1. È corretta nella 6.9.5 e nella 7.0.2, e sulla linea beta 7.1 nella Beta 2. CVE-2026-60137, la SQL injection in WP_Query, arriva più indietro. Riguarda anche le versioni dalla 6.8.0 alla 6.8.5, oltre agli stessi intervalli 6.9 e 7.0, e per il ramo più vecchio la correzione è la 6.8.6.

La conseguenza pratica è che un sito fermo alla 6.8.x legge i titoli su wp2shell, controlla se rientra nell'intervallo 6.9 o 7.0, conclude di non essere interessato e si ferma lì. Quel sito non è esposto alla catena completa di esecuzione di codice non autenticata, ma è esposto alla SQL injection, e deve comunque passare alla 6.8.6. I controlli di versione fatti sul CVE sbagliato sono il modo più probabile in cui un'organizzazione sbaglierà questa settimana.

La rete di protezione copre i siti che contano di meno

I manutentori di WordPress hanno reagito forzando l'aggiornamento sulle installazioni interessate che avevano gli aggiornamenti automatici attivi. È la scelta giusta e avrà protetto un numero enorme di siti durante il fine settimana senza che nessuno li toccasse.

Guardate però quali siti non ha protetto. Gli aggiornamenti automatici vengono disattivati di proposito, e le ragioni sono sempre le stesse: un processo di change control, un plugin che si era rotto con una minor release precedente, una pipeline dallo staging alla produzione, un contratto di agenzia che affida a una persona la responsabilità degli aggiornamenti, un regime di conformità che vieta modifiche non revisionate in produzione. Ognuna di queste ragioni è il segnale di un'installazione che qualcuno considera abbastanza importante da gestire.

La rete automatica di protezione, quindi, è inversamente correlata alla criticità per il business. Il blog amatoriale si è aggiornato da solo venerdì sera. Il portale clienti, il sistema di prenotazione e il sito che incassa i pagamenti sono rimasti su una versione vulnerabile per un intero fine settimana, quello in cui il codice di attacco funzionante è passato da zero a oltre due dozzine. Se la vostra organizzazione ha disattivato gli aggiornamenti automatici come segno di maturità, questo è il fine settimana in cui quella scelta vi ha presentato il conto.

Che cosa misura davvero la curva del fine settimana

Il numero utile qui non è un punteggio CVSS, e del resto i vendor non concordano nemmeno del tutto sulla gravità. Rapid7 registra un CVSS 7.5 per la catena di esecuzione di codice da remoto, mentre l'advisory corrispondente la tratta come critica, e VulnCheck considera la SQL injection la più critica delle due. Discutere su quale cifra scrivere nel ticket è un pessimo impiego del tempo che vi resta.

Il numero che conta è l'intervallo tra la patch e la trasformazione in arma. Qui si è misurato in ore per le prime segnalazioni di sfruttamento e in circa due giorni per l'ampia disponibilità pubblica di exploit. È questo il livello di servizio reale che il vostro processo di patching deve rispettare, e la policy dichiarata di quasi nessuna organizzazione ci arriva. Una finestra di rimedio di trenta giorni, comune nei framework di conformità, non è una policy di patching per un bug come questo. È la descrizione di quanto a lungo siete rimasti esposti.

Negli exploit più recenti c'è un secondo dettaglio che chiude anche il ripiego abituale. VulnCheck riferisce che entro domenica erano comparse ulteriori implementazioni di esecuzione di codice da remoto capaci di aggirare del tutto l'autenticazione dell'amministratore. I team che contavano di appoggiarsi ad account admin blindati, a pagine di login ad accesso ristretto o al secondo fattore su wp-admin come controllo compensativo devono rendersi conto che quelle misure non si trovano sul percorso di questo attacco.

Quattro cose che oggi vale la pena fare

Primo, fate l'inventario prima di patchare. Trovate ogni installazione WordPress che la vostra organizzazione possiede davvero, compresi i microsito di marketing, le landing page delle campagne, il sito del convegno di due anni fa e qualunque cosa abbia costruito un'agenzia che nel frattempo se n'è andata. L'installazione vulnerabile non è quasi mai quella censita nel registro degli asset. È quella che nessuno si ricordava fosse ancora online a servire traffico.

Secondo, verificate ciascuna installazione sul CVE giusto. Tutto ciò che sta sulla 6.8.x va portato alla 6.8.6. Tutto ciò che sta sulla 6.9.x va portato alla 6.9.5. Tutto ciò che sta sulla 7.0.x va portato alla 7.0.2. Non lasciate che una sola assunzione sull'intervallo di versione copra l'intero parco installato.

Terzo, trattate qualsiasi installazione non patchata rimasta esposta a internet nel fine settimana come potenzialmente compromessa e non semplicemente come vulnerabile, e andate a cercare le prove invece di darne per scontata l'assenza. La patch chiude la porta. Non fa uscire chi è già entrato. Quarto, ed è il punto che dura nel tempo, mettete per iscritto quale sia stato il tempo reale di applicazione della patch nella vostra organizzazione per questo evento e confrontatelo con il numero che pubblicate nella policy. La distanza tra le due cifre è la cosa da correggere, perché la prossima vulnerabilità del core correrà sullo stesso orologio.

Da leggere ora: La patch nginx è uscita, l'exploit arriva ad agosto  |  ServiceNow ha corretto prima il proprio cloud, voi 103 giorni più tardi