WordPress blocca gli update plugin ad alto rischio: AI e Jetpack entrano nella supply chain

🛡️ Executive Summary

• Ogni nuova release plugin su WordPress.org viene analizzata durante il cooldown da più modelli AI insieme a Jetpack Scan.
• Gli aggiornamenti con rischio elevato vengono bloccati prima di raggiungere gli utenti attraverso update automatici e dashboard.
• Il sistema ha già intercettato una backdoor destinata a circa 20.000 installazioni, mostrando il valore del controllo sulla supply chain.

WordPress cambia il modello di sicurezza degli aggiornamenti plugin e introduce un controllo automatico prima che una nuova versione raggiunga gli utenti. Durante il periodo di attesa che precede la distribuzione, ogni release viene ora analizzata da più modelli di intelligenza artificiale insieme a Jetpack Scan. Se il sistema assegna un punteggio di rischio elevato, l’aggiornamento viene bloccato automaticamente. La novità colpisce uno dei punti strutturalmente più delicati dell’ecosistema: non la vulnerabilità già presente su un sito, ma il codice che WordPress.org sta per distribuire contemporaneamente a migliaia o milioni di installazioni.

WordPress sposta il controllo di sicurezza prima dell’aggiornamento

Fino a pochi mesi fa esisteva un’asimmetria evidente nel Plugin Directory. I nuovi plugin venivano sottoposti a revisione prima della pubblicazione, mentre le versioni successive potevano essere rilasciate continuamente una volta che il progetto era stato approvato. Un plugin considerato sicuro al momento dell’ingresso nel repository poteva quindi introdurre in seguito una vulnerabilità, una backdoor o codice malevolo attraverso un normale aggiornamento. La Plugins Team di WordPress descrive ora il nuovo Automated Security Review come un controllo applicato a ogni release prima della distribuzione tramite WordPress.org Update API. Durante il cooldown, le modifiche vengono analizzate da più modelli AI e da Jetpack Scan; i risultati vengono confrontati e sintetizzati in finding ai quali viene assegnato un punteggio di rischio. Se il valore resta sotto la soglia di blocco, la release prosegue normalmente. Se invece la supera, la distribuzione viene fermata automaticamente e tutti i committer ricevono una mail con i problemi individuati. Il punto importante è che il blocco non richiede più l’intervento immediato di un revisore umano.

Una backdoor su 20.000 siti ha mostrato perché il filtro serviva

Il nuovo sistema non nasce da un problema teorico. WordPress rivela che il 28 luglio 2026 una backdoor era stata inserita in una release di un plugin con circa 20.000 installazioni attive. Il controllo automatico ha attribuito all’aggiornamento un livello di rischio elevato e, poiché la versione si trovava ancora nel periodo di cooldown, il codice compromesso non è mai stato distribuito tramite l’Update API di WordPress.org. Il plugin è stato successivamente chiuso ai download 26 minuti dopo che Wordfence aveva notificato il problema alla Plugins Team. WordPress non ne ha reso pubblico il nome, ma l’incidente ha evidenziato il limite del modello precedente: rilevare una release sospetta senza arrestarne automaticamente la distribuzione lasciava ancora una finestra nella quale era necessario l’intervento di una persona. Il problema è particolarmente rilevante perché la supply chain WordPress non dipende soltanto dagli exploit contro plugin vulnerabili. Ad agosto la compromissione dell’infrastruttura BdThemes aveva permesso di creare amministratori nascosti nei siti senza distribuire un aggiornamento malevolo, mostrando come una componente considerata affidabile possa diventare il veicolo attraverso cui raggiungere migliaia di installazioni contemporaneamente.

Protect The Shire introduce sei ore nelle quali l’update può essere fermato

L’infrastruttura che rende possibile il nuovo controllo era stata introdotta il 5 giugno 2026 con Protect The Shire. Inizialmente WordPress aveva imposto un’attesa fino a 24 ore tra la pubblicazione di una release e la sua disponibilità attraverso gli aggiornamenti automatici. Il periodo è stato successivamente ridotto a circa sei ore. Nel post originale con cui WordPress ha presentato Protect The Shire, Matt Mullenweg spiegava direttamente il conflitto che il progetto stava cercando di risolvere: aggiornare rapidamente resta una delle principali difese contro le vulnerabilità, ma l’aggiornamento stesso può diventare il vettore di un attacco supply chain quando le credenziali di uno sviluppatore vengono sottratte, un progetto cambia proprietario oppure codice malevolo viene introdotto nel repository. La scelta di inserire un ritardo artificiale trasforma quindi l’Update API in un punto di controllo. WordPress.org dichiara oltre 78.000 plugin e temi nel proprio ecosistema e centinaia di milioni di installazioni complessive: anche una singola release compromessa può produrre una distribuzione estremamente rapida prima che ricercatori o amministratori abbiano il tempo di intervenire.

Leggi anche: StopAndProtect usa quasi 2.000 siti WordPress compromessi per ransomware, furto dati e ClickFix

Il controllo cerca vulnerabilità ma anche comportamenti tipici delle backdoor

Il sistema non assegna il punteggio soltanto cercando firme malware note. La documentazione ufficiale dell’Automated Security Review chiarisce che i finding vengono prodotti incrociando strumenti differenti e che un punteggio elevato misura il rischio, non l’intenzione dello sviluppatore. Una vulnerabilità introdotta per errore può quindi essere trattata nello stesso modo di codice inserito deliberatamente per compromettere gli utenti. Tra i pattern indicati dalla Plugins Team rientrano endpoint REST, AJAX o admin-post privi di capability check, query SQL costruite senza $wpdb->prepare(), percorsi di file derivati direttamente da dati controllabili attraverso una richiesta, chiamate a unserialize() su input esterni e scritture di opzioni o user metadata raggiungibili da utenti non privilegiati. Particolare attenzione viene riservata anche al codice recuperato ed eseguito dinamicamente, all’offuscamento e al codice packed. Sono precisamente le classi di comportamento che trasformano spesso una vulnerabilità WordPress in takeover completo. Gli ultimi mesi hanno mostrato quanto ampia possa essere la superficie: WPMU DEV Dashboard, Avada, TranslatePress, Pods e GiveWP hanno accumulato falle capaci di arrivare a takeover e RCE, mentre pochi giorni dopo All-in-One WP Migration ha esposto oltre cinque milioni di installazioni a una SQL injection capace di evolvere verso esecuzione di codice.

Il blocco non chiude il plugin e non modifica i siti già installati

Un aggiornamento fermato dal nuovo sistema non viene automaticamente interpretato come malware e il plugin non viene necessariamente rimosso dal repository. La pagina continua a essere disponibile e gli utenti restano sulla versione precedentemente distribuita. È soltanto la nuova release a non attraversare l’Update API. Per gli sviluppatori il percorso più rapido consiste nel correggere i finding e pubblicare una nuova versione, che viene sottoposta nuovamente allo stesso controllo. È possibile contestare un falso positivo alla Plugins Team, ma WordPress avverte che, considerato il volume delle verifiche, rilasciare una versione corretta può essere più rapido dell’attesa per una revisione manuale. Questa scelta introduce inevitabilmente una tensione. Un filtro automatizzato abbastanza aggressivo da bloccare backdoor e vulnerabilità prima della distribuzione può generare falsi positivi; un filtro troppo permissivo perde invece gran parte del proprio valore. WordPress tenta di ridurre questo problema attraverso la correlazione tra più modelli AI e Jetpack Scan anziché affidare la decisione a un singolo sistema.

Continua con:

• PaperCut sotto attacco e GiveWP apre alla RCE su oltre 100.000 installazioni
• Una campagna globale sfrutta plugin WordPress e altri CMS per installare web shell

WordPress prova a spostare la difesa dal sito alla fonte della distribuzione

Il cambiamento più importante è architetturale. Le normali difese WordPress operano quasi sempre dopo che il codice è arrivato sul sito: WAF, scanner, monitoraggio dei file, vulnerability intelligence e intervento dell’amministratore devono individuare un componente vulnerabile o già compromesso. Automated Security Review sposta invece una parte della difesa a monte, prima che WordPress.org consegni l’aggiornamento. Non elimina il problema delle vulnerabilità e non protegge i plugin distribuiti al di fuori del repository ufficiale. Non impedisce nemmeno gli attacchi che sfruttano infrastrutture esterne controllate dal vendor, come ha mostrato BdThemes. Ma modifica una delle condizioni più pericolose della supply chain: la capacità di trasformare il canale di aggiornamento legittimo in un moltiplicatore automatico di codice malevolo. Per un ecosistema nel quale un singolo plugin può superare milioni di installazioni, sei ore di attrito possono quindi avere un valore molto maggiore di quanto suggerisca il semplice ritardo nell’update. La backdoor intercettata a luglio lo dimostra: in quel caso il risultato più importante del nuovo sistema è stato precisamente ciò che gli utenti non hanno ricevuto.