Quando si parla di sicurezza su WordPress, la mente corre quasi in automatico alla galassia di plugin e temi di terze parti che popolano l’ecosistema del CMS, storicamente considerati i veri anelli deboli della catena. Questa volta, però, lo scenario è radicalmente diverso e decisamente più problematico, poiché ci troviamo di fronte a un raro caso di falla strutturale, ovvero che risiede direttamente nel core della piattaforma. La minaccia, battezzata dagli esperti con il nome di wp2shell, non richiede l’attivazione di componenti aggiuntivi o configurazioni particolari per essere sfruttata. Si tratta di una vulnerabilità intrinseca al codice nativo del CMS individuata da diversi team di ricercatori, una circostanza che eleva istantaneamente il livello di allerta per tutti gli amministratori di sistema, i webmaster e i professionisti dell’IT che gestiscono infrastrutture basate su questa tecnologia.
La gravità della situazione impone la massima urgenza nell’applicazione delle contromisure, poiché un ritardo nella manutenzione espone i portali a rischi di compromissione totali e immediati. Dal punto di vista tecnico, il pericolo nasce dalla combinazione letale di due diversi difetti di sicurezza: una falla di tipo SQL injection identificata come CVE-2026-60137 che colpisce il parametro author__not_in di WP_Query qualora riceva una stringa al posto di un array, concatenata a un errore nella gestione delle richieste batch delle REST API, tracciato come CVE-2026-63030. Se sfruttate in sequenza, l’errore fa saltare i controlli di autenticazione e permette a un attaccante remoto anonimo di eseguire codice arbitrario sul server, a patto che sul sito non sia attivo un sistema di cache persistente degli oggetti, condizione che però purtroppo è solitamente assente nelle installazioni standard di default.
La mappatura delle installazioni a rischio richiede un controllo tempestivo della release in uso per comprendere se il proprio perimetro sia esposto all’attacco. La catena completa di wp2shell colpisce in modo specifico le versioni di WordPress Core dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1, che consentono il pieno controllo remoto. Esiste inoltre un impatto parziale per le versioni più vecchie comprese tra la 6.8.0 e la 6.8.5, le quali risultano vulnerabili alla sola componente di SQL injection, ma rimangono escluse dalla minaccia di esecuzione di codice remoto non autenticata poiché non integrano il bug delle API REST. Per mettere in sicurezza i sistemi è indispensabile effettuare immediatamente il passaggio alle versioni sane e corrette, ovvero la release 6.8.6 per il ramo più datato, la 6.9.5 per quello intermedio e la 7.0.2 per il ramo principale, rilasciate appositamente per neutralizzare la minaccia.
Sebbene gli automatismi di WordPress abbiano già avviato la distribuzione forzata degli aggiornamenti in background data l’eccezionalità del caso, non è assolutamente prudente adagiarsi sulla presunzione che il processo sia andato a buon fine su ogni singola macchina, specialmente se le automazioni sono state disattivate a livello di server. I team di sicurezza e il CERT-AGID raccomandano caldamente una verifica manuale e consigliano di non limitarsi al semplice update, ma di procedere a un audit approfondito per escludere che il server sia già stato violato. I controlli devono focalizzarsi sull’analisi dei file di log alla ricerca di richieste anomale verso gli endpoint /wp-json/batch/v1 e ?rest_route=/batch/v1, sul monitoraggio di accessi insoliti al database o sulla comparsa improvvisa di nuovi utenti amministrativi, tutti chiari indicatori di una possibile intrusione in corso.
Il rischio complessivo è ulteriormente amplificato dalla recente pubblicazione di Proof of Concept (PoC) funzionanti su GitHub, un fattore che riduce drasticamente i tempi di reazione a disposizione dei difensori prima che si registri un’ondata massiva di attacchi automatizzati. Di fronte a scenari di Remote Code Execution nel core di un software così diffuso, ogni minuto di attesa rappresenta una finestra che i criminali informatici possono sfruttare per installare web shell malevole, sottrarre dati sensibili o compromettere l’integrità dei database. Qualora non fosse possibile aggiornare immediatamente, gli esperti suggeriscono come palliativo temporaneo utilizzare un Web Application Firewall, oppure disabilitare completamente le funzionalità REST API non autenticate, ricordando però che l’unica soluzione definitiva e sicura rimane l’allineamento tempestivo alle ultime versioni contenenti la patch di sicurezza.
Per tutti gli utenti interessati ad approfondire, è stato creato un servizio gratuito che consente di verificare, previo inserimento dell’URL del proprio sito, se si è attualmente vulnerabili o meno (disponibile qui)
