Il 17 luglio 2026, giorno stesso della disclosure pubblica delle vulnerabilità WordPress CVE-2026-60137 e CVE-2026-63030, gli attaccanti hanno già iniziato a colpire. Entro sette giorni, i tentativi di exploit hanno superato i 45 milioni da quasi 150.000 fonti di rete uniche, secondo le analisi convergenti di Wordfence, Wiz e Bitdefender. La posta in gioco non è più la severità di una singola CVE, ma la velocità con cui l'automazione di massa ha compresso la finestra tra disclosure e compromissione a poche ore.
- Più di 45 milioni di tentativi di exploit nella prima settimana post-disclosure, circa 20 volte la scala di Drupalgeddon
- Gli attaccanti hanno iniziato a colpire il 17 luglio 2026, giorno stesso della disclosure, con exploitation di massa dal 18 luglio
- La catena combina CVE-2026-60137 (SQL injection, CVSS 5.9) e CVE-2026-63030 (REST API batch route confusion, CVSS 9.8)
- Il 60% delle organizzazioni WordPress in cloud aveva almeno un'istanza vulnerabile al momento della pubblicazione; entro 24 ore le percentuali erano scese a 50% e 10%
La scala dell'automazione: 45 milioni di tentativi e l'assenza di targeting
La campagna ha raggiunto una scala senza precedenti per il targeting di WordPress. Wordfence Firewall ha bloccato oltre 11 milioni di tentativi di exploit, ma questo dato si riferisce esclusivamente agli utenti Premium e rappresenta una stima parziale del volume totale. I dati di CyberSecurityNews indicano che la campagna ha superato i 45 milioni di tentativi nella prima settimana, con una moltiplicazione di circa 20 volte rispetto a Drupalgeddon.
Un elemento distintivo emerge dalla natura indiscriminata dello scanning: gli attaccanti hanno colpito anche ambienti Drupal con pattern URL WordPress-specifici, dimostrando l'assenza di ricognizione mirata. L'economia dell'attacco segue il paradigma "sparare ampio, poi identificare cosa ha funzionato", che inverte il modello tradizionale di identificazione preventiva del bersaglio.
La catena tecnica: da SQL injection a RCE completa
La vulnerabilità wp2shell si costruisce come catena di due falle distinte. CVE-2026-60137 è una SQL injection non autenticata che, isolata, ha un punteggio CVSS 5.9 MEDIUM secondo il record ufficiale CVE.org. La seconda componente, CVE-2026-63030, sfrutta una confusione nel routing batch delle REST API di WordPress. La combinazione delle due genera una catena con CVSS 9.8 CRITICAL, secondo l'analisi di Bitdefender.
Wordfence ha documentato entrambe le vulnerabilità con parametri e endpoint specifici, confermando la struttura tecnica della catena. Bitdefender MDR ha osservato un pattern operativo ripetuto: la catena di attacco veniva eseguita tre volte prima del successo completo, lasciando account amministratore orfani con prefisso 'w2s_' anche in casi di compromissione parziale.
Questo pattern ha una conseguenza investigativa concreta. Come riporta Bitdefender, "An orphaned w2s_-prefixed account on a server with no visible webshell is a confirmation that the server was targeted, the chain ran at least partway, and the attacker may return". L'account orfano non è un tentativo fallito da ignorare, ma un indicatore che l'attaccante può ripresentarsi.
La finestra di risposta compressa: ore, non giorni
La timeline dell'exploitation evidenzia la velocità della compressione. La disclosure è avvenuta il 17 luglio 2026. Gli attaccanti hanno iniziato a colpire il giorno stesso, con "only a small number of probing attempts on that first day", secondo Wordfence. L'exploitation di massa è iniziata il 18 luglio. CISA ha aggiunto entrambe le CVE al catalogo KEV il 21 luglio 2026, prima della disponibilità del PoC pubblico. Il PoC completo è stato pubblicato il 22 luglio 2026 da Icex0.
I dati di Wiz Research sul campione cloud mostrano la velocità di esposizione e reazione: al momento della pubblicazione, il 60% delle organizzazioni WordPress in cloud aveva almeno un'istanza vulnerabile, e il 25% esponiva un server vulnerabile a Internet. Entro 24 ore, le percentuali erano scese rispettivamente al 50% e al 10%. Il trend indica che una parte significativa delle organizzazioni ha reagito rapidamente, ma il margine di manovra è stato estremamente ridotto.
"Security teams must throw away vulnerability-management processes built around days or weeks of assessment and remediation. That timeline is no longer accurate. They now need to prepare for a response window increasingly measured in just hours." — Joey Stanford, CISO Pantheon
La scoperta con AI-assisted research e i limiti della narrazione
La vulnerabilità è stata scoperta da Searchlight Cyber usando OpenAI GPT 5.6 Sol, secondo Wiz. Tuttavia, le fonti convergenti specificano che l'AI non è l'unica responsabile della magnitudo dell'attacco: l'automazione preesistente e l'economia dell'attacco a largo raggio hanno un ruolo determinante. Non ogni vulnerabilità futura di CMS genererà decine di milioni di tentativi, come specificano le analisi, ma la compressione della finestra di risposta è un trend indipendente dalla singola campagna.
Wiz ha dichiarato di non aver identificato movimento laterale o data exfiltration nelle ambienti monitorati. Questo limite significa che il post-exploitation documentato si ferma alla creazione di account amministratore e all'installazione di plugin malevoli con webshell PHP. L'assenza di evidenza non esclude altri scenari, ma il dossier non documenta movimenti successivi.
Cosa fare adesso
Le azioni operative emergono direttamente dai dati delle fonti. La priorità è la verifica della presenza di account amministratore con prefisso 'w2s_' nei log WordPress: anche account orfani senza webshell visibile indicano targeting attivo e possibile ritorno dell'attaccante. La verifica della patch delle due CVE deve essere immediata per le istanze esposte a Internet, dato che il 25% delle organizzazioni cloud era vulnerabile al momento della disclosure.
L'architettura di contenimento acquista funzione critica come strato compensativo: WAF e segmentazione non sostituiscono il patching, ma comprano tempo durante la finestra di risposta compressa. Il monitoraggio dei tentativi ripetuti è essenziale: Bitdefender ha documentato che la catena veniva eseguita tre volte prima del successo completo, lasciando tracce investigabili.
Per le organizzazioni con istanze WordPress in cloud, la verifica della percentuale di esposizione deve includere il controllo del routing batch delle REST API, vettore specifico di CVE-2026-63030. La raccomandazione esplicita delle fonti è chiara: i layer di difesa sono complementari al patching, non alternativi.
Il punto di rottura del vulnerability management
I numeri di wp2shell non sono aneddotici. Quando 45 milioni di tentativi arrivano in sette giorni da 150.000 fonti diverse, la domanda non è quanto è grave la singola CVE, ma quanto tempo resta prima che l'automazione trovi un'istanza non patchata. Il CVSS 5.9 di CVE-2026-60137, se letto isolatamente, sottovaluta il rischio reale: la catena completa ha CVSS 9.8, e la velocità di exploitation ha reso la severità nominale irrilevante per la gestione operativa.
Il caso wp2shell segna un passaggio: la finestra di risposta misurata in ore non è più un'eccezione, ma il parametro di progettazione del vulnerability management. Le organizzazioni che calibrano i processi su giorni o settimane operano su una scala temporale che l'automazione di massa ha già reso obsoleta.
Fonti
- https://cybersecuritynews.com/what-45-million-wp2shell-exploit-attempts-reveal-about-the-new-vulnerability-response-window/
- https://www.wordfence.com/blog/2026/07/wp2shell-wordpress-exploit-technical-analysis-and-real-attack-data/
- https://www.wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137
- https://businessinsights.bitdefender.com/technical-advisory-wp2shell-unauthenticated-remote-code-execution-full-site-takeover-wordpress-core
- https://www.cve.org/CVERecord?id=CVE-2026-60137
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- https://www.wordfence.com/products/wordfence-premium/
- https://www.wordfence.com/products/wordfence-care/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.