Le richieste all'endpoint batch della REST API di WordPress sono più che triplicate sulla nostra infrastruttura
Nella settimana del 26 ottobre, il numero di sorgenti che hanno cercato sulla nostra infrastruttura l'endpoint batch della REST API di WordPress, il punto d'ingresso della catena di vulnerabilità wp2shell, è salito a 3.3 volte la media settimanale precedente. Gli scanner hanno cercato più spesso anche backup, pagine di debug e componenti interni delle applicazioni.
291 Intercept è il nostro report settimanale su ciò che gli scanner automatici hanno cercato sulla nostra infrastruttura, così potete verificare gli stessi punti sui vostri sistemi. Ogni edizione riguarda una settimana conclusa da almeno sette giorni.
Il cambiamento più evidente sulla nostra infrastruttura nella settimana del 26 ottobre è stato un balzo delle richieste per un indirizzo di WordPress: /wp-json/batch/v1. Lo hanno richiesto circa 40 sorgenti, 3.3 volte la sua media settimanale delle tre settimane precedenti. È proprio da quell'endpoint che parte wp2shell, una catena di due vulnerabilità nel core di WordPress che consente a un attaccante non autenticato di eseguire codice su un sito.
Il tutto in una settimana più movimentata del solito: circa 620 sorgenti hanno sondato la nostra infrastruttura esposta su internet, il 10% in più rispetto alla media delle tre settimane precedenti. WordPress è rimasto il bersaglio principale: il 66% delle sorgenti ha preso di mira login, XML-RPC o percorsi dei plugin di WordPress, in aumento del 20%. Gli scanner hanno anche cercato più spesso parti di un'applicazione che dovrebbero restare private.
Che cos'è wp2shell
/wp-json/ è la radice della REST API di WordPress e /wp-json/batch/v1 è il suo processore batch, che gestisce insieme un pacchetto di richieste API. Secondo Rapid7, wp2shell combina due vulnerabilità. CVE-2026-63030 è un errore logico in quel processore batch, mentre CVE-2026-60137 è una SQL injection nell'endpoint dei post. Concatenate, permettono a chiunque, anche senza un account, di eseguire codice su WordPress dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1.
La vulnerabilità è stata resa pubblica il 17 luglio 2026 e, secondo Rapid7, la CISA l'ha aggiunta al suo catalogo Known Exploited Vulnerabilities il 21 luglio. Le versioni corrette sono la 6.9.5, la 7.0.2 e la 7.1 Beta 2.
Perché cercare una vulnerabilità per cui esiste già una correzione? Agli scanner non serve che tutti i siti siano vulnerabili, ne bastano alcuni. Una richiesta non costa loro quasi nulla, e qualsiasi sito ancora fermo a una versione vulnerabile merita una seconda visita.
Il volto noto della scansione di WordPress
Un toolkit coordinato di circa 20 sorgenti in pochi paesi ha passato in rassegna lo stesso elenco di una decina di percorsi. Chiedeva lo stesso file sotto molti nomi di cartella, come /wp/wp-includes/wlwmanifest.xml, /shop/wp-includes/wlwmanifest.xml e /wordpress/wp-includes/wlwmanifest.xml, oltre a /xmlrpc.php.
wlwmanifest.xml è il manifest di Windows Live Writer presente nelle installazioni predefinite di WordPress, e richiederlo nelle cartelle più comuni è un modo per individuare i siti WordPress prima di tentare exploit su plugin o temi. XML-RPC è il passo successivo: nel 2015 alcuni ricercatori hanno scoperto che il suo metodo system.multicall permette a un attaccante di provare centinaia di password in una sola richiesta.
Avanzi e componenti interni
Rispetto alle tre settimane precedenti, il numero di sorgenti in cerca di file di backup e dump è cresciuto del 73%, quello delle sorgenti interessate a componenti interni delle applicazioni come gli actuator di Spring Boot del 63%, e quello delle sorgenti che chiedevano pagine diagnostiche come /phpinfo.php e /info.php del 52%. Poiché è aumentato anche il numero complessivo di sorgenti, le loro quote si sono mosse meno: le pagine diagnostiche sono passate in media dal 15% al 21% di tutte le sorgenti. Il grafico qui sotto mostra sei delle categorie di questa settimana, ciascuna con la sua quota di sorgenti di questa settimana a confronto con la media delle tre settimane precedenti.
Quota sul totale delle sorgenti distinte che hanno preso di mira ciascun obiettivo, in percentuale. Una sorgente può prendere di mira più obiettivi, quindi la somma delle quote supera il 100%.
| Questa settimana | Media delle 3 settimane precedenti | |
|---|---|---|
| Backup e dump di database | 12% | 9% |
| Endpoint di gestione delle applicazioni | 13% | 9% |
| Pagine di debug e diagnostica | 21% | 15% |
| Pagine di login e file di WordPress | 66% | 61% |
| Codice sorgente esposto (Git, SVN) | 29% | 24% |
| File di segreti e di configurazione | 33% | 33% |
/actuator/env ha attirato circa 40 sorgenti, 2.4 volte la sua media precedente. In Spring Boot quell'endpoint mostra le proprietà di configurazione dell'applicazione. La documentazione di Spring precisa che per impostazione predefinita solo health è raggiungibile via HTTP e che i valori di env sono mascherati, ma quando gli sviluppatori lo espongono senza limitarne l'accesso, può far trapelare credenziali, chiavi API e impostazioni interne. /wp-config.php.bak, un backup dimenticato della configurazione di WordPress, è raddoppiato arrivando a circa 40 sorgenti.
Un secondo toolkit di circa 20 sorgenti ha combinato questi interessi in un'unica passata: /.env, /.git/config, /info.php, /config.json, /server-status e /debug/default/view. L'ultimo percorso appartiene al debugger di Yii 2, che mostra dati di sessione, variabili d'ambiente e query al database. La guida di Yii spiega che di norma funziona solo da localhost, ma CVE-2026-103475, resa pubblica il 30 settembre, riguarda yii2-starter-kit fino alla 4.2.0, la cui configurazione predefinita lo rende accessibile da qualsiasi indirizzo IP.
Aggiornamento sulla scorsa settimana
Nella scorsa edizione avevamo segnalato un aumento degli scanner in cerca di file .env nelle sottocartelle. La tendenza è proseguita. /v2/.env e /old/.env hanno attirato circa 60 sorgenti ciascuno, più o meno il doppio della loro media precedente, con /production/.env a 50 e /storage/.env a 40. In totale, 200 sorgenti hanno cercato file di segreti e di configurazione, il 16% in più, in linea con la crescita complessiva delle sorgenti, per cui la loro quota è rimasta al 33%. Per dare un'idea della scala, a febbraio alcuni ricercatori hanno segnalato 12,088,677 indirizzi IP che servivano file in stile .env accessibili pubblicamente.
La ricerca di repository Git, che la scorsa settimana apriva il report, ha perso quota ma è rimasta sopra i livelli precedenti. In totale, 170 sorgenti hanno cercato repository di codice sorgente, il 20% in più rispetto alla media delle tre settimane, anche se la loro quota sul totale è scesa dal 37% al 29%.
Chi faceva le richieste
Più della metà delle sorgenti (55%) proveniva da reti cloud e di hosting, con DigitalOcean e Google Cloud al 20% ciascuna, e l'85% di tutte le sorgenti si è fatto vedere in un solo giorno. Quasi tutte cercavano anche di passare per persone: l'82% inviava user agent che imitavano normali browser, ma l'85% si comportava come uno strumento automatico, quindi il travestimento regge poco.
Cosa si è calmato
Le richieste per /wp-content/plugins/hellopress/wp_filemanager.php, che in media attiravano circa 20 sorgenti a settimana, sono quasi sparite, in calo del 79%. È presto per dire se gli scanner siano passati ad altro. I file di chiavi cloud come /service-account.json sono rimasti più o meno stabili a 70 sorgenti.
Cosa fare
- Controllate la versione di WordPress. Se è compresa tra la 6.9.0 e la 6.9.4 o tra la 7.0.0 e la 7.0.1, aggiornate subito alla 6.9.5 o alla 7.0.2.
- Tenete i file .env completamente fuori dalla cartella pubblica, comprese le vecchie release e le sottocartelle con le versioni. Il posto sicuro è un livello sopra la web root.
- Eliminate backup e dump come
/database.sqlo/wp-config.php.bakda qualsiasi percorso raggiungibile da un browser. - Blindate i componenti interni. Limitate l'accesso agli endpoint actuator di Spring Boot e lasciate attivo il mascheramento di env, rimuovete le pagine di test phpinfo e mantenete il debugger di Yii limitato a localhost.
- Disattivate XML-RPC se il vostro sito non ne ha bisogno.
Informazioni su queste osservazioni
Questo report è prodotto da 291 Heat Seeker One, il sistema di monitoraggio della sicurezza di 291 Group, in esecuzione su 291 Crossband, la nostra piattaforma proprietaria per le operazioni di sicurezza. Riguarda esclusivamente il traffico diretto all'infrastruttura di 291 Group esposta su internet.
I dati sono arrotondati, quote e variazioni si misurano sul numero di sorgenti distinte e non sulle richieste, e sono inclusi solo i pattern osservati da almeno 20 sorgenti distinte. I paesi indicano dove si trovano i server delle sorgenti, non necessariamente dove si trovano le persone che li gestiscono. Le tipologie di rete derivano da chi gestisce ciascuna rete; vengono nominati solo i fornitori grandi e noti.