wp2shell: Come una sessione AI da $ 25 Wobbles milioni di siti WordPress

Immagina di sederti rilassato davanti a un caffè, avere il tuo modello di intelligenza artificiale preferito aperto, spendere $ 25 in credito API e 10 ore dopo tenere tra le mani un Remote Code Execution (RCE) non autenticato per il CMS più utilizzato al mondo. Sì!

Questo è esattamente ciò che Adam Kues (Analista della sicurezza presso Searchlight Cyber) sta accadendo. Il risultato ascolta il nome liscio wp2shell ed è una catena di exploit attivamente sfruttata che attualmente gira su milioni di istanze WordPress. Security-Insider.de ha già Segnalato in dettaglio il 27.7.

Se stai eseguendo WordPress e non hai aggiornato da metà luglio, ora Il momento di mettere via il caffè e aprire il terminale.

L'istituzione è in fiamme: Che cosa è wp2shell?

Nel caso di: wp2shell Questo non è solo un semplice bug, ma un Catena di sfruttamento Due vulnerabilità nel core di WordPress. Insieme permettono RCE non autenticato, il che significa che un utente malintenzionato non ha bisogno di credenziali o stato speciale sul tuo sito. Una richiesta HTTP preparata è sufficiente per eseguire qualsiasi codice PHP e rilevare completamente il server.

Gli aggressori non perdono tempo: Già 13 minuti Dopo la pubblicazione del Patch di sicurezza di WordPress su 17.7 aziende di sicurezza come Defiant hanno registrato le prime sonde di iniezione SQL automatizzate sulla rete.

L'anatomia dell'exploit: Cosa succede sotto il cofano

Per chi vuole saperne di più su come funziona il coniglio: Qui, l'interazione delle due vulnerabilità è semplificata:

[ Unauth Request ] │ ▼ [ REST API Batch-Endpoint ] (CVE-2026-63030: │ ├─ Bypass von Auth / Routing-Restrictions ▼ [WP _Query Engine ] (CVE-2026-60137: __─ Undjusted parameter leverages SQL sanitization from _ [Esecuzione di codice remoto / Webshell │ ├─ File in /wp-content/cache/ with random hash name

Troverete tutti i dettagli tecnici nei contributi di Searchlight Cyber e wizz.io

L'apriporta: REST API Batch Routing (CVE-2026-63030)

• Punteggio CVSS: 9.8 (Critico)
• Versioni interessate: WP 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

WordPress offre la possibilità di raggruppare più richieste in una singola chiamata attraverso il suo endpoint batch REST API. C'è stato un errore logico nel Mappatura del percorso. Ciò ha permesso agli aggressori di inviare richieste a endpoint interni / protetti che normalmente richiederebbero l'autenticazione.

Il fornitore del carico utile: SQL Injection nel WP _Query (CVE-2026-60137)

• Punteggio CVSS: 5.9 (mezzi)
• Versioni interessate: WP 6.8.x (< 6.8.6), 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

Il classico: Il parametro Autore __not _in nella classe di interrogazione centrale WP _Query Non è stato adeguatamente igienizzato. Se questo parametro viene alimentato con input non filtrati (ad esempio attivato da un plugin o dal gap API REST sopra menzionato), viene creata una classica iniezione SQL.

La combinazione: Il principio in due fasi

Ricercatore in materia di sicurezza Johannes B. Ullrich (Istituto SANS) illustrato da un esempio, come funziona nella pratica l'ondata di attacchi:

1. Campione/ricognizione: L'attaccante invia un primo payload tramite SQLi per verificare se il database è scrivibile e se il gap funziona.
2. Contagocce Webshell: Una webshell PHP viene premuta nel file system tramite SQLi, in genere nella directory /wp-content/cache/ con un nome MD5/SHA generato casualmente (ad es. a8f3b...php).
3. Meccanismo di furtività: Il nome del file funge anche da token di autenticazione. Se scarichi la webshell senza il parametro URL appropriato, congelerà un URL falso. HTTP 404 non trovato indietro. Intelligente!

Una volta che la shell è a posto, i bot caricano plugin dannosi, leggi il wp-config.php da (Ciao credenziali del database!), creare nuovi utenti amministratori o inserire codice dannoso tramite script CDN manipolati.

AI nel gioco bug bounty: Il Joker da 25 dollari

Un dettaglio speziato sul bordo: Adam Kues ha definito la sua scrittura provocatoria:

"I broker di sfruttamento pagano 500 000 euro $ per un WordPress RCE. Ne ho uno con GPT-5.6 Sol Ultra e 25 $ trovato.»

Ha usato il Large Language Model specificamente per l'analisi statica del codice e il setacciamento attraverso i diff commit del core di WordPress. Quello che occupava squadre di ricercatori di sicurezza per settimane, un'IA specializzata lo fa oggi in poche ore per il cambiamento.

Per gli amministratori, questo significa: Il tempo per lo sfruttamento si sta riducendo enormemente. Il tempo tra il rilascio della patch e le scansioni di massa completamente automatizzate è ora nell'intervallo di minuti.

Primo soccorso: Sei interessato a & cosa fare?

Quick check via sito web: https://wp2shell.com/

Fase 1: Aggiornamento (ora!)

WordPress ha rilasciato la versione patchata il 17 luglio 2026 7.0.2 (o backport) 6.9.5 e 6.8.6) pubblicato. Se l'aggiornamento automatico non funziona: Tostare immediatamente manualmente.

Fase 2: IoC-Check (Indicatori di Compromesso)

Se vuoi sapere se qualcuno si è già stabilito con te, controlla la tua istanza per le seguenti anomalie:

1. /wp-content/cache/ Sfoglia: Attenzione al fresco .phpFile con nomi criptici nella cartella cache. Le cartelle della cache dovrebbero di solito nessuno Contiene codice PHP eseguibile.
   
2. Controlla gli utenti admin: Dai un'occhiata all'elenco dei modelli di WordPress (/wp-admin/users.php?rule=amministratore) a conti sconosciuti. Agli aggressori piace creare amministratori poco appariscenti.
   
3. Analisi dei file di log: Filtrare i registri del server web (Nginx/Apache) per le richieste sospette admin-ajax.php, Chiamate da /wp-json/wp/v2/partita e l'accesso ai file PHP nel cache/directory.

Fase 3: Strumenti utili

• Quanto sopra menzionato Searchlight Cyberwp2shell checker": Fornisce un rapido controllo remoto per il tuo dominio.
• Dashboard live di Macnica (Yutaka Sejiyama): Traccia il tasso di patch globale. Attualmente ci sono circa 81,6 % dei sistemi esaminati. Ma questo significa anche: Quasi uno su cinque La pagina è ancora aperta all'attacco!

Conclusione & Suggerimento per la pratica

wp2shell Ancora una volta, mostra in modo impressionante dove si sta dirigendo il viaggio nel settore della sicurezza informatica: Quando l'analisi basata sull'intelligenza artificiale democratizza la scoperta di 0-days, anche i difensori devono aggiornarsi.

3 regole d'oro per il tuo server WP:

1. Protezione della directory Upload/Cache: Nella configurazione Nginx/Apache, includi una regola che .php-files in /wp-content/caricamenti/ e /wp-content/cache/ È severamente vietato (~* /wp-content/(carica |cache)/.*\.php$ Negare tutto; }).
   
2. Uso di Fail2Ban/WAF: Configurare un firewall per applicazioni Web (ad esempio Cloudflare, Wordfence o ModSecurity) per intercettare i modelli di iniezione noti sul bordo.
   
3. Controlla i backup: Se hai una shell nel sistema, "patching over" spesso non è più sufficiente. Poi: Ripristinare il sistema da un backup pulito prima del 17 luglio e ripristinare tutte le chiavi wp-config.php Ruotalo!

Rimanere al sicuro & felice patching! Che mi dici di te? Hai già patchato tutte le istanze o hai già scoperto accessi sospetti nel registro? Allora andiamo!