Malware npm e NuGet colpiscono la supply chain mentre esplodono le app vibe-coded

La supply chain software torna sotto pressione con una serie di casi che mostrano la convergenza tra malware nei repository di pacchetti, abuso di ecosistemi open source e crescita incontrollata delle applicazioni generate con strumenti AI low-code. Il pacchetto npm mouse5212-super-formatter si presenta come utility innocua ma agisce come infostealer, esfiltra file dalla directory /mnt/user-data e finisce persino per esporre il proprio token GitHub hardcoded. In parallelo, il pacchetto NuGet Sicoob.Sdk impersona un presunto SDK bancario brasiliano, ruba credenziali di produzione, password PFX e certificati codificati in base64, sfruttando la fiducia degli sviluppatori nelle librerie distribuite tramite repository pubblici. A completare il quadro ci sono oltre 2000 app vibe-coded esposte su internet con dati sensibili accessibili senza protezioni adeguate, nate da piattaforme di sviluppo assistito dall’intelligenza artificiale e pubblicate da utenti non tecnici fuori dai normali processi di controllo IT. Il risultato è una superficie di attacco più ampia, più rapida e più difficile da governare, dove un pacchetto installato in una pipeline CI/CD o una dashboard aziendale generata in pochi minuti possono diventare il punto d’ingresso verso token, segreti, dati operativi e sistemi di produzione.

Il malware npm mouse5212-super-formatter ruba file e tradisce il proprio token GitHub

Il pacchetto npm mouse5212-super-formatter rappresenta un caso emblematico di malware nascosto dentro un componente apparentemente innocuo della catena di sviluppo. Scoperto da OX Security il 27 maggio 2026, il pacchetto raggiunge 676 download e resta attivo su npm al momento della segnalazione, dimostrando quanto rapidamente una libreria malevola possa entrare nei flussi di lavoro degli sviluppatori prima di essere riconosciuta come minaccia. Il codice si presenta come utility di sincronizzazione con repository GitHub, ma in realtà legge ricorsivamente la directory /mnt/user-data sul sistema della vittima, raccoglie i file presenti e li carica su un repository remoto controllato dall’attaccante. La logica di esfiltrazione usa un token GitHub privato hardcoded come meccanismo di fallback per l’autenticazione, ma proprio questa scelta operativa finisce per esporre il token e consente ai ricercatori di osservare parte delle attività di furto. Il malware crea cartelle casuali per ogni sessione di esfiltrazione, codifica i file in base64 e sfrutta l’API GitHub Contents per caricare i dati in modo ordinato sul repository remoto. L’attaccante maschera il comportamento con un falso log di connessioni di rete, così da presentare l’attività come normale diagnostica o sincronizzazione. L’account GitHub usato per ricevere i file viene creato poche ore prima del caricamento del pacchetto e cancellato dopo l’attacco, un comportamento compatibile con un’operazione opportunistica e a breve finestra. Il caso mostra come i repository pubblici possano essere abusati non solo per distribuire codice malevolo, ma anche come infrastruttura di esfiltrazione, sfruttando servizi legittimi per rendere più difficile il blocco immediato.

L’esfiltrazione su GitHub mostra la maturità del malware Slop

Il meccanismo attribuito al malware Slop su npm evidenzia una progettazione semplice ma efficace. Il codice tenta prima l’autenticazione verso GitHub usando un token ambiente e, in caso di assenza, ricorre al token hardcoded incorporato nel pacchetto. Dopo l’autenticazione, controlla l’esistenza del repository target e lo crea se necessario, quindi avvia la scansione ricorsiva della directory /mnt/user-data, area particolarmente sensibile negli ambienti containerizzati o nei sistemi dove vengono montati volumi con file utente, configurazioni, segreti o output di lavoro. Ogni sessione di furto genera una cartella unica nel repository remoto, così da separare i contenuti prelevati da vittime o esecuzioni differenti. I file vengono codificati in base64 prima del caricamento tramite API GitHub Contents, una scelta che facilita il trasporto dei dati e riduce problemi di compatibilità con contenuti binari o formati eterogenei.

Il log fasullo inserito nel pacchetto serve a depistare analisi superficiali e a far sembrare il comportamento parte di una normale attività di rete. La presenza del token leakato consente ai ricercatori di osservare sette eventi di esfiltrazione attivi, elemento che suggerisce test e utilizzo del malware in tempo reale. Per gli sviluppatori, il rischio è immediato: basta installare un pacchetto apparentemente utile perché un ambiente locale, un container o una pipeline possa consegnare file sensibili a un repository esterno. Il caso conferma che la fiducia implicita nei pacchetti npm resta uno dei punti più deboli della sicurezza applicativa moderna.

Il falso Sicoob.Sdk su NuGet colpisce credenziali bancarie e certificati PFX

Il pacchetto NuGet Sicoob.Sdk alza ulteriormente il livello del rischio perché impersona un presunto SDK ufficiale per le API di Sicoob, uno dei principali sistemi finanziari cooperativi del Brasile. Scoperto da Socket, il malware riguarda le versioni dalla 2.0.0 alla 2.0.4 e raggiunge 484 download complessivi, prendendo di mira sviluppatori e aziende impegnati in integrazioni finanziarie potenzialmente legate a pagamenti, transazioni Pix, boleto e servizi Open Finance. Il pacchetto esfiltra client ID, password PFX e contenuti di certificati PFX codificati in base64, cioè elementi estremamente critici in ambienti di produzione.

L’attività malevola si attiva durante l’istanziazione di SicoobClient quando il parametro isSandbox è impostato su false, quindi quando il codice opera in modalità produzione e non durante i test in ambiente sandbox. Questa scelta riduce la probabilità che il comportamento venga intercettato durante una verifica preliminare e massimizza il valore dei dati rubati. L’esfiltrazione avviene tramite abuso di Sentry, con un DSN hardcoded e invio dei dati sensibili attraverso SentrySdk.CaptureMessage. Il pacchetto include anche undici dipendenze associate, tra cui Sicoob-Cooperativa.Sicoob.Auth e Sicoob-Cooperativa.Sicoob.Pix, rafforzando l’apparenza di legittimità. L’account NuGet sicoob e l’organizzazione GitHub Sicoob-Cooperativa vengono creati il 4 maggio 2026, mentre il repository GitHub mostra codice pulito e il pacchetto distribuito su NuGet contiene la logica malevola. Questa discrepanza tra source e artifact è una tecnica classica di mascheramento nella supply chain: chi controlla il repository sorgente vede un progetto apparentemente sicuro, mentre chi installa il pacchetto riceve codice compromesso.

Il malware NuGet si attiva solo in produzione per evitare i controlli

Il funzionamento del malware NuGet durante l’istanziazione di SicoobClient è costruito per colpire nel momento di massimo valore operativo. Il costruttore legge il file PFX dal disco tramite File.ReadAllBytes, codifica il contenuto in base64 e costruisce un messaggio che include client ID, password in chiaro e certificato digitale. Il payload viene poi inviato all’endpoint Sentry configurato con DSN hardcoded, sfruttando un servizio legittimo per trasferire dati sensibili senza apparire immediatamente come comunicazione verso infrastruttura criminale. L’attivazione condizionata alla modalità produzione è il dettaglio più pericoloso: in sandbox il malware resta silenzioso, evitando di allertare sviluppatori e tester durante le prove.

Una volta integrato in sistemi reali, però, il pacchetto può consegnare credenziali bancarie utilizzabili per accessi, transazioni o ulteriori movimenti laterali. Il rischio cresce in ambienti CI/CD, dove segreti, certificati e password vengono spesso montati automaticamente per consentire build, test e deploy senza intervento manuale. Dopo la segnalazione, il pacchetto viene rimosso da NuGet e vengono notificati Sicoob e Sentry, ma la finestra di esposizione resta significativa per chi ha già installato le versioni compromesse. Il caso dimostra che l’impersonificazione di SDK legittimi consente agli attaccanti di aggirare la necessità di exploit complessi: basta convincere sviluppatori e pipeline a importare il componente giusto nel contesto sbagliato.

Le app vibe-coded esposte trasformano l’AI low-code in rischio aziendale

Il terzo fronte riguarda le oltre 2000 app vibe-coded esposte su internet senza controlli adeguati. Red Access identifica più di 380.000 asset web pubblici collegati a piattaforme di sviluppo AI, circa 5000 app di apparente natura aziendale e oltre 2000 applicazioni contenenti dati sensibili. Il fenomeno nasce dalla crescita di strumenti che permettono a utenti non tecnici di creare applicazioni partendo da descrizioni in linguaggio naturale. Manager di marketing, operations, finanza o vendite possono generare in poche ore dashboard, tracker di campagne, form di intake fornitori, strumenti collegati a CRM, ERP, sistemi di ticketing e database cloud. Il problema è che molte di queste app vengono pubblicate su URL pubblici, con accesso admin di default o senza autenticazione robusta, e si collegano direttamente a sistemi di produzione tramite OAuth o API key. Non serve alcun exploit per accedere ai dati: basta trovare l’app esposta. La gravità del fenomeno deriva dal fatto che i dati fluiscono da cloud a cloud, spesso interamente nel browser, sfuggendo ai controlli tradizionali di EDR, DLP e CASB. Gli strumenti endpoint vedono attività apparentemente legittima, i CASB riconoscono la piattaforma AI come singolo vendor ma non distinguono le singole app custom, mentre l’IT può non avere alcun inventario degli strumenti creati dai dipendenti. Il risultato è un nuovo tipo di Shadow IT, non più limitato all’uso non autorizzato di software esterni, ma esteso alla pubblicazione di vere applicazioni aziendali generate con AI e lasciate accessibili in rete.

La sicurezza aziendale perde visibilità su sessioni browser e app custom

L’impatto delle app vibe-coded sulla sicurezza aziendale è immediato perché sposta la creazione di software fuori dai processi tradizionali di governance. Dipendenti non tecnici possono risolvere problemi operativi in poche ore, ma pubblicano applicazioni che non passano da revisione del codice, threat modeling, controllo degli accessi, gestione dei segreti o validazione privacy. Le aziende possono superare audit formali mentre decine di app generate con AI low-code restano esposte pubblicamente con dati reali. Il punto cieco principale è la visibilità a livello di sessione browser. Gli strumenti di sicurezza vedono traffico verso una piattaforma autorizzata, ma non sempre distinguono se l’utente sta solo usando un servizio legittimo o se ha creato una dashboard pubblica collegata a sistemi produttivi. Il fenomeno cresce perché ogni mese nuovi utenti generano nuove app, spesso senza percepirle come software aziendale da censire. Le esposizioni attraversano settori e continenti, rendendo il problema trasversale. La mancanza di inventario impedisce una remediation completa: non si può proteggere ciò che non si sa di avere. Per questo la prima misura non è necessariamente tecnica, ma organizzativa. Le aziende devono chiedere esplicitamente ai dipendenti quali strumenti hanno creato, quali sistemi collegano, quali dati trattano e se sono raggiungibili pubblicamente. Solo dopo questa mappatura diventano possibili classificazione del rischio, revoca di accessi, introduzione di autenticazione, rotazione delle chiavi e definizione di piattaforme approvate.

Pacchetti malevoli e sviluppo AI-assisted convergono nello stesso rischio supply chain

I casi npm, NuGet e vibe coding appartengono a contesti diversi, ma convergono nello stesso problema: la supply chain dello sviluppo software è diventata troppo rapida per i controlli tradizionali. Un pacchetto npm malevolo può rubare file e token GitHub con una semplice installazione. Un pacchetto NuGet può impersonare un SDK finanziario e sottrarre certificati PFX in produzione. Una app generata con AI può essere pubblicata su internet da un dipendente non tecnico e collegarsi direttamente a dati aziendali sensibili. In tutti e tre i casi, l’attaccante o l’errore operativo sfruttano la fiducia nei flussi di sviluppo: fiducia nei repository pubblici, fiducia negli artifact compilati, fiducia nelle piattaforme AI, fiducia nella rapidità del low-code. Le aziende si trovano così a proteggere non solo codice scritto da sviluppatori professionisti, ma anche dipendenze esterne, pacchetti binari, app generate automaticamente, credenziali cloud e integrazioni create fuori dal perimetro IT. La separazione tra codice sorgente e artifact distribuito diventa critica, perché il repository può apparire pulito mentre il pacchetto installato contiene logica malevola. Le pipeline CI/CD diventano un vettore privilegiato perché possiedono privilegi elevati, accesso a segreti e capacità di distribuire codice in produzione. Gli sviluppatori devono quindi trattare ogni dipendenza come potenziale superficie di attacco, soprattutto quando riguarda funzioni sensibili, sistemi finanziari, accesso a repository, segreti o dati personali.

Le mitigazioni immediate richiedono revoca, inventario e controllo degli artifact

La risposta immediata deve partire dalla rimozione dei pacchetti malevoli e dalla rotazione dei segreti potenzialmente compromessi. Per mouse5212-super-formatter, gli sviluppatori devono verificare installazioni locali, container, ambienti di build e pipeline, controllare la directory /mnt/user-data per eventuali file sensibili esposti e revocare subito token GitHub o credenziali che potrebbero essere stati presenti nei percorsi accessibili. Per Sicoob.Sdk, occorre cercare ogni riferimento alle versioni compromesse nei codebase, rimuovere il pacchetto, revocare certificati PFX, ruotare password, client ID e segreti applicativi, monitorare log bancari per attività anomale e verificare connessioni verso l’endpoint Sentry usato per l’esfiltrazione. Sul fronte delle app vibe-coded, la priorità è costruire un inventario reale degli strumenti creati dai dipendenti, mappando ogni applicazione per proprietario, piattaforma, URL pubblico, sistemi connessi, categorie di dati trattati, metodo di autenticazione e chiavi utilizzate. Le aziende devono definire piattaforme approvate, standard minimi di autenticazione, policy per OAuth e API key, revisione obbligatoria delle app collegate a dati produttivi e controlli continui sulle sessioni browser. A livello di supply chain, diventa indispensabile verificare la corrispondenza tra sorgente e artifact, applicare scanning continuo delle dipendenze, usare pinning delle versioni, bloccare pacchetti appena pubblicati da account sospetti e imporre revisione manuale per librerie che accedono a file system, rete, repository, segreti o certificati. Le misure tecniche non bastano senza governance: lo sviluppo assistito dall’AI deve essere trattato come produzione software a tutti gli effetti.

La nuova frontiera è governare la velocità dello sviluppo automatizzato

Il futuro della sicurezza nella supply chain e nello sviluppo AI-assisted dipenderà dalla capacità delle organizzazioni di governare la velocità senza soffocare l’innovazione. Gli attaccanti useranno sempre più strumenti AI per creare pacchetti convincenti, documentazione credibile, namespace ingannevoli e artifact malevoli difficili da distinguere da componenti legittimi. Le piattaforme di vibe coding continueranno a crescere perché rispondono a un bisogno reale delle aziende: creare strumenti interni velocemente, senza attendere cicli di sviluppo tradizionali. Proprio questa utilità le rende pericolose se non vengono inserite in una governance chiara. I repository npm e NuGet dovranno rafforzare controlli su identità degli account, discrepanze source-artifact, uso di token hardcoded, chiamate di rete sospette e impersonificazione di brand o SDK finanziari. Le imprese dovranno invece costruire un nuovo livello di sicurezza dedicato alle app generate in browser, capace di censire, classificare e controllare ciò che oggi nasce fuori dai radar dell’IT. La combinazione tra malware nei pacchetti e applicazioni AI pubblicate senza protezione definisce una fase più dura della sicurezza software: il problema non è più solo impedire che codice malevolo entri in produzione, ma capire dove nasce il software, chi lo genera, quali dati usa, quali dipendenze importa e quali segreti può esporre. Solo un approccio integrato tra policy, scanning, inventario, controllo degli artifact e cultura di sicurezza potrà ridurre il rischio di una supply chain ormai contaminata dalla velocità dell’automazione.