Supply chain plugin WordPress: l'aggiornamento che infetta

Il consiglio più ripetuto della sicurezza WordPress è: aggiorna, sempre, subito. Lo ripeto anch'io in ogni audit, e nella maggior parte dei casi è la cosa giusta. Ma esiste uno scenario in cui l'aggiornamento stesso è l'arma, e negli ultimi mesi è diventato abbastanza concreto da meritare un articolo a parte. Un episodio del podcast WP Tavern — il numero 219, con Austin Ginder di Anchor Hosting — ha messo ordine in quello che io stesso vedevi come casi isolati: gli attacchi alla supply chain dei plugin, dove non è il tuo sito a essere attaccato direttamente, ma il canale da cui arrivano gli aggiornamenti.

La storia di Ginder parte da una bonifica malware su un sito cliente, una di quelle che sembrano finite e invece tornano. Ha seguito il filo, ed è arrivato a un quadro più ampio: attori malintenzionati che non bucano più solo i singoli siti, ma il canale di distribuzione. In questa guida rileggo il fenomeno con la mia ottica di consulente: come funziona, perché è sottile, e cosa fare se gestisci siti altrui — che è esattamente il lavoro di chi scrive assistenza WordPress per mestiere.

Cos'è un attacco supply chain (e perché non lo vedi)

Un attacco diretto è riconoscibile: sito lentamente compromesso, file strani, redirect. Un attacco supply chain è un'altra cosa, e nel podcast Ginder lo distingue con precisione: l'attaccante non entra nel tuo sito, entra nell'ecosistema che ti rifornisce. I modelli principali sono due. Nel primo si compra l'azienda di un plugin — un prodotto reale, con utenti veri, installazioni attive — e lo si arma dal dentro: una versione successiva, apparso innocua, contiene il payload. Nel secondo si dirotta il canale di aggiornamento: il plugin smette di parlare con wordpress.org e inizia a scaricare da un server estraneo, dove l'update che ti arriva non è quello che pensi.

Il dettaglio che rende questi attacchi particolarmente sottili è lo spostamento del server di update. L'utente medio non ha motivo di guardare da dove arriva un aggiornamento: vede la notifica, preme aggiorna, sente che tutto funziona. Se il codice malevolo è costruito bene, non rompe nulla — e questo è il problema. Un'infrazione visibile si segnala da sola; un'infrazione silenziosa si installa e aspetta.

Il progetto WP Beacon: mappare un problema diffuso

Dalla scoperta accidentale Ginder è arrivato a un progetto pubblico, WP Beacon, con un obiettivo semplice da dire e difficile da fare: tracciare, documentare e segnalare alla community gli attacchi supply chain noti. Il valore non è il singolo avviso — quelli arrivano comunque dai vari vendor — è il pattern: plugin comprati e armati, canali di update dirottati, casi che tornano con varianti diverse. E qui viene la parte che mi ha colpito di più dell'intervista: Ginder non si presenta come un esperto di sicurezza, ma come uno sviluppatore con automazioni WP-CLI e script bash che si è trovato al posto giusto. È stato l'AI a rendergli possibile l'indagine: pattern in migliaia di log, radici comuni tra infezioni su hosting diversi, lavoro da forensi che un tempo richiedeva un team.

Il limite del metodo è anche il più interessante: una persona con l'AI può fare l'indagine, ma la difesa vera sta a monte — negli hosting e nel repository, con audit su oltre 60.000 plugin. Il passaggio da indagine individuale a monitoraggio automatizzato di sistema è il gradino mancante, e l'episodio lo dice chiaramente: serve collaborazione tra host e ricercatori, non eroi solitari.

Il caso: tre bonifiche, una radice

Il mio caso più recente di questa famiglia è arrivato a luglio. Un sito WooCommerce cliente, 800 ordini al mese, infettato tre volte in sei settimane: skimmer sul checkout, pulizia, recidiva. Le prime due volte abbiamo cercato nel solito posto — plugin scaduti, password deboli, temi nulled — e non abbiamo trovato niente di tutto questo. La terza volta abbiamo cambiato metodo: abbiamo preso un file del payload e risalito la catena. Il vettore era un plugin di marketing automation che era passato di proprietà sei settimane prima: l'update delle 15:04 era arrivato da un server che non era wordpress.org, con un certificato valido e un dominio registrato da poco. Il plugin non era nella lista dei "fuori aggiornamento" che controllo sempre: era aggiornato, ed era proprio lui il problema.

Cosa abbiamo fatto, in ordine: rimosso il plugin (non sostituibile con un'alternativa seria a quel momento, quindi funzionalità dismessa e rimpiazzata con una sequenza di wp-hooks interni), ruotate tutte le credenziali, aggiunto al flusso di assistenza un controllo del canale di update sui plugin critici. Dalla terza pulizia, zero recidive in due mesi. Non è la regola: è l'eccezione che senza quel controllo sarebbe diventata la regola.

Il playbook operativo: prima, durante, dopo l'update

Riporto qui il protocollo che uso io ora su ogni sito che gestisco, nella forma più compatta. Non sostituisce il giudizio — e per questo c'è chi lo fa per te — ma è ciò che farei io stesso:

# da dove arriva l'update? i canali custom sono il segnale d'allarme n.1
wp plugin list --fields=name,update_version,version --format=csv --allow-root
# quando è cambiata l'ultima versione, e cosa dice il changelog ufficiale
wp plugin get nome-plugin --fields=version,update_version --allow-root

• Prima dell'update: su siti critici, cambio di proprietà del vendor o versioni saltate a vuoto sono un segnale. Il changelog e la pagina del plugin si controllano in un minuto; un sito WooCommerce infettato costa settimane.
• Durante: staging prima del live per i siti che non possono permettersi fermo. Se usi aggiornamenti automatici, escludi da quelli automatici i plugin con canali di update esterni a wordpress.org — è il pattern sospetto per eccellenza.
• Dopo: file diff sul plugin aggiornato se il sito è sensibile, e controllo che non siano comparsi file PHP dove non c'erano. I tool di integrità aiutano; un occhio umano su un sito serio no.

La parte scomoda è che il 99% degli update è innocuo, e trattarli tutti come sospetti è insostenibile. Per questo la mia posizione è la stessa che ho descritto in hosting WordPress sicuro: non è paranoia diffusa, è protocollo sui punti d'ingresso che valgono. Il resto va gestito con manutenzione regolare, che è dove i veri rischi — plugin scaduti, CVE note, credenziali — si chiudono da soli.

Cosa fare questa settimana

Se gestisci anche un solo sito che genera reddito, la sequenza minima è questa: verifica che i plugin con update automatico usino canali wordpress.org, controlla data di cambio proprietà sui plugin critici (la pagina del changelog la riporta quasi sempre), aggiungi il controllo del canale di update alla tua routine mensile. Se il pensiero di fare questo su tutti i tuoi siti ti mette ansia — e mettere ansia è esattamente quello che fa — non è un difetto tuo: è il momento di dividere il lavoro. La parte ripetitiva va a chi ha protocollo e automazioni (l'assistenza WordPress, per capirsi), la parte di giudizio resta a te. E se vuoi leggere l'altro lato del problema — cosa succede quando l'update non arriva proprio — l'articolo sui plugin senza patch descrive la posizione opposta dello stesso treno.

Riferimenti utili

• WP Tavern #219: Austin Ginder, how AI is exposing hidden threats in WordPress plugin updates
• Anchor Hosting: il servizio di Austin Ginder
• WP Beacon: monitoraggio della supply chain dei plugin
• Sicurezza WordPress nell'era AI: la corsa agli armamenti
• Plugin WordPress vulnerabile: 3,25 milioni di siti esposti
• Manutenzione WordPress: la routine mensile
• Assistenza WordPress: piani e interventi