wp2shell PoC: cosa dimostra davvero la CVE-2026-63030

La pubblicazione di un proof of concept per wp2shell ha reso molto più semplice verificare la superficie vulnerabile di WordPress. Ha anche generato un equivoco: il repository pubblico non dimostra da solo l’intera catena di esecuzione di codice da remoto senza autenticazione.

In questo approfondimento separo i fatti documentati dalle ipotesi, ricostruisco il funzionamento del PoC senza pubblicare payload riutilizzabili e propongo una procedura difensiva per validazione, analisi dei log e incident response.

In breve: aggiorna WordPress a 7.0.2, 6.9.5 o 6.8.6, in base al ramo in uso. Non usare il PoC sulla produzione come primo metodo di verifica e non considerare il WAF una sostituzione della patch.

Per una guida operativa più generale puoi leggere anche wp2shell WordPress: mitigazione e analisi dei log.

Le due vulnerabilità della catena

L’advisory ufficiale di WordPress descrive CVE-2026-63030 come una vulnerabilità critica nel batch endpoint della REST API. Una confusione nell’associazione tra route, validazione e richiesta eseguita può essere concatenata con una SQL injection e portare a RCE.

La SQL injection collegata è tracciata anche separatamente come CVE-2026-60137. Le versioni corrette sono:

Il bollettino WordPress raccomanda l’aggiornamento immediato e ha attivato aggiornamenti automatici forzati. È comunque necessario controllare che l’update sia realmente arrivato su ogni istanza: permessi errati, filesystem non scrivibile, installazioni gestite o policy aziendali possono impedirlo.

Cosa dimostra il PoC pubblico

Il repository pubblico di Icex0 si presenta come un’implementazione indipendente della route confusion con SQL injection. Non è il checker ufficiale di Searchlight Cyber e non riproduce gli elementi non divulgati della ricerca originale.

È utile distinguere le sue modalità:

Le ultime due attività sono intrusive e devono essere svolte esclusivamente in un laboratorio isolato o durante un assessment formalmente autorizzato.

Il marker non è una prova di compromissione

Il controllo meno invasivo cerca una risposta HTTP 207 con una combinazione di errori coerente con il disallineamento interno, tra cui:

• parse_path_failed;
• block_cannot_read;
• rest_batch_not_allowed.

Sulle versioni corrette gli array interni restano allineati e questa esatta combinazione non dovrebbe comparire. Un marker positivo indica però una versione o un comportamento vulnerabile, non prova che un attaccante abbia letto dati.

Anche un risultato negativo non basta a dichiarare il sistema sicuro: CDN, WAF, reverse proxy, cache o regole personalizzate possono alterare la risposta. La verifica primaria resta il controllo della versione e dell’integrità del core.

Come nasce la route confusion

Il batch endpoint riceve più sotto-richieste e, nel codice vulnerabile, mantiene strutture parallele per:

1. le route riconosciute;
2. i risultati della validazione;
3. le richieste da eseguire.

Con un percorso malformato, il parsing può produrre un errore inserito nell’elenco di validazione senza aggiungere il corrispondente elemento all’elenco delle route riconosciute. Da quel momento gli indici non descrivono più la stessa richiesta.

Il PoC annida questo comportamento due volte. In termini concettuali:

1. una richiesta destinata al controller dei post viene validata come se appartenesse a un’altra posizione del batch;
2. una successiva richiesta al controller utenti viene eseguita dal gestore dei post;
3. un parametro che nel contesto utenti ha un significato innocuo raggiunge invece WP_Query come author__not_in;
4. il valore non normalizzato entra nella costruzione della query SQL.

Il punto critico non è quindi una singola route “magica”, ma la divergenza tra ciò che WordPress valida e il controller che WordPress esegue.

Perché la SQL injection è blind

Il database non restituisce direttamente il risultato della query all’attaccante. Il PoC deve inferire la risposta osservando differenze booleane o nei tempi di risposta e ricostruire i dati progressivamente.

Questo rende l’estrazione più lenta, ma non innocua. Un attaccante può tentare di leggere:

• nomi utente ed email;
• hash delle password amministrative;
• configurazioni e dati applicativi presenti nel database;
• eventuali segreti memorizzati impropriamente nelle tabelle.

Il traffico di una blind SQL injection tende a produrre richieste ripetute e latenze anomale. Non esiste però una firma universale: le prestazioni del database, la rete e i sistemi intermedi possono generare pattern simili.

Il passaggio a RCE: cosa sappiamo davvero

L’advisory ufficiale afferma che la catena può portare all’esecuzione di codice. La ricerca originale non ha però divulgato tutti i dettagli dell’ultimo passaggio, e il PoC pubblico analizzato non lo implementa senza autenticazione.

Tra le ipotesi discusse pubblicamente ci sono il recupero e cracking di un hash amministrativo seguito da un accesso legittimo, oppure primitive offerte dalla configurazione del database. Non vanno presentate come la catena ufficiale confermata.

Dal punto di vista operativo questa distinzione non riduce l’urgenza:

• la lettura non autenticata del database è già una compromissione grave della riservatezza;
• un hash debole o riutilizzato può favorire l’accesso amministrativo;
• la disponibilità di un PoC abbassa la barriera per scansioni su larga scala;
• configurazioni diverse possono offrire percorsi di escalation differenti.

La presenza o assenza di una cache persistente può influenzare la riproducibilità osservata in alcuni ambienti, ma non è una mitigazione e non deve essere usata per classificare un’istanza come sicura.

Verificare in modo sicuro

Prima di eseguire qualsiasi test attivo, raccogli la versione e verifica i file del core:

wp core version
wp core verify-checksums --include-root

Controlla inoltre che gli aggiornamenti automatici non siano rimasti bloccati e inventaria tutte le istanze, incluse staging, sottodomini dimenticati e copie usate per migrazioni.

Un PoC non dovrebbe essere lanciato direttamente sulla produzione come semplice “health check”. Se serve riprodurre il comportamento:

1. crea una copia isolata senza dati reali;
2. limita la rete in uscita;
3. conserva snapshot e log;
4. testa sia una versione vulnerabile sia quella corretta;
5. distruggi o bonifica il laboratorio dopo l’analisi.

Cercare indicatori nei log

Le due forme principali della route batch da cercare sono:

• /wp-json/batch/v1;
• ?rest_route=/batch/v1, inclusa la variante URL-encoded.

Un primo controllo sui log Nginx compressi e correnti può essere:

zgrep -Ehi '(/wp-json/batch/v1|rest_route=(%2F|/)batch(%2F|/)v1)' /var/log/nginx/access.log*

Adatta percorso e sintassi al web server. Per ogni evento estrai almeno:

• timestamp e IP sorgente;
• metodo HTTP;
• status, in particolare risposte 207;
• user agent e referrer;
• durata della richiesta;
• numero e frequenza delle richieste per sorgente;
• host virtuale raggiunto.

Un limite spesso ignorato

I normali access log non registrano il body delle richieste POST. Cercare soltanto stringhe come author__not_in può quindi non produrre risultati anche quando il tentativo è arrivato al server.

Per un’indagine affidabile bisogna correlare:

• log del reverse proxy, CDN e WAF;
• access ed error log del web server;
• log PHP-FPM e applicativi;
• slow query log o audit log del database, se disponibili;
• telemetria EDR e file integrity monitoring;
• eventi di autenticazione e modifiche amministrative WordPress.

Se sono disponibili response logging o tracing applicativo, la combinazione dei marker parse_path_failed, block_cannot_read e rest_batch_not_allowed aumenta il valore diagnostico.

Come interpretare gli indicatori

Non assumere automaticamente una violazione dei dati da una singola richiesta. Allo stesso tempo, un marker positivo seguito da traffico ripetitivo deve attivare un triage prioritario.

Controlli post-exploitation

Oltre ai log, verifica lo stato dell’installazione:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list
wp plugin list --status=must-use
wp cron event list
wp core verify-checksums --include-root
find wp-content/uploads -type f -iname '*.php' -print
find wp-content -type f -mtime -3 -print

Controlla anche:

• modifiche a wp-config.php, temi e plugin;
• utenti amministratori, application password e sessioni attive;
• plugin caricati fuori dal normale processo di deploy;
• cron di sistema e scheduled task WordPress;
• processi PHP e connessioni in uscita insolite;
• credenziali riutilizzate su pannello hosting, database o servizi esterni.

I comandi find producono piste investigative, non verdetti: alcuni plugin legittimi generano file dinamicamente.

Procedura di risposta se trovi attività sospetta

1. Preserva le evidenze. Salva log, snapshot, timeline e copie dei file prima di ripulire.
2. Contieni l’istanza. Limita l’accesso, blocca gli indicatori confermati e proteggi i sistemi collegati.
3. Aggiorna WordPress. Applica la versione corretta; il WAF resta una misura temporanea.
4. Valuta l’accesso ai dati. Correlare log web e database è essenziale per distinguere scansione, exploit e possibile esfiltrazione.
5. Ruota i segreti. Password amministrative, database, hosting, chiavi API, application password e salt WordPress.
6. Ripristina da una base attendibile. In presenza di compromissione, preferisci rebuild e ripristino verificato alla sola rimozione del file sospetto.
7. Coinvolgi le funzioni competenti. DPO e consulenza legale devono valutare gli eventuali obblighi di notifica sulla base delle evidenze, non della sola esposizione.

Mitigazione temporanea

Se non puoi aggiornare immediatamente, blocca entrambe le forme del batch endpoint al reverse proxy o WAF:

• percorso REST diretto /wp-json/batch/v1;
• parametro rest_route=/batch/v1.

Valuta l’impatto su integrazioni legittime e non dimenticare le varianti codificate. La regola riduce l’esposizione, ma può essere aggirata da differenze di normalizzazione e non corregge il codice vulnerabile.

Domande frequenti

Il PoC pubblico prova la RCE pre-auth?

Non nella sua interezza. Dimostra la route confusion e la SQL injection; la funzione di caricamento della shell richiede credenziali amministrative valide. L’advisory ufficiale conferma comunque che la catena completa può portare a RCE.

Se il check è negativo posso chiudere l’incidente?

No. Verifica versione e checksum, controlla i sistemi intermedi e analizza i log. Un WAF può impedire al check di osservare il comportamento senza eliminare la vulnerabilità dal server origin.

È sufficiente cambiare le password?

No. Prima applica la patch e determina se il sistema è stato compromesso. Se l’attaccante mantiene persistenza, una semplice rotazione non risolve il problema.

Il WAF sostituisce l’aggiornamento?

No. È una compensazione temporanea utile durante la finestra di patching.

Supporto per analisi log e mitigazione

Se devi capire se un’istanza WordPress è stata soltanto scansionata o realmente raggiunta dalla catena wp2shell, posso supportarti con:

• analisi e correlazione di log web, CDN/WAF, PHP e database;
• costruzione della timeline e classificazione degli indicatori;
• verifica di integrità e ricerca di persistenza;
• hardening, regole temporanee e piano di patching;
• supporto tecnico alla risposta all’incidente.

Contattami per una valutazione tecnica.

Fonti

• WordPress Security Advisory: CVE-2026-63030
• WordPress Security Advisory: CVE-2026-60137
• WordPress 7.0.2 Security Release
• Searchlight Cyber: wp2shell research
• Checker e mitigazioni wp2shell
• Icex0: repository del PoC pubblico
• Approfondimento di Pasquale Pillitteri