Sicurezza informaticaOT e impianti

Caso supermercati Intermarché: i problemi sono sempre gli stessi

16 ottobre 2026

Il cyberattacco che nell’ottobre 2026 ha colpito centinaia di supermercati francesi viene facilmente raccontato come una storia di vulnerabilità software: un controller vulnerabile, una password prevedibile, un hacker che entra e porta i frigoriferi a 50 °C. È una lettura comoda. Ed è anche incompleta. Il problema più serio non riguarda un bug: riguarda l’architettura con cui per anni è stata organizzata la gestione remota degli impianti di refrigerazione.

Si parla moltissimo dei rischi dell’intelligenza artificiale: agenti che trovano vulnerabilità da soli, attacchi automatizzati, modelli usati come armi. Qui però non è servito niente di tutto questo. Per portare a 50 °C i frigoriferi di Intermarché e degli altri supermercati è bastato trovare interfacce di gestione lasciate raggiungibili da Internet, controller a fine vita mai sostituiti, accessi remoti pensati per la comodità della manutenzione. Sono tutte scelte umane: di progettazione, di installazione, di gestione. Prima del rischio AI, c’è il rischio umano.

Cosa è successo

Nella notte tra l’11 e il 12 ottobre 2026 gli impianti di refrigerazione di numerosi supermercati francesi sono stati manomessi a distanza. Frigoriferi e congelatori sono stati portati fino a 50 °C, in alcuni casi forzando un ciclo continuo di sbrinamento, con merce da buttare e perfino qualche principio d’incendio. Secondo il ministro dell’Economia Roland Lescure i punti vendita colpiti sono circa 700, su circa 10.000 supermercati nel paese: Intermarché e Netto, Carrefour, Coopérative U, Monoprix, alcuni E.Leclerc. La procura di Parigi ha aperto un’indagine e l’ANSSI è stata incaricata di analizzare l’accaduto. Al momento non c’è un’attribuzione.

Il CERT-FR ha pubblicato un’allerta già il 12 ottobre e l’ha aggiornata il giorno dopo: i sistemi presi di mira sono i controller Danfoss serie AK-SM e AK-SC, Copeland xweb e Dixell xweb. Produttori diversi, famiglie di prodotti diverse.

Il controller del frigorifero è diventato un server Internet

Prendiamo il caso più studiato, il Danfoss AK-SM 800A. Non è un termostato: è un System Manager installato nel punto vendita, il centro di controllo di tutto l’impianto frigorifero. Da una sola console si monitorano i circuiti, si cambiano le soglie di temperatura, si leggono gli allarmi, si modificano i programmi di sbrinamento, si gestiscono gli utenti e si fa manutenzione remota.

Per rendere comoda l’assistenza, il controller incorpora un vero web server: l’interfaccia StoreView Web, raggiungibile da un normale browser all’indirizzo dell’unità.

IMPIANTO FISICO
      │
      ▼
controller OT (AK-SM / AK-SC / xweb)
      │
      ├── temperature
      ├── compressori
      ├── sbrinamento
      ├── allarmi
      └── configurazione
      │
      ▼
WEB SERVER  →  RETE IP  →  ACCESSO REMOTO

Il problema non è che esista un’interfaccia web. Il problema è dove viene collocato il confine di fiducia. Se la stessa interfaccia che governa un sistema cyber-fisico diventa raggiungibile dalla rete pubblica, si è trasformato un apparato industriale in un servizio Internet. E un frigorifero industriale non dovrebbe avere lo stesso threat model di un sito web.

Internet non dovrebbe essere la rete di manutenzione di un impianto OT

Ad agosto 2026 i ricercatori di Team82 di Claroty, studiando l’AK-SM 800A, hanno cercato queste interfacce con i motori di scansione di Internet: con Censys ne hanno trovate 2.765 raggiungibili dalla rete pubblica.

È probabilmente il dato più importante di tutta la vicenda. In una rete ben costruita un aggressore dovrebbe attraversare il firewall aziendale, la rete corporate, la rete del punto vendita e poi il segmento OT prima di arrivare al controller. Con un’interfaccia esposta, invece, il percorso diventa:

Internet
   │
   ▼
interfaccia di amministrazione del controller
   │
   ▼
processo fisico

Tutta la profondità difensiva sparisce. L’attaccante non deve compromettere nulla prima: deve solo trovare il dispositivo e parlare direttamente con la sua applicazione di gestione. È una scelta che cambia radicalmente il blast radius di qualsiasi vulnerabilità, presente e futura.

Le vulnerabilità ci sono, e ce ne saranno altre

Lo stesso studio di Claroty è quasi didattico. Sull’AK-SM 800A Team82 ha documentato tre problemi:

CVE-2025-41450: un meccanismo nascosto di autenticazione basato su un “code of the day” calcolato dalla data del dispositivo, che permetteva di aggirare il login una volta ricostruito l’algoritmo;
CVE-2025-41451: una command injection, dopo l’autenticazione, attraverso un campo di configurazione delle email di allarme, che portava all’esecuzione di comandi sul sistema;
CVE-2025-41452: la possibilità, per un utente autenticato, di iniettare direttive nella configurazione del web server Nginx, fino a renderlo inutilizzabile.

Danfoss ha corretto i problemi e Claroty raccomanda di aggiornare alla release R4.3.1 o successiva. Non è dimostrato che proprio queste CVE siano state usate negli attacchi di ottobre. Ma il punto è un altro.

Una CVE è un evento. L’esposizione del management plane è un’architettura. Se domani esce una nuova vulnerabilità pre-autenticazione, un controller esposto a Internet la trasforma subito in una porta verso il processo fisico. E poi ancora con la successiva.

La patch che non arriverà mai

Qui la vicenda francese aggiunge un elemento decisivo. Secondo quanto riportato da Danfoss, la maggior parte delle unità colpite sono modelli che l’azienda non aggiorna più: l’AK-SM 800 è a fine vita dal 2021, l’AK-SC 355 dal 2016. Copeland, a sua volta, ha parlato di una vulnerabilità in una generazione di controller dismessa e a fine vita.

Per questi apparati non c’è nessuna patch da installare. Non ci sarà mai.

Ed è la situazione normale nell’OT, non l’eccezione. Gli impianti non si cambiano ogni tre anni come uno smartphone: restano in servizio dieci, quindici, vent’anni. Nel frattempo i produttori cambiano linee di prodotto, vengono acquisiti, chiudono il supporto, smettono di rilasciare firmware. A volte la patch esiste ma non può essere installata senza fermare l’impianto o senza riqualificarlo. A volte nessuno sa nemmeno che quel controller è ancora lì, configurato da un installatore anni prima.

Lo dice in modo esplicito anche il CERT-FR: mantenere esposto un apparato a fine vita e senza patch di sicurezza significa sottoporlo a una probabilità molto elevata di compromissione. E per i dispositivi già compromessi persino un reset di fabbrica non basta: elimina l’eventuale persistenza dell’attaccante, ma l’apparato resta vulnerabile e verrà probabilmente compromesso di nuovo.

La conclusione è semplice, e scomoda: non si può affidare la sicurezza di un impianto alla buona volontà di patching di un produttore. Non perché i produttori siano in malafede, ma perché il loro ciclo di vita non coincide con quello dell’impianto.

Filtrare prima, fidarsi dopo

Se il software dell’apparato non può essere considerato affidabile, e prima o poi non lo sarà, la sicurezza deve esistere prima che la richiesta lo raggiunga.

È un cambio di prospettiva. La sicurezza applicativa, cioè il login del controller, le sue sessioni, i suoi controlli interni, resta utile, ma diventa l’ultima linea, non la prima. Davanti deve esserci uno strato che decide chi può anche solo parlare con quell’interfaccia, e che non dipende in alcun modo dal firmware che protegge.

È esattamente ciò che chiede il CERT-FR. La prima misura indicata nell’allerta non è “cambiare password” e non è “installare la patch”: è eliminare l’esposizione Internet delle unità interessate e di tutte quelle pubblicate su un indirizzo IP pubblico, perché esporre un’interfaccia di gestione su Internet è contrario alle buone pratiche. L’accesso remoto va ripristinato solo attraverso una VPN sicura o una rete protetta, mentre il filtro sugli IP dei tecnici è accettabile solo come soluzione temporanea.

In altre parole: il problema non si risolve riparando il software. Si risolve cambiando come il servizio viene raggiunto.

            INTERNET
                │
                ▼
     gate di accesso (identità, filtro)
                │
       autenticazione forte
                │
                ▼
     tunnel cifrato verso il sito
                │
                ▼
       segmento OT locale
                │
                ▼
   controller refrigerazione
                │
                ▼
         processo fisico

Il controller non deve conoscere Internet. Internet non deve conoscere il controller. In mezzo deve esserci un livello di accesso controllato, autenticato, monitorato e revocabile. E, dove possibile, la connessione deve partire dal sito verso il servizio di gestione, non da Internet verso il controller.

Come lo affrontiamo con ZTAG: l’esempio dei supermercati

È il ragionamento da cui nasce ZTAG, il Zero Trust Application Gateway che abbiamo sviluppato in LaloSpace. Proviamo ad applicarlo proprio al caso francese, immaginando una catena con qualche centinaio di punti vendita e un controller di refrigerazione in ciascuno.

1. Il controller sparisce da Internet. Nel punto vendita non resta aperta nessuna porta in ingresso. È il router del negozio ad aprire un tunnel WireGuard in uscita verso l’hub ZTAG, e a mantenerlo vivo. Il controller è raggiungibile solo attraverso quel tunnel: uno scanner che gira su Internet, come quelli che hanno contato i 2.765 dispositivi esposti, non trova più niente da contare.

2. L’unica cosa esposta è il gate. L’interfaccia web del controller viene pubblicata dietro ZTAG su un dominio gestito (per esempio uno per negozio). Prima che una richiesta arrivi al firmware, ZTAG decide se può passare. Senza una sessione valida, la richiesta non tocca il controller: un bug di autenticazione come il “code of the day”, che funziona solo se l’attaccante riesce a parlare con l’interfaccia, resta lì, ma non è raggiungibile da chi non ha superato il gate.

3. Il filtro viene prima dell’identità. Ogni accesso riceve un punteggio: paese di provenienza, tipo di rete (datacenter, VPN, Tor), presenza nelle blocklist CrowdSec e fail2ban, frequenza delle richieste. Chi ha un punteggio pulito prosegue; chi è dubbio deve comunque confermare un codice; chi è chiaramente ostile finisce su una pagina esca, che registra cosa prova a fare e, dopo pochi tentativi, viene bannato automaticamente fino al firewall. I profili di filtro si assegnano per dominio, quindi l’accesso ai controller può avere regole molto più severe di quelle di un normale sito.

4. Poi l’identità, con un secondo fattore. Il tecnico del frigorista deve essere un utente abilitato su quel dominio, con nome utente ed email, e confermare un codice OTP. Il filtro per IP non è l’unica difesa, come giustamente avverte il CERT-FR, ma uno dei segnali: le reti fidate dell’azienda di manutenzione possono essere riconosciute, ma l’identità resta obbligatoria per tutti gli altri.

5. Tutto è tracciato e revocabile. Accessi, tentativi, sessioni e azioni amministrative finiscono in un registro. Un utente si disattiva in un clic. Per l’accesso SSH ai server dietro il tunnel, ZTAG apre la porta solo per l’IP del tecnico, per un tempo limitato, dopo un OTP, e la richiude da sola alla scadenza.

6. Il legacy smette di essere un’emergenza. Il controller a fine vita, quello per cui la patch non arriverà mai, può restare in servizio finché l’impianto lo richiede, perché non è più un servizio Internet: è un apparato su un segmento chiuso, raggiungibile solo attraverso un percorso controllato. Non lo abbiamo reso sicuro. Abbiamo smesso di chiedergli di esserlo da solo.

Va detto con onestà anche cosa ZTAG non fa. Non corregge il firmware e non sostituisce gli aggiornamenti, che vanno comunque fatti dove esistono. E non impedisce a un utente legittimo, con credenziali valide, di impostare un valore assurdo: per quello serve un livello di sicurezza nel controller stesso, come vedremo tra poco. Quello che fa è togliere di mezzo l’intera classe di attacchi che oggi parte da Internet e arriva dritta al management plane, che è esattamente la classe che ha colpito i supermercati francesi.

On-premise non significa isolato

L’incidente smonta anche una distinzione sempre più fuorviante, quella tra cloud e on-premise. Gli apparati colpiti erano sistemi on-premise, installati nei locali tecnici dei negozi. Ma “on-premise” non significa “offline”.

fisicamente:     ON-PREMISE
logicamente:     INTERNET-FACING
operativamente:  CONTROLLO OT
impatto:         FISICO

È forse la peggiore combinazione possibile: l’impatto di un sistema industriale con la superficie d’attacco di un’applicazione Internet.

Allo stesso modo, la soluzione non è “mettere tutto nel cloud”. Una piattaforma centralizzata compromessa può aprire la porta a migliaia di impianti in una volta. La domanda giusta è un’altra: dove si trova il piano di controllo, chi può raggiungerlo e quale autorità possiede? Che sia locale o in cloud, deve restare separato in livelli distinti: Internet, identità, gestione, controllo OT, sicurezza dell’impianto, processo fisico. Quando questi livelli collassano l’uno sull’altro, una password rubata diventa una temperatura cambiata.

La comodità operativa ha costruito il rischio

Questa architettura non è nata per caso. Mandare un tecnico in ogni supermercato costa; farlo collegare da remoto costa molto meno. Dal punto di vista operativo è una scelta perfettamente razionale.

Il problema è che meno interventi fisici hanno significato più gestione remota, più connettività, più superficie d’attacco e, alla fine, una dipendenza totale dalla sicurezza di un pannello web. Un’interfaccia da cui si può cambiare il comportamento di un impianto frigorifero non è un comodo pannello: è una console OT privilegiata, e va progettata e protetta come tale.

Anche il modello dei privilegi va messo in discussione

C’è poi una seconda domanda. Perché una sessione remota di manutenzione deve poter modificare direttamente parametri capaci di causare danni fisici così gravi?

Un sistema cyber-fisico dovrebbe distinguere almeno tra monitoraggio (letture, allarmi, diagnostica), configurazione ordinaria (programmi, notifiche) e controllo critico (setpoint estremi, sbrinamento, protezioni). Più cresce l’impatto fisico di una modifica, più deve crescere il livello di autorizzazione richiesto.

È il concetto di safety envelope: anche un amministratore autenticato non dovrebbe poter impartire qualunque comando. Il controller dovrebbe rifiutare configurazioni palesemente incompatibili con l’uso normale dell’impianto, e per superare quei limiti dovrebbe servire qualcosa di speciale: un’autorizzazione aggiuntiva, la presenza locale, una doppia approvazione, una modalità di manutenzione a tempo. La sicurezza deve essere legata alla fisica del processo, non soltanto al login. È un compito del produttore dell’apparato, ed è complementare al gate: uno decide chi può arrivare, l’altro cosa può fare chi è arrivato.

Chi è responsabile?

È presto per attribuire la responsabilità tecnica a un singolo attore: il percorso preciso degli aggressori in ogni punto vendita non è ancora pubblico. Ma parlare solo di “vulnerabilità Danfoss” sarebbe riduttivo, anche perché sono stati colpiti più produttori.

La catena comprende il produttore del controller, l’integratore, l’installatore frigorista, il fornitore della connettività, chi gestisce IT e OT e infine la catena di supermercati. Se una console OT finisce su Internet, qualcuno l’ha resa possibile, qualcuno l’ha installata, qualcuno ha configurato la rete e qualcuno ha continuato a gestirla così. La sicurezza dell’OT è una responsabilità condivisa. Ma “condivisa” non può voler dire “di nessuno”.

Il vero incidente è avvenuto molto prima dell’attacco

La notte in cui qualcuno ha portato i frigoriferi a 50 °C è soltanto il momento in cui il problema è diventato visibile.

L’incidente architetturale era iniziato anni prima: quando si è deciso che un controller responsabile di un processo fisico poteva essere amministrato come una normale applicazione web, quando l’accesso remoto è diventato parte della manutenzione ordinaria, quando apparati ormai senza supporto sono rimasti collegati, e quando quelle interfacce sono finite direttamente sulla rete pubblica.

Lo stesso vale per tutto ciò che tocca il mondo fisico: climatizzazione, building automation, ascensori, generatori, UPS, pompe, impianti idrici, controllo accessi. Il management remoto è necessario. Ma va costruito dando per scontato che le password verranno rubate, che le CVE verranno scoperte, che il firmware diventerà obsoleto, che un dispositivo resterà senza patch e che qualcuno proverà a raggiungerlo da Internet.

Una buona architettura impedisce che ciascuno di questi eventi diventi automaticamente un incidente fisico. Finché il presupposto resta quello attuale, correggere l’ultima CVE servirà soltanto ad aspettare la prossima.