Backdoor nella supply chain WordPress: l'attacco al canale di update ShapedPlugin

Nessuno ha scaricato il file sbagliato. Gli amministratori compromessi hanno fatto esattamente ciò che ogni checklist di sicurezza prescrive: hanno tenuto aggiornati i loro plugin a pagamento, scaricando release firmate dal server di update con licenza del fornitore. L'aggiornamento era l'attacco. Tra il 21 maggio e la divulgazione pubblica di metà giugno 2026, tre prodotti commerciali di ShapedPlugin hanno distribuito una backdoor che rubava credenziali attraverso il canale legittimo — e su ogni sito infetto la dashboard delle patch è rimasta verde per tutto il tempo.

È il modello di fallimento per cui la compromissione della supply chain è stata costruita, e vale la pena soffermarci perché l'ecosistema WordPress lo rende insolitamente concreto. Non c'era una CVE da cercare nel senso usuale, nessuna patch mancante, nessuna porta esposta. L'intero stack preventivo del difensore funzionava come previsto, puntato nella direzione sbagliata.

Cosa è successo nella backdoor supply chain di ShapedPlugin

ShapedPlugin è un fornitore di plugin WordPress i cui prodotti gratuiti contano oltre 400.000 installazioni attive. A giugno 2026 il team Wordfence Threat Intelligence (Defiant) ha confermato che gli attaccanti avevano compromesso la pipeline di build e distribuzione del fornitore, iniettando codice backdoor nelle build Pro di tre plugin a pagamento, distribuite attraverso il canale di update ufficiale con licenza. Le versioni gratuite su WordPress.org non sono state colpite.

Le release interessate, secondo il report di BleepingComputer:

• Product Slider Pro for WooCommerce — prima della 3.5.4
• Real Testimonials Pro — 3.2.5
• Smart Post Show Pro — prima della 4.0.2

La cronologia conta, perché mostra per quanto tempo un update avvelenato-ma-legittimo passa inosservato. La backdoor è stata iniettata nella pipeline di build il 21 maggio 2026. Le prime segnalazioni dei clienti su comportamenti sospetti sono emerse il 10 giugno. Wordfence ha confermato l'infezione il 12 giugno e ShapedPlugin ha riconosciuto l'incidente il 16 giugno (analisi di securityaffairs). Circa tre settimane durante le quali gli amministratori installavano la backdoor come atto di buona igiene. L'incidente è tracciato come CVE-2026-10735, con la compromissione di Product Slider Pro che porta un proprio identificatore di gravità massima, CVE-2026-49777, riportato a CVSS 10.0.

Perché una backdoor supply chain WordPress batte la dashboard delle patch

Gran parte del budget preventivo di un difensore serve a confermare che il software sia aggiornato e autentico. Gli scanner di patch segnalano le versioni vecchie. I canali di update verificano i token di licenza. I WAF si fidano del traffico che parte dall'interno del pannello admin. I controlli di integrità confrontano un plugin con la release pubblicata dal fornitore — che, qui, è l'artefatto malevolo.

Ognuno di questi controlli restituiva un risultato pulito su un sito ShapedPlugin infetto. La versione era l'ultima. La licenza era valida. Il download veniva dal fornitore. Il codice girava dentro una sessione admin autenticata. Non c'è alcun mismatch di firma da rilevare quando la firma è sulla backdoor.

"Siamo completamente patchati. Wordfence è installato. I plugin sono le versioni più recenti, scaricate direttamente dal fornitore — fammi vedere cosa c'è che non va."

Tutto ciò che hai appena elencato è vero, e niente di tutto questo è la domanda giusta. Il codice malevolo è arrivato perché eri aggiornato. L'unico posto in cui la compromissione è visibile è la conversazione che il tuo server ha iniziato con un host che non aveva mai contattato prima.

È il punto strutturale. Quando l'assunzione di input affidabile viene violata alla sorgente, i controlli lato host e lato identità non falliscono in modo rumoroso — passano. La compromissione diventa visibile solo come comportamento: una nuova connessione in uscita, una raffica di esfiltrazione, un login da un account fasullo proveniente da una rete sconosciuta. Il comportamento sta sul filo.

La kill chain, passo per passo

Il meccanismo, ricostruito dall'analisi di Wordfence e dal breakdown di threat-modeling.com, è un loader-più-stager da manuale, costruito per lasciare l'host il più silenzioso possibile:

1. Trigger al login admin. Un loader malevolo (LicenseLoader.php) dentro il plugin Pro si attiva alla successiva apertura del pannello admin da parte di un amministratore — non su una richiesta pubblica, così gli scanner esterni non lo vedono mai.
2. Chiamata a casa. Il loader contatta il proprio endpoint di command-and-control (cdn-stats-api[.]com o suoi sottodomini) — un nome scelto per sembrare innocuo traffico di analytics.
3. Stage della vera backdoor. Scarica un secondo stage e lo installa come plugin fasullo chiamato woocommerce-subscription o woocommerce-notification, mimetizzandosi in una normale installazione WooCommerce.
4. Cancellazione del punto d'ingresso. Il loader poi si auto-elimina. Il dropper che ha fatto il lavoro non c'è più; ciò che resta è camuffato da normale strumentazione di e-commerce.
5. Persistenza fuori portata. La backdoor di secondo stage e un account amministratore fasullo (wp_support_sys) sopravvivono alla normale disattivazione e rimozione del plugin — disinstallare il plugin incriminato non pulisce il sito.
6. Esfiltrazione. Raccoglie credenziali admin di WordPress e segreti 2FA, credenziali del database (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) e i salt di wp-config.php, impostazioni SMTP e fino a tre mesi di dati su ordini e metodi di pagamento WooCommerce — il tutto spedito al C2.

Il loader che si auto-elimina è il segnale rivelatore. L'attaccante ha rimosso deliberatamente l'artefatto host più ovvio mantenendo l'accesso. Ciò che non ha potuto rimuovere è l'impronta di rete, perché l'esfiltrazione richiede traffico in uscita e la persistenza richiede una callback. Ecco com'è fatta quell'impronta:

Indicatore	Dove risiede	Visibile agli strumenti host?
Uscita verso cdn-stats-api[.]com	Egress di rete	Solo se ispezioni il traffico
Plugin fasullo woocommerce-*	Filesystem	Sopravvive alla rimozione; sembra legittimo
Admin fasullo wp_support_sys	Tabella wp_users	Sì, se controlli gli account
RewriteRule in .htaccess verso domini esterni	Webroot	Facile da non notare
Chiavi wp_options _wp_sp_ / _tmp_sp	Database	Facile da non notare
Raffica di esfiltrazione credenziali / ordini	Egress di rete	Solo se ispezioni il traffico

Due degli indicatori a più alto segnale — la chiamata C2 iniziale e l'esfiltrazione dei dati — esistono solo sul filo. Quelli lato host o si mimetizzano o richiedono un audit che non hai motivo di lanciare, perché niente ti ha detto che il sito era compromesso.

Non è un problema di WordPress

È tentante archiviare il caso come "WordPress è caotico" e andare oltre. È una lettura errata del trend. La compromissione della supply chain è ormai una delle categorie di incidente in più rapida crescita in ogni ecosistema, non una stranezza dei CMS.

• L'ENISA Threat Landscape 2025 ha attribuito il 10,6% di 4.875 incidenti analizzati (luglio 2024–giugno 2025) ad attacchi alla supply chain del software, e ha indicato la compromissione di fornitori software, integratori cloud, partner MSP/MSSP e pipeline CI/CD tra i pattern in più rapida crescita.
• Il Data Breach Investigations Report 2025 di Verizon ha raddoppiato la quota di breach da terze parti dal 15% al 30% — il maggior cambiamento in un singolo anno nella storia della serie.
• Il report supply-chain 2026 di Sonatype ha contato oltre 454.600 nuovi pacchetti open-source malevoli solo nel 2025, un salto di circa il 75% anno su anno; ReversingLabs ha registrato in modo indipendente un +73% comparabile.

Il filo comune è che l'attaccante non cerca più di rompere un controllo che possiedi. Sta sovvertendo un input che hai già deciso di considerare affidabile — il build server di un fornitore, un registry di pacchetti, un canale di update. Il caso ShapedPlugin è lo stesso pattern al livello del sito e-commerce di una singola PMI: il confine di fiducia si è spostato a monte, in un punto che i tuoi scanner non possono vedere, e l'unica cosa che è rientrata nella tua visibilità è stato il comportamento di rete.

Cosa deve davvero osservare il rilevamento

Se il livello preventivo è strutturalmente cieco agli update avvelenati-ma-autentici, il rilevamento deve assumere la breccia e osservarne le conseguenze. Per questa classe di attacco quelle conseguenze hanno una forma quasi interamente di rete:

• Un web server che storicamente serviva soltanto contenuti apre improvvisamente sessioni in uscita verso un dominio mai visto prima su un ASN sconosciuto.
• Il segnale temporale di un beacon che scatta al login admin invece che su uno schedule.
• Una breve e densa raffica di esfiltrazione — credenziali, salt, tre mesi di dati ordini — che lascia un host che normalmente invia quasi nulla all'esterno.
• Traffico laterale o di follow-on dall'account fasullo una volta che l'attaccante usa le credenziali rubate.

Niente di tutto questo dipende dal conoscere la CVE, dall'avere una firma per LicenseLoader.php o dall'essere stati avvisati dal fornitore. Dipende dall'aver osservato il filo e aver imparato che aspetto ha il normale per quell'host, così che l'egress anomalo salti all'occhio nell'istante in cui accade — non tre settimane dopo, quando un cliente nota che qualcosa non va.

Dove si colloca Zero Hunt

È lo scenario per cui è stata costruita l'AI Traffic Analysis di Zero Hunt. Quando l'host è compromesso attraverso un update fidato e il loader si cancella da solo, la rete è l'unico testimone onesto rimasto. Zero Hunt esegue un modello proprietario di deep learning — addestrato su miliardi di sequenze PCAP, con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) — interamente sulla GPU dell'appliance, con baseline di 2,7+ Gbit/s. Segnala la sessione in uscita anomala verso un endpoint mai visto e la raffica di esfiltrazione mentre stanno accadendo, su una macchina che callback e dropper auto-eliminanti non possono disabilitare in silenzio. Poiché gira on-prem senza callback verso il cloud, il traffico di ordini e credenziali che ispeziona non lascia mai il perimetro del cliente per essere analizzato.

Il lato offensivo chiude l'altra metà. Un plugin avvelenato è, in pratica, un asset sconosciuto che si comporta in modo nuovo, e le campagne attivate dal cambiamento di Zero Hunt trattano un nuovo plugin o una nuova versione sul perimetro come motivo per ri-testare entro l'ora, invece di aspettare la prossima revisione trimestrale. Lo swarm generativo a 10 agenti valida da una postura di assumed-breach — l'agente Credential verifica se segreti raccolti o di default autenticano ancora, gli agenti Post-Exploit e Pivot mappano cosa potrebbe davvero raggiungere un attaccante arrivato a quella sessione admin — e ogni finding è firmato ECDSA al momento della scrittura, così la prova di quando l'anomalia è comparsa per la prima volta regge a fronte di una timeline d'incidente. La lezione di ShapedPlugin non è "controlla i tuoi plugin con più attenzione". È che la fiducia riposta a monte va verificata a valle, sul filo, in modo continuo — perché quello è l'unico posto dove l'attaccante non può seguirti per ripulire.