Cl0p torna a colpire dove sa fare più male: non un endpoint qualsiasi, ma il software che tiene insieme la catena di progettazione e produzione di centinaia di aziende manifatturiere, automotive, aerospaziali e di abbigliamento. La gang, la stessa che ha reso celebri gli attacchi di massa contro MOVEit, GoAnywhere MFT e Accellion FTA, sta ora sfruttando una falla critica in PTC Windchill e FlexPLM per ottenere accesso non autenticato, installare webshell e avviare campagne di estorsione su scala industriale.

Un bersaglio scelto con cura: il PLM come infrastruttura critica invisibileWindchill è la piattaforma di Product Lifecycle Management (PLM) di PTC usata da produttori e ingegneri per gestire distinte base, disegni CAD, cicli di revisione e conformità normativa. FlexPLM è la sua controparte pensata per retail, abbigliamento, calzature e beni di consumo. Sono, in sostanza, il “sistema nervoso” della progettazione di prodotto: chi compromette Windchill non ruba solo dati, ottiene la proprietà intellettuale che tiene in piedi intere linee produttive, spesso condivise con fornitori e terze parti a valle della catena. È esattamente il tipo di software “orizzontale ma invisibile” che Cl0p ha sempre preferito, sul modello già visto con MOVEit nel 2023: individuare una falla in un prodotto enterprise diffuso, sfruttarla in massa prima che le patch si diffondano, poi monetizzare i dati sottratti con estorsioni multiple.

La falla: CVE-2026-12569, CVSS 9.3La vulnerabilità alla base della campagna è un caso di improper input validation legato alla deserializzazione di dati non attendibili in Windchill, che consente a un attaccante remoto e non autenticato di eseguire codice arbitrario con una singola richiesta malformata. Secondo l’advisory diffusa da ricercatori di threat intelligence (ecrime.ch) e ripresa dagli analisti, l’affiliato Cl0p osservato in queste settimane concatena due debolezze distinte: una falla di information disclosure nel WSDL di FlexPLM, che permette di mappare gli endpoint e raccogliere informazioni utili sull’istanza target, e una vulnerabilità nel servlet di login di Windchill, che consente di bypassare l’autenticazione e ottenere RCE. Il risultato è una catena di exploit pienamente “unauthenticated to RCE”, il tipo di primitiva che i gruppi ransomware più organizzati amano weaponizzare in pochi giorni.

PTC ha comunicato la vulnerabilità il 17 giugno 2026, rilasciando le prime patch il giorno successivo dopo aver confermato exploitation attiva in the wild. CISA ha inserito CVE-2026-12569 nel proprio Known Exploited Vulnerabilities (KEV) catalog il 25 giugno, imponendo alle agenzie federali statunitensi la remediation entro il 28 giugno: è la prima vulnerabilità di un prodotto PTC ad entrare nel KEV. In Germania, il BSI e la polizia federale (BKA) hanno avvisato direttamente le aziende esposte già dalla notte del 17 giugno, un déjà-vu rispetto a un’altra vulnerabilità RCE nelle stesse piattaforme (CVE-2026-4681) divulgata a marzo 2026.

Dalla falla alla webshell: la firma operativa dell’attaccoUna volta ottenuta l’esecuzione di codice, gli operatori osservati droppano webshell JSP persistenti seguendo uno schema di naming riconoscibile: file con nome esadecimale a 16 caratteri collocati sotto il percorso di login di Windchill. Da lì gestiscono comandi da remoto, effettuano attività di file-listing (lasciando spesso una traccia in un file temporaneo) ed esfiltrano dati prima di passare alla fase di estorsione, con email inviate direttamente alle organizzazioni colpite nei settori Manufacturing, Automotive, Aerospace e Retail/Apparel. Non risultano, al momento, evidenze pubbliche di deployment di ransomware “classico” con cifratura dei file: lo schema resta quello, tipico di Cl0p dal 2023 in poi, di furto massivo di dati seguito da doppia estorsione senza necessariamente criptare gli ambienti compromessi.

Due righe per i difensori: rischio supply chain, non solo perimetraleIl vero elemento di rischio geopolitico e industriale qui non è la singola azienda compromessa, ma l’effetto a cascata: Windchill e FlexPLM sono spesso condivisi con OEM, fornitori Tier 1 e partner di co-design. Un accesso non autorizzato ai repository PLM significa potenziale esposizione di disegni tecnici, specifiche di materiali, cicli di produzione e roadmap di prodotto — informazioni che hanno valore sia per la criminalità organizzata in cerca di leva estorsiva, sia, in scenari più sensibili (difesa, aerospazio), per attori interessati allo spionaggio industriale. È lo stesso pattern di rischio già visto con gli attacchi a piattaforme di file transfer enterprise: la superficie non è l’endpoint dell’utente, ma il software B2B che nessuno vede ma su cui si regge la produzione.

Applicare immediatamente le patch PTC per Windchill e FlexPLM (rilasciate dal 18 giugno 2026) su tutte le versioni supportate.

Verificare la presenza di webshell nel percorso /Windchill/login/ con nomi esadecimali a 16 caratteri.

Analizzare i log HTTP per richieste POST anomale verso gli endpoint di login e per l’header X-windchill-req.

Bloccare al perimetro gli indirizzi IP noti come infrastruttura di comando e controllo.

Limitare l’esposizione diretta a Internet dell’endpoint di login Windchill dove operativamente possibile, instradando l’accesso tramite VPN o gateway con MFA.

Effettuare un controllo retrospettivo dei log di accesso per individuare eventuali esfiltrazioni avvenute prima della patch.

Indicatori di compromissione# Indirizzi IP associati all'infrastruttura d'attacco
172.111.38.31
216.152.148.54
104.243.35.131
74.50.76.146
5.180.41.35 # C2 - bloccare immediatamente al perimetro

Pattern webshell

/Windchill/login/[0-9a-f]{16}.jsp

Hash file webshell (SHA-256)

55a1eb4c2d3da04376df39d7ba832569c6af1a37a0cf2b95f754ac898023a30c

Marcatore di attivita di file-listing dell'attaccante

/tmp/flst.txt (o nella working directory di Windchill)

Header HTTP sospetto usato dagli operatori

X-windchill-req: *
Per i team di sicurezza che gestiscono ambienti PLM esposti, il messaggio è chiaro: la finestra tra disclosure pubblica e weaponization da parte di gruppi come Cl0p si è ormai ridotta a giorni, non settimane. Chi non ha ancora patchato Windchill o FlexPLM dovrebbe considerare l’ambiente potenzialmente già compromesso e agire di conseguenza, con hunting retroattivo prima ancora del solo deployment della patch.

Diciannovemila file, 14,3 gigabyte di planimetrie, elenchi fornitori, verbali di ispezione e persino polizze assicurative contro il terrorismo. È quanto la gang di data extortion World Leaks ha pubblicato sul proprio leak site relativamente alla Kudankulam Nuclear Power Plant, la più grande centrale nucleare indiana, dopo che l’appaltatore Reliance Infrastructure ha rifiutato di pagare il riscatto. Non si tratta dei sistemi di controllo del reattore — quelli restano di competenza russa, forniti da Rosatom — ma la mole di documentazione tecnica esposta è comunque sufficiente per preoccupare gli esperti di sicurezza nucleare.

Un incidente nato a maggio, esploso a luglioLa vicenda comincia il 29 maggio 2026, quando Yotta, il data center indiano che ospita i server di Reliance Infrastructure, rileva un’attività sospetta su un’istanza riconducibile al gruppo Reliance. Yotta dichiara di aver bloccato l’esecuzione di un probabile ransomware in tempo reale. A fine giugno, però, Reliance Infrastructure comunica a Yotta di aver ricevuto rivendicazioni di data breach da parte di “attori esterni”: il tempo tra il contenimento tecnico e la scoperta dell’esfiltrazione reale è il primo campanello d’allarme di questa storia, e non è un caso isolato nel panorama delle intrusioni contro appaltatori di infrastrutture critiche.

Il 15 luglio i file compaiono sul portale World Leaks, accessibile solo tramite browser specializzati per l’accesso al dark web. Secondo il ricercatore indipendente Rakesh Krishnan, che per primo ha segnalato la fuga di dati a Reuters, i documenti riferiti alla sigla “KKNP” (Kudankulam Nuclear Power) risultavano online già dall’11 giugno — quasi un mese prima che la notizia diventasse pubblica. Reliance ha confermato una “violazione parziale” dei propri dati, senza specificarne l’estensione.

Chi è World LeaksWorld Leaks non è un nome nuovo per chi segue il cybercrime organizzato. Il gruppo è la reincarnazione operativa di Hunters International, storica gang ransomware che nel 2025 ha scelto di abbandonare quasi del tutto la cifratura dei file per concentrarsi sulla pura estorsione dei dati: niente più payload di encryption da sviluppare e far evolvere contro gli antivirus, solo intrusione silenziosa, permanenza prolungata nella rete della vittima, esfiltrazione massiva e pressione pubblica sul leak site. Un modello di business più snello, più difficile da rilevare con gli strumenti EDR tradizionali (che sono tarati soprattutto sul comportamento anomalo della cifratura) e altrettanto redditizio.

Dal gennaio 2025 il gruppo rivendica oltre 150 vittime, tra cui Nike (1,4 TB di dati, 188.347 file, gennaio 2026), Dell, UBS e — soprattutto — un trio di società del conglomerato indiano Tata: Tata Technologies (1,4 TB, ereditata direttamente da Hunters International nel marzo 2025), Tata Electronics (630,4 GB, 204.341 file, giugno 2026, con dati sensibili di Apple e Tesla legati alla produzione di iPhone) e ora, con Reliance, un secondo grande gruppo industriale indiano colpito nello spazio di poche settimane. Nel caso Tata, World Leaks aveva dichiarato a Reuters di aver chiesto un riscatto di 1,5 milioni di dollari, pubblicando i dati dopo che l’azienda aveva “ignorato” la richiesta. Lo stesso copione — silenzio della vittima, contatore che scade, pubblicazione integrale — si è ripetuto con Reliance.

Cosa contengono davvero i fileReuters, che ha potuto visionare parte del materiale senza tuttavia certificarne l’autenticità al 100%, descrive documenti datati tra il 2016 e la metà del 2025: planimetrie dei sistemi di ventilazione e raffreddamento delle Unità 3 e 4 (ancora in costruzione, operative entro il 2027, per una capacità combinata di 2.000 MW), la mappa completa di una control room comune, proposte di fornitori, un elenco di supplier approvati e i verbali di un’ispezione congiunta del 2024 tra Nuclear Power Corporation of India (NPCIL) e Reliance, corredati di fotografie degli impianti. Tra i documenti più delicati compare anche una polizza assicurativa che garantirebbe 112 milioni di dollari a Reliance Infrastructure e NPCIL in caso di atto terroristico contro le Unità 3 o 4 — un dettaglio che, se autentico, offre a un aggressore una stima concreta di quanto l’operatore stesso consideri “critico” quel bersaglio.

Nickolas Roth, senior director della Nuclear Threat Initiative, ha sottolineato a Reuters il vero rischio operativo di questo genere di fughe: non serve accedere ai sistemi del reattore per costruire un profilo utile a un attacco fisico o informatico successivo. Planimetrie, elenchi fornitori e mappe di controllo “mostrano a un avversario non solo chi ha accesso al progetto, ma quali sistemi quell’accesso può raggiungere” — in altre parole, permettono di ricostruire la catena di sicurezza dell’impianto e di individuarne i punti deboli, dai fornitori meno protetti ai varchi fisici meno sorvegliati.

Non è la prima volta per KudankulamKudankulam ha già una storia di incidenti cyber: nel 2019 la rete amministrativa della centrale era stata infettata da un malware attribuito a un gruppo nordcoreano — un episodio che, secondo NPCIL, non aveva toccato i sistemi operativi dell’impianto. Il fatto che la stessa struttura torni due volte in sette anni al centro di un incidente informatico, per quanto di natura diversa, la dice lunga sulla difficoltà di isolare completamente reti industriali critiche dalla catena di fornitura IT che le circonda: la violazione non è avvenuta contro NPCIL direttamente, ma contro un fornitore terzo (Reliance) ospitato su infrastruttura di un altro fornitore terzo (Yotta) — un classico esempio di rischio di supply chain in ambito OT/critical infrastructure.

Contesto: l’India nel mirinoIl caso Reliance si inserisce in un trend più ampio. Secondo dati Surfshark, l’India è il terzo Paese al mondo per numero di account compromessi nel 2025 (28,9 milioni), dietro solo a Stati Uniti e Francia. Un report del Data Security Council of India realizzato con Seqrite ha rilevato che il 73% delle 204 organizzazioni intervistate “non sa se sia mai stata attaccata” e il 57% non applica pratiche basilari di igiene informatica. In un Paese che sta rapidamente espandendo il proprio parco nucleare — Kudankulam è centrale nel piano del governo Modi — il divario tra ambizione infrastrutturale e maturità della sicurezza informatica degli appaltatori resta il vero punto debole.

Due righe per i difensoriPer i team di sicurezza che gestiscono ambienti industriali o infrastrutture critiche, il caso Reliance/World Leaks offre alcune lezioni pratiche:

Il rilevamento di un tentativo di cifratura bloccato non implica che l’esfiltrazione dei dati sia stata impedita: va sempre assunta l’ipotesi di data theft anche quando il ransomware “classico” viene neutralizzato in tempo.

La sicurezza dei fornitori terzi (in questo caso un data center che ospita un appaltatore di un operatore nucleare) va trattata come estensione diretta del perimetro critico, con audit periodici e segmentazione delle reti che ospitano documentazione sensibile.

Documentazione apparentemente “amministrativa” — planimetrie, elenchi fornitori, verbali di ispezione, polizze assicurative — va classificata e protetta con lo stesso rigore dei dati operativi, perché costituisce ricognizione pronta all’uso per un aggressore.

Il ritardo tra compromissione (29 maggio), notifica interna (fine giugno) e pubblicazione pubblica (15 luglio, con dati online già dall’11 giugno) mostra quanto sia critico ridurre il tempo di rilevamento delle fughe di dati, anche tramite monitoraggio proattivo dei leak site e dei marketplace del dark web.

Dati chiave dell’incidenteVittima: Reliance Infrastructure (contractor NPCIL/Kudankulam NPP)
Hosting compromesso: Yotta Data Services (data center terze parti)
Gruppo responsabile: World Leaks (rebrand di Hunters International)
Modello operativo: data extortion senza cifratura (double extortion "leak-only")
Volume totale dati Reliance: ~858.000 file
File più sensibili pubblicati: ~19.000 file / 14,3 GB
Data compromissione rilevata: 29 maggio 2026
Data comparsa dati su leak site: online dall'11 giugno, pubblicazione ufficiale 15 luglio 2026
Precedenti vittime note del gruppo: Nike, Dell, UBS, Tata Technologies, Tata Electronics, Mediaworks
Riscatto richiesto (caso Tata, riferimento): 1,5 milioni di USD
Accesso al leak site: solo tramite browser dark web dedicatoNPCIL, CERT-In e l’ufficio stampa del governo indiano non hanno risposto alle richieste di commento di Reuters. L’indagine è in corso, e resta da chiarire l’estensione reale della compromissione oltre i file già pubblicati.

Si parla di:

Toggle

Per la prima volta un fornitore di infrastruttura AI ammette pubblicamente di essere stato violato da un attacco condotto end-to-end da un agente AI autonomo, senza un operatore umano al comando durante l’intrusione vera e propria. Hugging Face, il più grande repository al mondo di modelli e dataset open source, ha reso noto il 16 luglio di aver rilevato e contenuto un’intrusione nella propria infrastruttura di produzione partita da un dataset malevolo e proseguita per un intero weekend attraverso migliaia di azioni automatizzate. L’ironia non è sfuggita a nessuno: la piattaforma che ospita gran parte dell’ecosistema AI open source è stata compromessa da un attacco reso possibile proprio dall’AI agentica.

Il vettore: la pipeline di elaborazione datasetIl punto di ingresso non è stato un endpoint applicativo generico, ma il cuore stesso del business di Hugging Face: la pipeline che processa i dataset caricati dagli utenti. Un dataset predisposto ad hoc ha sfruttato due distinti code-execution path nel sistema di elaborazione: un remote-code dataset loader (una funzionalità che consente l’esecuzione di codice personalizzato durante il caricamento di certi formati di dataset) e una vulnerabilità di template injection nella configurazione del dataset stesso. La combinazione ha permesso l’esecuzione di codice arbitrario su un processing worker — il classico “primo piede nella porta” che qualunque red teamer riconoscerebbe, solo che qui a orchestrare i passi successivi non c’era una persona.

Da quel singolo worker compromesso, l’attaccante ha scalato privilegi fino ad accesso a livello di nodo, raccolto credenziali cloud e di cluster, e si è mosso lateralmente in diversi cluster interni nell’arco di un intero fine settimana — la finestra temporale preferita da chi attacca infrastrutture aziendali, quando il personale di sicurezza è ridotto e la reattività cala. Hugging Face ha successivamente confermato l’accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio, ma nessuna evidenza di manomissione di modelli, dataset o Spaces pubblici, e la supply chain software (immagini container, pacchetti pubblicati) è risultata pulita.

Uno sciame di sandbox, non uno scriptCiò che distingue questo incidente da un normale attacco automatizzato è la scala e l’autonomia dell’orchestrazione. Secondo Hugging Face, la campagna è stata condotta da un framework di agenti autonomi — verosimilmente costruito su un harness da security research agentico, anche se il modello linguistico usato dall’attaccante resta sconosciuto — capace di eseguire migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con un’infrastruttura di comando e controllo self-migrating ospitata su servizi pubblici legittimi (una tecnica di “living off trusted services” che rende il traffico C2 difficile da distinguere da normale attività cloud). È esattamente lo scenario dell'”agentic attacker” che l’industria della sicurezza discute da mesi come previsione teorica, qui osservato per la prima volta in produzione contro un target reale.

La caccia forense: quando i guardrail bloccano i difensoriLa parte più istruttiva della disclosure riguarda la risposta all’incidente. Il rilevamento iniziale è arrivato da una pipeline di anomaly-detection che usa LLM per il triage della telemetria di sicurezza: è stata la correlazione automatica dei segnali a far scattare l’allarme. Per ricostruire cosa avesse fatto realmente lo sciame di azioni automatizzate, il team ha fatto girare agenti di analisi LLM sull’intero log delle azioni dell’attaccante — oltre 17.000 eventi registrati — per ricostruire la timeline, estrarre indicatori di compromissione, mappare le credenziali toccate e separare l’impatto reale dalle attività diversive. Un lavoro che con metodi tradizionali avrebbe richiesto giorni, completato in poche ore.

Ma è qui che Hugging Face ha incontrato un ostacolo inatteso, e potenzialmente rilevante per ogni team di incident response che lavora con modelli commerciali “hosted”: i primi tentativi di analisi con modelli frontier dietro API commerciali sono falliti, perché le richieste — che necessariamente contenevano comandi di attacco reali, exploit payload e artefatti C2 — venivano bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder legittimo da un attaccante. La soluzione è stata spostare l’analisi forense su GLM 5.2, modello open-weight del laboratorio cinese Z.ai, eseguito sull’infrastruttura interna dell’azienda: un doppio vantaggio, perché ha sbloccato l’analisi e ha evitato che dati dell’attaccante e credenziali compromesse uscissero dal perimetro aziendale.

L’asimmetria che nessuno aveva pianificatoHugging Face descrive questo come “un gap su cui vale la pena pianificare”: non si sa quale modello alimentasse gli agenti dell’attaccante — un modello hosted jailbreakato o uno open-weight senza restrizioni — ma in ogni caso l’attaccante non era vincolato da alcuna policy d’uso, mentre il lavoro forense legittimo dei difensori è stato bloccato proprio dai guardrail dei modelli hosted inizialmente scelti. La lezione pratica che l’azienda condivide con il settore: avere già pronto e validato, prima che scoppi un incidente, un modello capace eseguibile sulla propria infrastruttura, sia per evitare il lockout dei guardrail sia per mantenere dati e credenziali sensibili entro il proprio perimetro. Non è, precisano, un argomento contro le misure di sicurezza sui modelli hosted — è un feedback che l’azienda dice di aver già condiviso con i provider coinvolti.

Timeline dell’incidenteSettimana del 6 luglio 2026: rilevamento dell’intrusione nella pipeline di elaborazione dataset tramite anomaly-detection basata su LLM.

Weekend successivo al primo accesso: escalation di privilegi, raccolta di credenziali cloud/cluster, movimento laterale su più cluster interni condotto dallo sciame di agenti autonomi.

16 luglio 2026: pubblicazione della disclosure ufficiale sul blog Hugging Face, con dettaglio tecnico del vettore e delle contromisure adottate.

Contestualmente: chiusura dei code-execution path usati come accesso iniziale, rotazione precauzionale di credenziali e token, rafforzamento degli admission control sui cluster, coinvolgimento di specialisti forensi esterni e notifica alle forze dell’ordine.

Due righe per i difensoriQuesto incidente non è solo una curiosità tecnica: ridefinisce cosa significa “superficie di attacco” per qualunque piattaforma che elabora contenuti generati da utenti tramite pipeline automatizzate, AI o non AI.

Trattare ogni pipeline di data processing che esegue codice fornito dall’utente (loader personalizzati, plugin, configurazioni con logica di templating) come superficie di attacco di prima classe, non come funzionalità di prodotto neutra.

Validare in anticipo — prima di un incidente — un modello LLM eseguibile on-premise o in ambiente isolato per l’analisi forense, così da non dipendere da provider commerciali i cui guardrail possono bloccare legittime attività di incident response.

Assumere che attacchi “a sciame” con orchestrazione agentica possano operare a velocità e scala superiori a quelle di un operatore umano, e dimensionare di conseguenza i tempi di detection e risposta: Hugging Face cita l’obiettivo di allertare un responder “in pochi minuti, in qualsiasi giorno della settimana”.

Segmentare rigorosamente i processing worker dal resto del cluster e limitare il raggio d’azione di credenziali cloud raccolte da un singolo nodo compromesso, per contenere il movimento laterale anche quando l’accesso iniziale non può essere prevenuto al 100%.

Indicatori e dettagli tecnici notiTarget: infrastruttura di produzione Hugging Face (dataset processing pipeline)
Vettore iniziale: dataset malevolo caricato dall'utente
Tecniche di code execution: remote-code dataset loader + template injection in dataset config
Escalation: da worker compromesso a node-level access
Post-exploitation: raccolta credenziali cloud/cluster, movimento laterale multi-cluster
Durata campagna attiva: un intero weekend
Orchestrazione: framework di agenti autonomi, presumibile harness di security-research agentico
Infrastruttura C2: self-migrating, ospitata su servizi pubblici legittimi
Eventi registrati nel log dell'attaccante: 17.000+
Impatto confermato: accesso non autorizzato a dataset interni limitati e a credenziali di servizio
Impatto escluso: nessuna manomissione di modelli/dataset/Spaces pubblici; supply chain software verificata pulita
Strumento di analisi forense: GLM 5.2 (Z.ai, open-weight), eseguito su infrastruttura interna
Contatto per segnalazioni: security@huggingface.coHugging Face raccomanda a chi utilizza la piattaforma di ruotare i propri access token e rivedere l’attività recente sui rispettivi account. L’azienda ha inoltre chiarito di stare ancora completando la valutazione di eventuali impatti su dati di partner o clienti, con notifiche dirette previste per le parti coinvolte.

Non 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ù critiche

Mappare le dipendenze condivise (Active Directory, VPN, orchestrazione cloud) tra rete IT e rete OT

Predisporre in anticipo contatti con FBI/law enforcement locale e retainer di incident response per ridurre i tempi di reazione

Cosa 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