Un attacco alla supply chain WordPress ha coinvolto oltre 30 plugin acquistati in modo del tutto legale da un soggetto terzo, che li ha poi modificati inserendo codice malevolo e distribuendoli attraverso i canali ufficiali. La scoperta arriva da Anchor, fornitore di servizi hosting specializzato in WordPress, che ha pubblicato un’analisi approfondita su quanto accaduto. Il meccanismo è tanto semplice quanto efficace: comprare un portafoglio di plugin già affermati, ottenere accesso al repository ufficiale WordPress.org e sfruttare la fiducia costruita negli anni dagli sviluppatori originali. Il tutto senza dover violare nulla, almeno tecnicamente.
Il gruppo di plugin è stato venduto su marketplace come Flippa per un importo a sei cifre. Il nuovo proprietario ha ereditato l’accesso completo al sistema SVN, quello usato per distribuire gli aggiornamenti. E qui sta il punto debole: il processo di trasferimento verifica il consenso di chi vende, ma non introduce controlli reali su chi compra. Nessuna revisione del primo commit, nessuna validazione dell’identità tecnica. Chi acquisisce un plugin WordPress eredita automaticamente tutta la credibilità accumulata dal precedente sviluppatore.
Come funziona la backdoor e perché è rimasta nascosta per mesi
Il codice malevolo è comparso mascherato da aggiornamento di compatibilità con WordPress 6.8.2. Niente di appariscente, anzi: a una lettura superficiale sembrava un normale sistema di telemetria. In realtà attivava una sequenza di esecuzione remota sfruttando la PHP deserialization, una tecnica che permette di ricreare oggetti a partire da dati serializzati. Quando non viene validata a dovere, consente a un attaccante di iniettare oggetti malevoli e farli eseguire dentro l’applicazione. Una funzione interna recuperava dati da un server remoto e li passava direttamente a unserialize(), consentendo l’esecuzione di codice PHP arbitrario senza alcuna autenticazione.
La parte più insidiosa riguarda il timing. Il codice risulta introdotto ad agosto 2025 ma è rimasto dormiente per circa otto mesi. Durante tutto quel periodo, il server remoto restituiva risposte perfettamente legittime. Nessun avviso, nessun comportamento anomalo. L’attivazione è avvenuta ad aprile 2026, quando i plugin risultavano ormai installati su migliaia di siti.
Una volta attiva, la backdoor scaricava un file chiamato wp-comments-posts.php, progettato per imitare un componente core di WordPress. Poi andava a modificare direttamente wp-config.php, uno dei file più sensibili dell’intera installazione, aggiungendo circa 6 KB di codice PHP capace di generare pagine SEO spam, redirect condizionali e caricamento di contenuti remoti. Un dettaglio che la dice lunga: il contenuto malevolo si attivava solo per user agent specifici, come Googlebot. Gli amministratori del sito vedevano una versione pulita, mentre i motori di ricerca indicizzavano contenuti manipolati. Danno tecnico e penalizzazione SEO insieme.
Perché aggiornare non è bastato e cosa manca al modello WordPress
WordPress.org ha reagito in fretta con la rimozione dei plugin, la chiusura del repository e il rilascio di una versione correttiva (2.6.9.1). La patch, però, introduce solo un blocco logico, spesso un semplice return aggiunto alle funzioni compromesse. Il problema è che il codice già eseguito resta nel sistema. Le modifiche a wp-config.php non vengono rimosse automaticamente, quindi il sito rimane compromesso anche dopo l’aggiornamento di emergenza.
Questa vicenda mette in evidenza un limite strutturale del repository WordPress: viene verificato chi cede un plugin, ma non chi lo acquisisce. Non esiste un controllo sistematico sui cambi di proprietà né una revisione del codice dopo operazioni di questo tipo. Altri ecosistemi hanno già introdotto misure più rigide: Apple richiede una revisione completa in caso di trasferimento delle app, Google Play impone verifiche sull’identità dello sviluppatore. La lista completa dei 30 plugin acquisiti e modificati per servire codice malevolo è disponibile nell’analisi pubblicata da Anchor.