La vulnerabilità denominata wp2shell, scoperta da Searchlight Cyber con il supporto di OpenAI GPT 5.6 Sol e pubblicata il 17 luglio 2026, è attivamente sfruttata in-the-wild contro installazioni WordPress self-hosted nel cloud. Wiz Research ha documentato exploitation quasi immediata: webshell sofisticate, plugin malevoli e scanning di massa entro 24 ore dalla divulgazione. Il caso segna un punto di svolta nel rapporto tra discovery assistita da intelligenza artificiale e weaponizzazione da parte di attori di minaccia.
- CVE-2026-63030 (CVSS 9.8 CRITICAL) e CVE-2026-60137 (CVSS 5.9 MEDIUM) formano una catena RCE pre-autenticazione in WordPress Core, denominata wp2shell
- Il meccanismo centrale è la "batch-route confusion" nell'API REST: l'endpoint
/wp-json/batch/v1separa validazione ed esecuzione, permettendo SQL injection con escalation a privilegi admin - Wiz Research ha osservato exploitation attiva con webshell da 150KB mascherate da plugin CMSmap, user agent specifici e upload di plugin malevoli contro istanze cloud
- WordPress.org ha rilasciato le versioni 7.0.2, 6.9.5 e 6.8.6 con fix e abilitato l'aggiornamento forzato via auto-update: il 60% delle organizzazioni vulnerabili è sceso al 50% in 24 ore
"We've observed multiple actors successfully exploiting this vulnerability chain against WordPress instances self-hosted in the cloud" — Wiz Research
Il meccanismo: come la batch API tradisce la validazione
Il nucleo tecnico risiede nel comportamento dell'endpoint /wp-json/batch/v1 dell'API REST di WordPress. L'architettura batch processa richieste multiple in parallelo, ma separa la fase di validazione dei parametri dalla fase di esecuzione. Questa "batch-route confusion" permette di bypassare la funzione has_valid_params() su singole richieste interne al batch.
Una volta superato il controllo, l'attaccante inietta codice SQL che conduce a privilege escalation fino a privilegi amministrativi. Con accesso admin, l'RCE è raggiungibile attraverso upload di plugin malevoli o Local File Inclusion sul file wp-config. La catena è pre-autenticata su installazioni WordPress con configurazione default, secondo Wiz Research e confermata dall'advisory ufficiale di WordPress.org.
La fonte citata non specifica se varianti del meccanismo possano aggirare configurazioni con REST API disabilitata o hardening di endpoint. Il dossier non documenta inoltre l'esistenza di bypass per le patch rilasciate.
La scoperta: intelligenza artificiale come amplificatore di vulnerabilità research
Searchlight Cyber ha condotto la ricerca utilizzando OpenAI GPT 5.6 Sol, un modello di reasoning specializzato. La metodologia AI-assisted non ha sostituito il ricercatore umano — Adam Kues di Assetnote/Searchlight Cyber è creditato come reporter ufficiale — ma ha compresso i tempi di analisi del codice e identificazione del pattern di bypass.
Questo aspetto apre una questione strutturale per il settore. Se la scoperta di una catena RCE pre-autenticazione in un software con circa 500 milioni di istanze worldwide può essere accelerata da modelli di linguaggio, il divario temporale tra disclosure pubblica e weaponizzazione si restringe in modo misurabile. Nel caso wp2shell, la compressione è andata oltre la teoria: exploit POC sono apparsi "quasi immediatamente", secondo Wiz Research.
L'exploitation in-the-wild: webshell, IoC e post-exploitation
Wiz Research ha osservato una pluralità di attori, non attribuiti a gruppi specifici, impegnati in exploitation attiva contro istanze self-hosted nel cloud. La post-exploitation documentata include: upload di plugin malevoli, enumerazione utenti, LFI su wp-config e accesso al pannello di amministrazione.
Tra i payload rilevati figurano tre classi di webshell. La prima è un one-liner minimale che restituisce HTTP 404 per eludere detection superficiale. La seconda è una webshell di 150KB mascherata da plugin "CMSmap", con interfaccia grafica, autenticazione password, gestione file, accesso database, port scanning, injection batch di codice e moduli di privilege escalation. Il nome CMSmap impersona un legittimo progetto di auditing WordPress. La terza implementa un endpoint REST API custom /morning/v1/.
Gli indicatori di compromissione osservati includono risposte HTTP 207/200 agli endpoint batch e user agent contenenti le stringhe "wp2shell" e "rezwp2shell". Questi pattern, secondo Wiz Research, fungono da "reliable tool signatures identifying purpose-built exploitation frameworks".
Il brief non documenta se le webshell osservate siano correlate a campagne di minaccia preesistenti o rappresentino strumenti originari sviluppati per questa vulnerabilità.
Perché è importante
La fonte non specifica misure correttive operative al di là dell'aggiornamento del software. Il dossier non documenta raccomandazioni su Web Application Firewall, segmentazione di rete o hardening dell'API REST per istanze non aggiornabili immediatamente.
Il brief non indica inoltre se le webshell osservate abbiano comportato movimento laterale o esfiltrazione dati: Wiz Research afferma esplicitamente di non aver identificato tali attività allo stato attuale. La natura dei dati potenzialmente esposti tramite LFI su wp-config non è dettagliata dalla fonte.
L'identità degli attori rimane non determinata: "multiple actors" senza sovrapposizioni infrastrutturali documentate che colleghino l'attività a gruppi noti. Il movente — opportunismo diffuso versus interesse mirato — non è dichiarato testualmente.
La risposta di WordPress.org: patch e auto-update forzato
WordPress.org ha rilasciato le versioni 7.0.2, 6.9.5 e 6.8.6 correggendo la vulnerabilità. L'advisory ufficiale conferma la stessa natura tecnica — "REST API batch-route confusion and SQL injection issue leading to Remote Code Execution" — e accredita Adam Kues presso Assetnote/Searchlight Cyber.
Il sistema di auto-update ha abilitato l'aggiornamento forzato. Al momento della pubblicazione della vulnerabilità, circa il 60% delle organizzazioni con istanze WordPress aveva almeno un'installazione vulnerabile, e il 25% aveva server esposti direttamente a Internet. Entro 24 ore, le percentuali sono scese rispettivamente al 50% e al 10%, secondo Wiz Research. Questo dato indica una velocità di deployment superiore alla media storica per WordPress, probabilmente pilotata dalla criticità della vulnerabilità e dall'automatismo del vendor.
L'advisory ufficiale di WordPress.org menziona inoltre una vulnerabilità SQL injection facilitata, riportata da TF1T, dtro e haongo, distinta dalla catena wp2shell. Il dossier non chiarisce se questa seconda falla sia stata sfruttata in-the-wild o sia rimasta teorica.
La data esatta di pubblicazione dell'advisory WordPress.org non è rilevata nel testo fornito; il brief non la documenta.
Cosa cambia nel ciclo discovery-to-exploitation
Il caso wp2shell offre una misura empirica di quanto l'AI-assisted discovery stia modificando la geometria della sicurezza offensiva. Non si tratta della prima vulnerabilità trovata con supporto di modelli di linguaggio, ma è il primo caso documentato in cui la catena discovery-AI → pubblicazione → weaponizzazione in-the-wild si completa in circa 24 ore su una superficie d'attacco di mezzo miliardo di istanze.
Per le organizzazioni che gestiscono WordPress self-hosted, il parametro che si sposta non è solo la gravità della singola falla, ma la prevedibilità del tempo a disposizione. Se la finestra tra disclosure e exploitation attiva si misura in ore anziché in giorni, il patching reattivo diventa insufficiente per definizione. La fonte citata non specifica quali architetture difensive — se esistenti — abbiano resistito all'exploitation attiva, né raccomanda configurazioni preventive al di fuori dell'aggiornamento automatico.
Il dossier non documenta inoltre se le istanze cloud gestite da provider (managed WordPress) abbiano subito exploitation parallela rispetto alle installazioni self-hosted, o se la superficie self-hosted sia stata selezionata strategicamente dagli attori osservati.
Domande e risposte
Quali versioni di WordPress sono effettivamente vulnerabili?
Secondo Wiz Research: 6.8.0-6.8.5, 6.9.0-6.9.4, 7.0.0-7.0.1. WordPress.org conferma il rilascio delle patch 7.0.2, 6.9.5 e 6.8.6.
L'exploitation richiede condizioni specifiche?
La catena funziona su installazioni WordPress default con API REST attiva. Il brief non specifica se configurazioni con REST API disabilitata o plugin di hardening endpoint siano risultate efficaci barriera.
Chi ha sviluppato le webshell osservate?
Wiz Research non attribuisce i payload a gruppi identificati. Il dossier non documenta correlazioni tra le webshell e campagne di minaccia precedenti.
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://www.wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137
- https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/
- https://github.com/dionach/CMSmap
- https://github.com/alpha1e0/pentestdb/blob/master/webshell/php/%E5%85%8D%E6%9D%80php%E5%A4%A7%E9%A9%AC.php#L3
- https://wordpress.org/news/2026/07/wordpress-7-0-2-release/