Una nuova campagna scoperta il 25 agosto 2026 mostra un cambio di tattica che riguarda anche le aziende non tecniche: i criminali non stanno cercando di infettare chi installa pacchetti npm, ma stanno usando l’infrastruttura pubblica dei mirror come UNPKG per pubblicare pagine web ingannevoli su domini considerati affidabili. In pratica, una falsa verifica Cloudflare può apparire da un indirizzo “legittimo” e reindirizzare l’utente verso siti controllati dagli attaccanti.
Per un’azienda questo conta perché il rischio non nasce solo da email sospette o siti sconosciuti: sempre più spesso gli attacchi passano da servizi noti e reputati sicuri. È un promemoria importante: fidarsi del dominio, da solo, oggi non basta più.
Che cosa è successo
Secondo le analisi pubblicate da OX Security e riprese da The Hacker News e BleepingComputer il 25 agosto 2026, sono stati individuati 24 pacchetti npm usati come infrastruttura gratuita per campagne di phishing e reindirizzamento malevolo.
Il punto chiave è questo: i pacchetti non contengono un malware tradizionale pensato per colpire gli sviluppatori che li installano. Al loro interno c’è soprattutto una semplice pagina HTML, accompagnata dal file di configurazione del pacchetto. Una volta pubblicato il pacchetto, però, servizi mirror come UNPKG o npmmirror ne rendono accessibili i singoli file via browser. E così quella pagina HTML diventa, di fatto, una pagina web pubblica ospitata su un dominio affidabile.
Uno degli esempi riportati nelle fonti mostra un file index.html raggiungibile tramite un URL del tipo unpkg.com/nomepacchetto@1.0.0/index.html. Quando un utente apre quel link, il browser carica una falsa pagina di verifica Cloudflare che simula un controllo di sicurezza o un CAPTCHA. Anche se l’aspetto richiama un servizio legittimo, lo scopo reale è portare la vittima altrove.
Perché questa tecnica è diversa dal solito
Negli ultimi anni si è parlato molto di attacchi alla supply chain software: librerie compromesse, dipendenze malevole, aggiornamenti manipolati. In questo caso, però, il meccanismo è diverso.
L’obiettivo non è tanto compromettere il computer di uno sviluppatore tramite l’installazione del pacchetto, quanto sfruttare npm e i suoi mirror come “hosting gratuito” per contenuti ingannevoli. È un abuso dell’infrastruttura, non solo del software.
Questo rende la tecnica interessante per gli attaccanti per almeno tre motivi:
- il contenuto viene servito da un dominio conosciuto e spesso ben reputato;
- alcuni controlli di sicurezza possono essere meno severi verso piattaforme considerate legittime;
- i contenuti possono restare disponibili sui mirror anche se il pacchetto viene rimosso dal registro principale.
Le fonti sottolineano proprio questo aspetto: un mirror può continuare a mantenere copia del contenuto, prolungando la vita operativa della campagna anche dopo un’eventuale rimozione.
Come funziona il reindirizzamento
Le pagine individuate imitano una verifica Cloudflare e incorporano codice JavaScript offuscato. Dietro la grafica apparentemente innocua, lo script esegue un reindirizzamento verso un sito esterno controllato dagli attaccanti o comunque definito da loro.
Le prime versioni osservate nelle fonti rimandavano a domini che imitavano servizi Microsoft. Tra quelli citati compaiono login.microsofte.live e, in precedenza, microcloud.homes. In alcuni casi iniziali di luglio il reindirizzamento arrivava fino alla pagina autentica di accesso a Outlook sul dominio outlook.office.com/mail, probabilmente per rendere il flusso più credibile o preparare fasi successive della truffa.
Successivamente, dopo che uno dei domini è finito nelle liste di blocco di Google Safe Browsing, gli autori della campagna hanno cambiato approccio. Invece di inserire nel file HTML un indirizzo fisso, hanno usato api.keyval.org, un servizio legittimo di memorizzazione chiave-valore accessibile via API. Il browser recupera un valore remoto, lo decodifica e usa l’URL risultante come destinazione finale.
Questo dettaglio è importante perché aumenta la flessibilità dell’attacco: gli attaccanti possono cambiare il sito di destinazione senza dover ripubblicare il pacchetto npm. Al momento dell’analisi, una parte delle pagine portava addirittura al sito legittimo di ChatGPT. Ma le fonti chiariscono che la destinazione può essere cambiata in qualsiasi momento per puntare a pagine di phishing, raccolta credenziali o schemi di tipo ClickFix.
Che cos’è il rischio ClickFix in questo contesto
Le fonti collegano la campagna allo stile ClickFix, una tecnica di social engineering in cui la vittima viene spinta a compiere da sola un’azione dannosa. In pratica, invece di sfruttare una falla tecnica complessa, l’attaccante persuade l’utente a cliccare, autorizzare, copiare comandi o superare presunti controlli di sicurezza.
In questo scenario, la falsa pagina Cloudflare serve soprattutto a costruire fiducia. Se l’utente vede un dominio noto e una verifica “familiare”, è più propenso a proseguire senza sospetti. È qui che l’attacco diventa pericoloso anche fuori dal reparto IT: colpisce il comportamento umano prima ancora dei sistemi.
Un fenomeno già visto, ma in evoluzione
Le fonti ricordano che non è il primo abuso di questo tipo. BleepingComputer cita osservazioni precedenti di luglio, mentre The Hacker News richiama una campagna descritta da Socket nell’ottobre 2025, in cui 175 pacchetti npm sfruttavano la CDN di unpkg.com per ospitare script di reindirizzamento verso pagine di raccolta credenziali.
Il segnale da cogliere è chiaro: i criminali continuano a spostarsi verso servizi leciti, affidabili e a basso costo operativo. Questo complica la difesa, perché il confine fra traffico “normale” e traffico malevolo diventa meno netto.
Cosa significa per la tua azienda
Per una PMI italiana il messaggio non è “blocca npm”, ma “rivedi come valuti il rischio web e il comportamento degli utenti”. Alcune azioni pratiche sono particolarmente utili.
Primo: non considerare sicuro un link solo perché appartiene a un dominio noto. Anche un servizio legittimo può essere sfruttato per ospitare o inoltrare contenuti fraudolenti. Le policy di navigazione e i controlli del proxy o del filtro web dovrebbero considerare sospette le richieste dirette a file HTML su mirror di pacchetti, soprattutto se arrivano da email, chat o documenti condivisi.
Secondo: forma il personale su un concetto semplice ma essenziale. Le pagine che chiedono di “verificare di non essere un robot” fuori contesto, o prima di aprire un documento o accedere a un contenuto aziendale, meritano sempre diffidenza. Se poi compaiono istruzioni anomale o reindirizzamenti inattesi, l’utente deve fermarsi e segnalare.
Terzo: proteggi gli account, perché molte campagne di phishing puntano alle credenziali prima ancora di distribuire malware. L’autenticazione a più fattori, il controllo degli accessi e il monitoraggio dei login restano misure decisive. Se vuoi rafforzare questo fronte, una revisione della tua postura di sicurezza informatica è il punto di partenza più concreto.
Quarto: prepara una risposta rapida all’incidente. Se un dipendente apre un link sospetto o inserisce credenziali su una pagina dubbia, bisogna poter intervenire subito: cambio password, revoca sessioni, verifica dei log, controllo del dispositivo. Un servizio continuativo di gestione delle postazioni e delle policy può ridurre tempi e incertezze, soprattutto dove manca un reparto IT interno strutturato. In questi casi può essere utile valutare un supporto di desktop IT management.
Quinto: verifica la capacità di ripristino. Anche se questa campagna nasce come phishing e reindirizzamento, il passo verso il malware è breve. Un buon piano di copie di sicurezza isolate e controllate resta una rete di protezione essenziale. Se il tuo backup è solo locale o non viene testato, è il momento di rivederlo, ad esempio con una soluzione di remote backup.
Cosa controllare subito in pratica
Se vuoi un elenco operativo da condividere con il responsabile d’ufficio o con il fornitore IT, concentrati su questi punti:
- verifica se i sistemi di filtro web registrano accessi a URL su
unpkg.como altri mirror con file.htmlaperti direttamente; - controlla se utenti hanno ricevuto link tramite email, Teams, Slack o WhatsApp aziendale che puntano a domini tecnici poco familiari;
- conferma che l’MFA sia attiva almeno per posta elettronica, Microsoft 365, VPN e gestionali esposti online;
- aggiorna le istruzioni interne: mai inserire credenziali dopo reindirizzamenti inattesi, anche se il sito iniziale sembra affidabile;
- stabilisci una procedura semplice di segnalazione: screenshot, link ricevuto, orario, utente coinvolto.
Non serve creare allarmismo, ma serve velocità. In attacchi di questo tipo, il valore sta nella finestra di tempo tra clic e rilevazione.
Perché questa notizia va oltre gli sviluppatori
A prima vista npm sembra un tema da programmatori. In realtà la lezione è molto più ampia: gli attaccanti stanno imparando a sfruttare la reputazione di piattaforme terze per aggirare la diffidenza degli utenti e, in parte, dei sistemi automatici.
Questo vale per i mirror di pacchetti oggi, ma lo stesso schema può comparire domani su servizi cloud, strumenti di collaborazione, piattaforme di storage o pagine ospitate su infrastrutture note. Per chi guida un’azienda significa una cosa sola: la sicurezza non può basarsi su liste di siti “buoni” e “cattivi”, ma su controlli stratificati, formazione e processi chiari.
Domande frequenti
Installare uno di questi pacchetti infetta automaticamente il computer?
No, secondo le fonti il punto non è infettare chi installa il pacchetto. Il rischio principale è l’uso del contenuto HTML ospitato sui mirror come pagina di phishing o reindirizzamento.
Se il dominio è legittimo, posso fidarmi?
No. In questo caso il dominio del mirror può essere legittimo, ma il contenuto servito può essere stato caricato da un attaccante tramite un pacchetto pubblicato ad hoc.
Una PMI senza sviluppatori deve preoccuparsi lo stesso?
Sì. Il bersaglio finale può essere qualsiasi utente aziendale che apra un link e inserisca credenziali o segua istruzioni ingannevoli. Il tema è il phishing, non solo lo sviluppo software.