Si parla di:ToggleNon serve colpire una centrale elettrica per mettere in ginocchio una filiera critica: basta un ransomware ben piazzato nei sistemi produttivi di un’azienda che imbottiglia latte. Il 16 luglio 2026 Coca-Cola ha comunicato alla SEC che la sua controllata Fairlife ha sospeso la produzione negli Stati Uniti dopo un attacco ransomware che ha colpito i sistemi legati alla produzione stessa. Un episodio che, al netto delle dimensioni del marchio coinvolto, racconta molto sullo stato di sicurezza dell’OT nel settore alimentare.Cosa è successoFairlife, con sede a Chicago, è il marchio di latte ultrafiltrato di proprietà di Coca-Cola, noto anche per le linee Core Power Protein Shakes e Nutrition Plan. Nel filing 8-K depositato presso la Securities and Exchange Commission, Coca-Cola ha dichiarato che soggetti non autorizzati hanno avuto accesso a una parte dei sistemi di Fairlife, inclusi quelli legati alla produzione, in un attacco che l’azienda descrive esplicitamente come ransomware. Le operazioni negli stabilimenti statunitensi sono state temporaneamente sospese; la produzione in Canada, gestita separatamente, non risulta invece impattata.Coca-Cola ha attivato i protocolli di incident response e business continuity, coinvolto consulenti esterni e notificato le forze dell’ordine, precisando che qualità e sicurezza del prodotto non sono state compromesse. Al momento della scrittura, la società non ha reso noto quale gruppo ransomware sia responsabile, se siano stati sottratti dati né se sia stata ricevuta una richiesta di riscatto. Nessuna gang ransomware nota ha ancora rivendicato l’attacco, un silenzio che nel settore viene letto come tipico delle prime fasi di un negoziato, prima che gli estorsori tornino a farsi vivi minacciando la pubblicazione di eventuali dati sottratti.Non è un caso isolato: la filiera alimentare nel mirinoL’attacco a Fairlife arriva in un contesto in cui il comparto food & beverage è bersaglio ricorrente del ransomware, spesso proprio perché la convergenza IT/OT nelle linee di produzione rende gli impianti fragili: basta bloccare i sistemi SCADA o MES che orchestrano il confezionamento per fermare intere linee, anche senza toccare la sicurezza alimentare in senso stretto. Il precedente più noto resta l’attacco del 2021 a JBS, il colosso mondiale della carne, costretto a fermare impianti in Nord America e Australia e a pagare 11 milioni di dollari di riscatto al gruppo REvil. Nella sola finestra delle ultime 48 ore, la stessa dinamica si è ripetuta altrove: in Giappone, un attacco informatico a un operatore logistico ha svuotato le cucine di migliaia di ristoranti per un blocco nelle consegne di prodotti alimentari, mentre il colosso giapponese dei surgelati Nichirei ha segnalato la disruzione delle proprie operazioni per un incidente informatico separato.Il filo comune è la dipendenza di filiere alimentari globalizzate da sistemi IT centralizzati per pianificazione della produzione, gestione ordini e logistica: quando quei sistemi vengono cifrati o resi inaccessibili, l’impatto si propaga rapidamente dagli scaffali dei supermercati alle cucine dei ristoranti, ben oltre il perimetro aziendale colpito.Perché conta anche per chi non produce latteIl caso Fairlife è interessante per i difensori non tanto per i dettagli tecnici, che Coca-Cola non ha ancora reso pubblici, quanto per la dinamica di disclosure e per l’esposizione di un brand multimiliardario a un rischio operativo concreto tramite una controllata. Il filing SEC evidenzia un punto spesso sottovalutato nei risk assessment: la segmentazione tra rete IT aziendale e rete OT di produzione, quando esiste, va verificata regolarmente, perché un attacco che compromette “solo” i sistemi IT può comunque paralizzare la produzione se i due domini condividono directory service, credenziali o piattaforme di orchestrazione.Per le aziende manifatturiere, specialmente nel food & beverage dove i margini di tolleranza su tempi di fermo sono minimi per ragioni di deperibilità delle materie prime, le priorità restano quelle già emerse dai casi JBS e Nichirei: backup offline testati e realmente isolati (non solo replicati su un secondo datacenter raggiungibile dalla stessa rete), piani di failover manuale per le linee di produzione critiche, segmentazione rigorosa tra reti corporate e reti OT/ICS, e accordi di incident response pre-negoziati con forze dell’ordine e consulenti forensi, in modo da non partire da zero quando il tempo conta più di ogni altra cosa.Verificare che i backup dei sistemi MES/SCADA siano realmente air-gapped e non solo “logicamente separati”Testare periodicamente scenari di failover manuale per le linee di produzione più criticheMappare le dipendenze condivise (Active Directory, VPN, orchestrazione cloud) tra rete IT e rete OTPredisporre in anticipo contatti con FBI/law enforcement locale e retainer di incident response per ridurre i tempi di reazioneCosa manca ancora al quadroAl momento della pubblicazione, mancano ancora elementi chiave per una piena attribuzione: nome della gang ransomware, vettore di accesso iniziale, eventuale esfiltrazione di dati e ammontare della richiesta di riscatto. Continueremo a seguire l’evoluzione del caso Fairlife, aggiornando l’articolo qualora emergano rivendicazioni o dettagli tecnici da fonti di threat intelligence.Stato indicatori al 18/07/2026: - Gruppo ransomware responsabile: non identificato pubblicamente - Vettore di accesso iniziale: non divulgato - Esfiltrazione dati: non confermata - Richiesta di riscatto: non divulgata - Sistemi impattati: infrastrutture di produzione Fairlife (solo USA) - Sistemi non impattati: produzione Fairlife Canada, qualita/sicurezza prodotto Riferimento normativo: SEC Form 8-K depositato da The Coca-Cola Company il 16/07/2026

Si parla di:ToggleBastava un “npm install” per essere compromessi. L’11 luglio 2026 la versione 8.14.0 del pacchetto jscrambler, tool di offuscamento JavaScript usato in migliaia di pipeline di build e ambienti CI/CD, è stata pubblicata su npm con un hook di preinstallazione malevolo capace di eseguire silenziosamente un infostealer nativo scritto in Rust, con build dedicate per Windows, macOS e Linux. Non serviva importare il pacchetto né lanciare un comando: la sola installazione bastava a far partire il payload.Il caso, documentato da Socket, StepSecurity e SafeDep, si inserisce in una scia di attacchi alla supply chain npm che va avanti da fine 2025 — dal worm Shai-Hulud alla compromissione di chalk e debug, fino al trojan iniettato in Axios a marzo. Ma questa volta il bersaglio non è la massa di utenti finali: è l’ambiente di build stesso, dove risiedono le chiavi cloud, i token di deploy e il codice sorgente che un’infrastruttura CI può raggiungere.Sei minuti per essere scoperti, troppo tardi per moltiSocket ha segnalato la release appena sei minuti dopo la pubblicazione. Chiunque, o qualsiasi sistema di build, avesse scaricato il pacchetto in quella finestra ha già eseguito il payload con tutti i permessi del processo di installazione. L’hook malevolo si attiva prima ancora che il pacchetto venga configurato, e non compare nella release precedente, la 8.13.0: il diff del pacchetto mostra due nuovi file sotto dist/, setup.js — un piccolo loader — e intro.js, che nonostante il nome non è affatto JavaScript ma un container di circa 7,8 MB che impacchetta tre binari nativi compressi in gzip, uno per Linux, uno per Windows e uno per macOS.All’installazione, setup.js seleziona il binario per il sistema operativo host, lo scrive con un nome casuale nella directory temporanea di sistema, lo rende eseguibile e lo lancia in modalità detached nascondendone l’output. I file aggiunti erano presenti nel pacchetto pubblicato ma assenti nel codice sorgente pubblico: sia StepSecurity sia SafeDep, che hanno analizzato indipendentemente la release, riportano l’assenza di qualsiasi commit, tag o pull request corrispondente alla versione 8.14.0 nel repository GitHub, il cui ultimo tag ufficiale resta 8.13.0.La versione compromessa è stata pubblicata direttamente su npm da un account maintainer legittimo, bypassando il normale flusso di rilascio del progetto — un forte indicatore di account npm compromesso o pipeline di build violata. Quale delle due ipotesi sia corretta non è ancora stato stabilito.Cosa fa davvero l’infostealerL’analisi di follow-up di Socket identifica il payload come un infostealer Rust, compilato per tutte e tre le piattaforme, che scandaglia la macchina dello sviluppatore alla ricerca di segreti e li invia a un server di raccolta via TLS. La lista dei bersagli è ampia e mirata esplicitamente agli sviluppatori:Credenziali cloud da AWS, Azure e Google Cloud, inclusi gli endpoint di metadata usati dai runner CI.Wallet di criptovalute e seed phrase da MetaMask, Phantom ed Exodus, oltre al vault del password manager Bitwarden.Password e cookie salvati nel browser, insieme alle sessioni di Discord, Slack, Telegram e Steam.File di configurazione di strumenti di coding AI — Claude Desktop, Cursor, Windsurf, VS Code e Zed — dove risiedono tipicamente chiavi API e credenziali dei server Model Context Protocol (MCP).Il payload va oltre il furto ordinario di credenziali: su Linux, si collega alla libreria BPF del kernel ed è in grado di caricare in memoria un programma eBPF, un punto d’appoggio a livello kernel piuttosto che il semplice accesso userspace ai file su cui si basa il resto dello stealer. Sia StepSecurity sia SafeDep hanno segnalato questa capacità, anche se la funzione esatta del programma eBPF è ancora in fase di analisi. Le build Windows e macOS aggiungono controlli anti-debug, mentre la persistenza è garantita da un task pianificato nascosto su Windows, impostato per rilanciarsi ogni minuto, e da un LaunchAgent su macOS che si ricarica a ogni login.I dettagli di comando e controllo restano cifrati nel binario e non sono emersi dall’analisi statica; il monitoraggio runtime di StepSecurity ha però intercettato il binario mentre contattava due indirizzi IP hardcoded e infrastruttura Tor — i primi indicatori di rete pubblicati per questa campagna.Timeline e portata dell’incidenteNell’arco di circa tre ore, l’attaccante ha pubblicato cinque release malevole — 8.14.0, 8.16.0, 8.17.0, 8.18.0 e 8.20.0 — intervallate da release pulite che i maintainer sembrano aver spinto come tentativo di rimedio. Il pacchetto jscrambler conta circa 15.800 download settimanali: una base d’utenza ben più contenuta rispetto ai grandi incidenti npm dell’ultimo anno, che hanno coinvolto pacchetti con miliardi di download settimanali complessivi. Ma per uno stealer pensato per colpire macchine di build, la portata non era l’obiettivo: lo era l’accesso.Un dettaglio temporale rende il caso ancora più significativo: npm 12, rilasciato l’8 luglio 2026, appena tre giorni prima di questo incidente, ha disattivato di default l’esecuzione automatica degli script di installazione delle dipendenze. Su npm 12, un preinstall hook come questo non gira a meno che qualcuno non lo approvi esplicitamente. I client più datati, però, continuano a eseguirli automaticamente — ed è esattamente lì che l’attacco ha colpito.La versione 8.15.0 ha da allora sostituito la 8.14.0 in cima all’elenco versioni di npm, pubblicata dallo stesso account maintainer e priva di qualsiasi alert di malware: nessuno script di installazione, nessun binario incluso. Ma la versione 8.14.0 non è stata rimossa da npm: resta scaricabile, quindi qualsiasi lockfile o comando ancorato a quella versione continua a installare lo stealer. Solo il pacchetto CLI principale è stato colpito; i plugin jscrambler per webpack, gulp, Metro e grunt sono rimasti sulle release pulite di giugno, senza hook di installazione.Cosa fare adessoAbbandonare immediatamente la versione 8.14.0: passare alla 8.15.0, oppure fissare la 8.13.0 (release precedente all’incidente), ed eliminare jscrambler@8.14.0 da lockfile e cache.Verificare se la versione compromessa è stata installata: controllare lockfile e log dei package manager per jscrambler@8.14.0, e i log CI per qualsiasi esecuzione di dist/setup.js dall’11 luglio in poi. Il loader scrive il payload con un nome casuale nella directory temporanea, quindi non esiste un nome di binario fisso da cercare: bisogna incrociare i timestamp di installazione con i processi figli di Node e l’esecuzione nella directory temp. Su Windows controllare Task Scheduler per task nascosti; su macOS ispezionare ~/Library/LaunchAgents per plist sconosciuti.Se la 8.14.0 è stata eseguita su una macchina, trattare ogni segreto raggiungibile come rubato, non solo come esposto: ruotare chiavi cloud, token npm e GitHub, chiavi API di strumenti AI e MCP; revocare sessioni Discord, Slack, browser e Bitwarden; spostare eventuali fondi in criptovaluta da wallet presenti su quell’host. Bloccare i due IP di comando e controllo elencati di seguito.La pulizia da parte del maintainer è stata rapida, ma uno stealer compie il proprio lavoro nei secondi immediatamente successivi all’installazione. La 8.14.0 resta su npm, e una build ancorata a quella versione, su un client datato che esegue ancora gli script di installazione, continua a eseguire il payload. Nel momento in cui la 8.15.0 ha raggiunto la cima della lista versioni, i segreti su ogni macchina che aveva già eseguito la 8.14.0 erano già compromessi.Indicatori di compromissionePacchetto malevolo: jscrambler@8.14.0 SHA-256 dei file aggiunti e dei payload decompressi: dist/setup.js: a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60 dist/intro.js: a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86 Payload Linux: fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd Payload Windows: b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903 Payload macOS: c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd Endpoint di rete osservati a runtime (StepSecurity): C2 IP: 37.27.122[.]124 C2 IP: 57.128.246[.]79 Infrastruttura Tor: check.torproject[.]org, archive.torproject[.]org Artefatti on-host: File nascosto con nome casuale nella directory temp di sistema (.{random}, o .{random}.exe su Windows) Task pianificato nascosto su Windows / LaunchAgent su macOS per la persistenzaFonti: Socket.dev, StepSecurity, SafeDep.