BGP hijacking colpisce Virtualizor, Packagist diffonde spyware sugli iPhone

🛡️ Executive Summary

• Un BGP hijacking ha deviato il traffico Softaculous e consentito di distribuire un aggiornamento Virtualizor malevolo attraverso un certificato TLS valido.
• Tredici temi Composer su Packagist iniettano JavaScript nei siti e colpiscono iPhone non aggiornati con una catena WebKit-to-kernel.
• Operatori Virtualizor devono cercare java-jre-update.service; gli utenti iPhone devono installare gli aggiornamenti che correggono le vulnerabilità WebKit sfruttate.

Due attacchi tecnicamente molto diversi mostrano lo stesso problema strutturale della supply chain software: la fiducia può essere compromessa senza violare direttamente il sistema della vittima. Nel primo caso gli aggressori hanno dirottato tramite BGP il traffico diretto ai servizi di Softaculous, riuscendo a distribuire un aggiornamento malevolo di Virtualizor. Nel secondo, 13 pacchetti Composer pubblicati su Packagist trasformano siti di streaming basati su Laravel in vettori per una catena di exploit contro iPhone non aggiornati, capace di arrivare dal browser al kernel e sottrarre dati, password e seed dei wallet crypto. Il filo comune è la compromissione di un passaggio normalmente considerato affidabile.

Virtualizor: il BGP hijacking trasforma il routing in un attacco agli aggiornamenti

L’incidente Virtualizor si è sviluppato tra le 20:57 UTC del 28 agosto e le 06:10 UTC del 30 agosto 2026. Secondo la ricostruzione tecnica pubblicata da Virtualizor, il prefisso 162.55.80.0/24, appartenente all’infrastruttura Hetzner utilizzata da Softaculous, è stato annunciato senza autorizzazione da AS62390, NexonHost, attraverso AS6204, Zet.net. La rotta /24 era più specifica del normale annuncio Hetzner 162.55.0.0/16 e ha quindi prevalso sulle reti che l’hanno accettata. L’elemento più critico è che l’attaccante non si è limitato a deviare il traffico: ha potuto ottenere anche un certificato TLS tecnicamente valido di Let’s Encrypt, perché la stessa procedura automatizzata di verifica del dominio è transitata attraverso la rotta dirottata. Un client diretto verso virtualizor.com, api.virtualizor.com o files.virtualizor.com poteva quindi comunicare con l’infrastruttura ostile senza ricevere un errore di certificato. Virtualizor conferma che un piccolo numero di server che ha verificato la presenza di aggiornamenti durante le finestre di intercettazione ha ricevuto un pacchetto software malevolo. Il problema è stato aggravato dal fatto che il client di aggiornamento non effettuava ancora una verifica crittografica della firma dei pacchetti: controllare correttamente HTTPS non bastava più, perché il livello di routing e quello di validazione TLS erano entrambi finiti sotto il controllo dell’attaccante.

Leggi anche: Cloudflare e il leak BGP IPv6: come un errore di routing può propagarsi su Internet

Un certificato valido non ha protetto la catena di aggiornamento

La particolarità dell’incidente rende insufficiente la classica lettura dell’attacco Man-in-the-Middle basato su un certificato invalido. Virtualizor stima che, durante le fasi più intense, la rotta abusiva sia stata visibile a una porzione estremamente ampia dei peer osservati dal Routing Information Service di RIPE. L’attività si è articolata in due ondate, separate da circa undici ore nelle quali la deviazione è praticamente scomparsa. Virtualizor segnala inoltre circa 10.600 ritiri di rotta durante l’intera finestra, segno di una propagazione molto instabile. Per chi gestisce server Virtualizor l’indicatore più importante è /etc/systemd/system/java-jre-update.service: la presenza della relativa unità systemd indica, secondo il vendor, che il server è stato compromesso e non dovrebbe essere semplicemente “ripulito” cancellando il file, perché sarebbe necessario preservare le evidenze. Gli amministratori devono inoltre ruotare le chiavi API, limitare gli accessi alle API agli indirizzi fidati, controllare chiavi SSH sconosciute, nuovi utenti, cron job e connessioni in uscita anomale. Virtualizor ha distribuito la versione 3.2.9.9 con uno strumento di mitigazione e ha annunciato l’introduzione della firma del codice per tutti i pacchetti, una misura decisiva perché separa l’autenticità dell’aggiornamento dall’affidabilità del percorso di rete utilizzato per scaricarlo. L’episodio porta su scala ostile un problema già visibile nei precedenti incidenti BGP: proteggere TLS non significa proteggere automaticamente l’intera catena di distribuzione.

Packagist: 13 temi trasformano siti Laravel in vettori contro gli iPhone

Il secondo caso sposta la compromissione dal routing ai repository software. Socket Threat Research ha identificato 13 temi Composer malevoli su Packagist, distribuiti attraverso cinque namespace: vsmov, vsphim, haiau009, chilltvcms e ophimcms. I pacchetti sono presentati come temi per OphimCMS e KKPhim, sistemi PHP basati su Laravel utilizzati soprattutto da portali vietnamiti dedicati a film, fumetti e contenuti streaming. L’operatore del sito esegue normalmente composer require, installa il tema e con esso distribuisce automaticamente gli asset JavaScript inclusi. Gli aggressori hanno sfruttato proprio questo rapporto di fiducia: mantengono intatta buona parte della struttura originale dei progetti, ma modificano gli asset frontend in modo che ogni visitatore del sito riceva codice controllato dagli attaccanti.

Non viene quindi compromessa soltanto la macchina dello sviluppatore. Il sito legittimo diventa un watering hole capace di attaccare direttamente i propri visitatori. È un’evoluzione della stessa superficie d’attacco emersa a marzo, quando pacchetti Laravel su Packagist nascondevano un RAT PHP nelle dipendenze Composer: in quel caso il bersaglio era il server che installava il pacchetto; nella nuova campagna, il pacchetto compromesso trasforma invece il server in un distributore di exploit verso terzi.

Da WebKit al kernel iOS fino alle seed phrase dei wallet

La catena più pericolosa viene attivata contro dispositivi mobili e seleziona versioni specifiche del sistema. Un loader inserito dopo jQuery recupera JavaScript da infrastruttura FUNNULL, crea un iframe invisibile, identifica la versione di iOS e seleziona l’exploit appropriato. Gli attaccanti utilizzano CVE-2025-31277 e CVE-2025-43529 per ottenere primitive di lettura e scrittura nel renderer WebContent e proseguire verso il processo GPU e il kernel.

Il comportamento presenta sovrapposizioni tecniche con la catena DarkSword già osservata contro dispositivi con iOS 18. Il bersaglio individuato da Socket comprende iOS 18.4 fino alla famiglia 18.6.x e dispositivi dall’iPhone XS alla serie iPhone 16: le versioni più recenti non risultano supportate dalle tabelle di offset analizzate, segnale che gli operatori stanno puntando soprattutto su dispositivi rimasti indietro con le patch. Apple aveva corretto CVE-2025-31277 in iOS 18.6, descrivendo un problema WebKit di gestione della memoria, mentre CVE-2025-43529 è stata corretta nelle successive release e Apple ha confermato segnalazioni di sfruttamento in attacchi altamente sofisticati contro persone specifiche. Dopo la compromissione, il payload accede a Keychain, password Wi-Fi, SMS, contatti, foto, cookie, cronologia delle chiamate, dati di localizzazione e account, cifra la raccolta con AES e la invia ai server C2. Dal 12 agosto 2026 la campagna ha compiuto un ulteriore salto: il payload è stato ridistribuito con nuovi componenti e ha aggiunto routine dedicate alla ricerca delle seed phrase e delle mnemonic conservate da Bitget, BitKeep, Bitpie, Phantom, Tonkeeper, Trust Wallet e OKX.

La supply chain non finisce più al pacchetto installato

I due incidenti mostrano perché la definizione tradizionale di attacco supply chain sta diventando troppo stretta. Nel caso Packagist, la dipendenza malevola non rappresenta necessariamente l’ultimo payload: serve a trasformare un sito legittimo in un’infrastruttura di distribuzione, con una seconda catena che seleziona la vittima in base a dispositivo, sistema operativo e referrer. Socket segnala inoltre pacchetti pubblicati dagli stessi cinque vendor che al momento dell’analisi non contenevano un payload attivo, ma disponevano già di campi Custom JS e hook capaci di inserire codice nelle pagine. Sono quindi componenti potenzialmente “dormienti”, attivabili successivamente senza richiedere necessariamente una nuova installazione completa. Nel caso Virtualizor accade l’inverso: il software richiesto dall’amministratore è apparentemente quello corretto, il dominio è corretto e persino il certificato TLS è valido, ma il traffico viene portato verso un’origine diversa prima che il pacchetto raggiunga il server. La stessa crisi della fiducia interessa da mesi gli ecosistemi dei package manager, dove GitHub e npm hanno introdotto nuove difese contro compromissioni di pacchetti e account di pubblicazione. Il punto non è quindi soltanto verificare da quale repository provenga un file, ma costruire una catena nella quale identità del publisher, integrità del pacchetto, firma, percorso di distribuzione e comportamento runtime possano essere verificati indipendentemente.

Continua con:

• Sapphire Sleet compromette 140 pacchetti npm Mastra attraverso un singolo account maintainer
• Chrome ed Edge: 19 estensioni trasformano gli aggiornamenti legittimi in wallet drainer

Aggiornare non basta se non si verifica anche ciò che viene installato

Per gli utenti iPhone la misura principale resta semplice: installare le versioni più recenti di iOS, perché la catena analizzata da Socket dipende da vulnerabilità già corrette. Per gli amministratori di siti OphimCMS e KKPhim è invece necessario confrontare le dipendenze installate con i tredici pacchetti individuati, rimuovere quelli compromessi, ruotare le credenziali disponibili sul server e controllare jQuery, script dei temi e richieste verso gli indicatori pubblicati. Gli operatori Virtualizor devono considerare l’intera finestra del 28-30 agosto potenzialmente rilevante, cercare java-jre-update.service, verificare accessi e persistenza e ruotare le credenziali API. Ma la lezione più ampia riguarda chi progetta piattaforme e sistemi di aggiornamento: HTTPS da solo non garantisce l’integrità del software e un repository ufficiale non garantisce che una dipendenza sia affidabile. Firma crittografica dei pacchetti, pinning delle versioni, controllo delle dipendenze, protezione degli account maintainer, verifica degli artefatti in CI/CD e difese a livello di routing devono diventare livelli indipendenti. I due attacchi di fine agosto mostrano la stessa debolezza da due estremità opposte: gli aggressori non devono necessariamente violare direttamente una macchina se riescono a convincerla che ciò che sta ricevendo proviene ancora da una fonte fidata.