WordPress wp2shell: RCE in-the-wild entro 24 ore dalla scoperta AI

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.

"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.

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".

Perché è importante

La fonte non specifica misure correttive operative al di là dell'aggiornamento del software.

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.

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.

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.

Chi ha sviluppato le webshell osservate?

Wiz Research non attribuisce i payload a gruppi identificati.

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/