WordPress ora blocca gli aggiornamenti dei plugin ad alto rischio prima della distribuzione
WordPress sta aggiungendo una revisione di sicurezza automatizzata per ogni versione di ogni plugin prima che quella versione venga distribuita attraverso l'API di aggiornamento di WordPress.org. La modifica serve a intercettare codice ad alto rischio prima che raggiunga i siti che si affidano agli aggiornamenti automatici, ed è l'ultimo passo compiuto dalla piattaforma per migliorare la sicurezza dei plugin di WordPress.
Il repository dei plugin di WordPress.org da tempo esamina i nuovi plugin prima che entrino nella directory, ma dopo quel controllo iniziale gli aggiornamenti sono stati distribuiti senza interruzioni. David Perez, co-responsabile del WordPress Official Plugin Repository Team, ha spiegato che un plugin può essere sicuro oggi e introdurre una vulnerabilità o codice malevolo in una versione futura. WordPress stessa ha dichiarato che l'assenza di un passaggio di revisione coerente tra il commit di una versione e la distribuzione di un plugin agli utenti finali potrebbe aprire la porta ad attacchi malevoli. Dal 5 giugno 2026, ogni plugin e tema passa attraverso un periodo di attesa prima di essere distribuito tramite gli aggiornamenti automatici, nell'ambito di un'iniziativa chiamata Protect The Shire. L'attesa aggiunge un ostacolo affinché gli aggiornamenti malevoli non raggiungano immediatamente gli utenti finali, e attualmente è di sei ore, ridotta rispetto alle 24 ore iniziali.
Il valore di quella finestra di attesa è diventato chiaro il 28 luglio 2026, quando la revisione automatizzata ha rilevato una backdoor inserita in una versione di un plugin con circa 20.000 installazioni attive. Poiché la versione era ancora nel periodo di attesa, la versione compromessa non ha mai raggiunto l'API di aggiornamento di WordPress.org. L'azienda di sicurezza WordPress Wordfence ha avvisato il Plugins Team, e il plugin è stato chiuso ai download 26 minuti dopo. WordPress non ha divulgato il nome del plugin. Il rilevamento e la chiusura rapidi mostrano come la revisione automatizzata e la risposta umana possano lavorare insieme per tenere un aggiornamento malevolo lontano dai proprietari dei siti.
La modifica più recente colma un'altra lacuna facendo sì che un punteggio di alto rischio blocchi automaticamente la distribuzione senza richiedere l'intervento del Plugins Team. Durante il periodo di attesa, le modifiche di ogni versione vengono analizzate da modelli di intelligenza artificiale e da Jetpack Scan, uno strumento di scansione di sicurezza. Quei risultati vengono verificati in modo incrociato e combinati in un punteggio di sicurezza; un punteggio più alto significa un rischio potenzialmente più elevato. Le versioni con un punteggio di rischio elevato vengono bloccate automaticamente una volta completata la revisione, mentre le versioni al di sotto di quella soglia proseguono il processo normale. Gli autori dei plugin ricevono un'email con i risultati solo quando un plugin viene bloccato.
Un punteggio di rischio elevato non indica necessariamente un intento malevolo. Il punteggio può segnalare una falla di sicurezza introdotta per errore così come segnala malware intenzionale. Perez ha detto che la revisione automatizzata cerca le stesse classi di vulnerabilità che cercherebbe qualsiasi audit di sicurezza. Gli sviluppatori sono invitati a seguire gli WordPress Coding Standards e le regole di PHP_CodeSniffer per validare il proprio codice, e agli autori di estensioni WooCommerce è consigliato usare la piattaforma di test Quality Insights Toolkit. Il sistema di punteggio presta attenzione a diversi schemi pericolosi. Un endpoint REST, AJAX o admin-post senza un controllo dei permessi può consentire a una richiesta non autorizzata di eseguire un'azione; un controllo dei permessi è un test che verifica che la persona o il programma abbia il permesso corretto, e un nonce da solo, che verifica soltanto che una richiesta provenga da un modulo valido, non è sufficiente. Le query costruite senza una prepared statement possono permettere agli attaccanti di modificare il comando stesso del database. Costruire percorsi di file, upload, cancellazioni o include direttamente dai dati della richiesta può permettere a un attaccante di indirizzare il codice verso un file che controlla. Usare unserialize sui dati della richiesta o su una risposta remota, scrivere opzioni o impostazioni utente da endpoint raggiungibili da sottoscrittori o utenti non autenticati, e recuperare o valutare codice a runtime, incluso codice offuscato o compattato, sono tutti segnali che fanno salire il punteggio di rischio.
Una volta che una versione è bloccata, l'unico modo per lo sviluppatore di rimuovere la restrizione è rivedere i risultati, correggere i problemi e pubblicare una nuova versione. Se quella nuova versione ottiene un punteggio inferiore alla soglia di alto rischio, prosegue attraverso il normale processo di attesa. Se un risultato sembra errato, gli autori possono contattare il Plugins Team, ma Perez ha avvertito che il team gestisce un volume elevato di revisioni, quindi pubblicare una versione corretta è quasi sempre più veloce che aspettare un ricorso manuale. Questo approccio mantiene in movimento l'ecosistema pur tenendo il codice pericoloso fuori dal flusso degli aggiornamenti.
Per i proprietari di siti che si affidano ai plugin di WordPress, il blocco automatizzato aggiunge un ulteriore livello di protezione prima che codice rischioso arrivi sui loro siti. Gestire gli aggiornamenti dei plugin e la sicurezza è più semplice su una piattaforma di hosting WordPress gestito; AEU Hosting offre hosting WordPress gestito con misure di sicurezza e una gestione semplificata degli aggiornamenti che può ridurre il carico di lavoro per i proprietari dei siti e aiutarli a mantenerli più sicuri.