WordPress, comprano 30 plugin e nascondono una backdoor in tutti

Gli attacchi alla supply chain software sono operazioni in cui un aggressore non colpisce direttamente il bersaglio finale, ma compromette uno degli elementi “a monte” della filiera di sviluppo: librerie open source, dipendenze, strumenti di build, repository o servizi di aggiornamento. L’effetto è che colpendo uno specifico punto nella catena, gli aggressori possono lanciare un attacco su larga scala capace di colpire un’estesissima platea di soggetti (spesso senza che se ne accorgano subito). Questa volta l’attacco coinvolge gli sviluppatori e amministratori WordPress.

Ad aver scoperto il problema è un fornitore di servizi di hosting per WordPress, Anchor, che pubblica un’analisi dettagliata sull’accaduto: un portafoglio di plugin WordPress acquistato legalmente da un soggetto terzo è stato modificato con codice malevolo e distribuito attraverso canali ufficiali. Il risultato ha coinvolto decine di estensioni e migliaia di siti, con effetti che si sono manifestati solo mesi dopo dall’introduzione del codice.

Acquisizione dei plugin WordPress e accesso alla supply chain

L’operazione di attacco a WordPress è in questo caso partita da un’acquisizione commerciale: un gruppo di oltre 30 plugin sviluppati da un vendor noto viene venduto su marketplace come Flippa per un importo a sei cifre. Il nuovo proprietario ottiene accesso completo al repository ufficiale WordPress.org, incluso il sistema SVN utilizzato per la distribuzione degli aggiornamenti.

Il punto critico è proprio qui: il processo di trasferimento verifica il consenso del venditore, ma non introduce controlli sostanziali sul nuovo maintainer. Non esiste una revisione approfondita del primo commit né una validazione dell’identità tecnica. Chi compra eredita automaticamente la fiducia degli utenti in ogni singolo plugin per WordPress,, costruita nel corso di anni di lavoro.

Inserimento della backdoor nel codice

Il codice malevolo compare in una versione apparentemente innocua, etichettata come aggiornamento di compatibilità con WordPress 6.8.2. In realtà attiva una sequenza di esecuzione di codice da remoto sfruttando la PHP deserialization, un processo che ricrea oggetti a partire da dati precedentemente trasformati in un formato memorizzabile o trasmissibile. Se non adeguatamente validata, tale tecnica può consentire a un attaccante di introdurre oggetti malevoli e provocarne l’esecuzione all’interno dell’applicazione.

Una funzione interna recupera dati da un server remoto tramite file_get_contents() e li passa direttamente a unserialize(). A quel punto il payload può eseguire codice PHP arbitrario senza autenticazione. Il codice include anche un endpoint REST con permission_callback impostato a true, quindi accessibile pubblicamente.

Chi legge il codice vede un normale sistema di aggiornamento o telemetria. In pratica, invece, si tratta di un loader remoto.

Una backdoor dormiente per mesi

La scelta più interessante riguarda il timing. Anchor spiega che il codice malevolo risulta introdotto addirittura ad agosto 2025 ma resta inattivo per circa 8 mesi. Durante questo periodo, il server remoto restituisce risposte legittime. Nessun avviso, nessun comportamento sospetto.

All’attivazione dell’attacco, avvenuta ad aprile 2026, i plugin risultano installati su migliaia di siti; complice anche la “fiducia” che gli utenti – nel frattempo – hanno continuato a rifondere nei componenti aggiuntivi.

Una volta attivata, la backdoor scarica un file chiamato wp-comments-posts.php, progettato per imitare un file core di WordPress. Il codice poi modifica direttamente wp-config.php, uno dei file più sensibili dell’intera installazione.

L’iniezione aggiunge circa 6 KB di codice PHP che gestisce:

• generazione di pagine SEO spam;
• redirect condizionali;
• caricamento di contenuti remoti.

Un dettaglio rilevante: il contenuto malevolo si attiva solo per user agent specifici, come Googlebot. Gli amministratori del sito vedono così una versione pulita, mentre i motori di ricerca indicizzano contenuti manipolati. Il risultato è un danno doppio: compromissione tecnica e penalizzazione SEO.

Perché la patch non basta

WordPress.org ha reagito rapidamente: rimozione dei plugin, chiusura definitiva del repository e rilascio di una versione correttiva (2.6.9.1). Tuttavia la patch introduce solo un blocco logico, spesso sotto forma di return aggiunto alle funzioni compromesse.

Il problema è che il codice malevolo già eseguito resta nel sistema. In particolare, le modifiche a wp-config.php non vengono rimosse automaticamente: il sito rimane compromesso anche dopo l’aggiornamento di emergenza.

La lista dei 30 plugin acquisiti dai criminali e modificati per servire codice malevolo è disponibile nell’analisi di Anchor.

Limiti del modello WordPress

La vicenda evidenzia un limite importante: il modello di fiducia del repository. WordPress verifica chi cede un plugin, ma non chi lo acquisisce: non esiste un controllo sistematico sui cambi di proprietà né una revisione del codice successivamente a questo tipo di operazioni.

Altri ecosistemi hanno introdotto misure più rigide. Apple richiede una revisione completa in caso di trasferimento delle app; Google Play impone verifiche sull’identità dello sviluppatore.

Chi lavora con WordPress dovrebbe rivedere alcune abitudini consolidate: aggiornare i plugin non è più una garanzia di sicurezza. Nella vicenda descritta da Anchor l’aggressione è arrivata sui sistemi dei gestori di siti WordPress proprio tramite un aggiornamento dei plugin.

Ha quindi senso introdurre controlli aggiuntivi: monitoraggio dei file critici, verifica dei cambi di proprietà dei plugin, audit periodici del codice installato. Negli ambienti professionali, vale la pena isolare wp-config.php e limitarne le modifiche tramite i permessi a livello di file system o strumenti di controllo dell’integrità.