La catena di fornitura invisibile nell'OT: quando librerie open-source onnipresenti creano rischio sistemico multi-vendor

Il 6 ottobre 2026 CISA ha pubblicato sei advisory ICS nello stesso giorno. Quattro portano la firma Hitachi Energy, uno Johnson Controls, uno Savannah. A prima vista sembrano casi isolati: un relè di protezione REB500, una suite asset management, un sistema SCADA SOI, un RTU legacy, un controller building automation EasyIO, un client SMTP embedded. Ma scavando nei dettagli tecnici emerge un filo conduttore che dovrebbe preoccupare ogni CISO responsabile di ambienti OT: le stesse librerie open-source ricorrono in prodotti di vendor diversi, in settori diversi, creando una superficie d'attacco condivisa che nessun singolo vendor governa interamente.

Non è una novità che l'OT si basi su componenti terzi. La novità è la concentrazione temporale e la trasversalità settoriale: in 24 ore CISA ha documentato vulnerabilità in libexpat (parser XML onnipresente), Apache ActiveMQ (message broker enterprise), lwIP (stack TCP/IP per embedded) — tutte componenti che i vendor incorporano "as-is" o con modifiche minime, spesso senza processo di aggiornamento autonomo quando upstream rilascia patch. Il risultato è una catena di fornitura software invisibile che lega relè di sottostazione, controller HVAC, sistemi di controllo accessi fisici e RTU idrici in un unico destino di rischio.

Il caso libexpat: da parser XML a DoS nell'energy

L'advisory ICSA-26-279-05 su Hitachi Energy REB500 documenta due CVE (CVE-2024-8176, CVE-2025-59375) entrambe radicate in libexpat < 2.7.2 (Hitachi Energy REB500). Il relè REB500 usa libexpat per la funzionalità IEC 61850 — lo standard per la comunicazione in sottostazioni elettriche. Un utente autenticato con accesso locale può inviare messaggi IEC 61850 malevoli che triggerano ricorsione non controllata (CWE-674) o allocazione di memoria eccessiva via documenti XML piccoli ma crafted. Risultato: DoS sul relè, con potenziale memory corruption "a seconda dell'ambiente e uso della libreria".

Hitachi raccomanda aggiornamento a versione 8.3.4.0. Ma la domanda resta: quanti altri dispositivi IEC 61850 in rete — di Hitachi, di ABB, di Siemens, di GE — incorporano la stessa libreria? Libexpat è ovunque: firmware di switch industriali, gateway protocolli, HMI, RTU. Una singola vulnerabilità upstream diventa istantaneamente multi-vendor, multi-settore. E il vendor finale spesso scopre la dipendenza solo quando CISA pubblica l'advisory.

Apache ActiveMQ: un vettore che unisce SCADA energy e controllo accessi fisici

Stesso giorno, due advisory, stesso componente: Apache ActiveMQ. In Hitachi Energy SOI (ICSA-26-279-04) la CVE-2026-34197 (CVSS 8.8) permette RCE via Jolokia JMX-HTTP bridge esposto di default (Hitachi Energy SOI). L'attaccante autenticato invoca operazioni MBean per caricare contesto Spring XML remoto → esecuzione codice arbitrario sul JVM del broker. SOI è un sistema SCADA per settore energy, deployed worldwide.

Poche ore prima, Armatura One — sistema di controllo accessi fisici per critical manufacturing, energy, transportation — riceve advisory ICSA-26-274-01 per CVE-2023-46604 (CVSS 9.8), deserializzazione OpenWire in ActiveMQ embedded che permette RCE non autenticato (Armatura LLC Armatura One). Armatura ha patchato in v4.7.2 (USA v4.6.1), ma la vulnerabilità è nota dal 2023.

Due prodotti, due settori (energy SCADA + physical access control), stesso componente embedded, stesso vettore (ActiveMQ), gravità critica in entrambi i casi. Un attaccante che sviluppa exploit per ActiveMQ ha immediato accesso a due superfici d'attacco critiche diversissime. E non sono gli unici: ActiveMQ è embedded in decine di prodotti OT/ICS come message bus interno.

lwIP: lo stack TCP/IP ubiquo che espone energy e water

Il quinto advisory dello stesso giorno (ICSA-26-279-02) colpisce Savannah lwIP SMTP client v2.2.1 — CVE-2026-15340, CVSS 9.8 CRITICAL, classic buffer overflow (Savannah lwIP SMTP client). lwIP (lightweight IP) è lo stack TCP/IP open-source de facto per sistemi embedded: lo trovi in PLC, RTU, gateway cellulari, contatori smart, sensori IoT industriali. Settori interessati: Energy, Water and Wastewater Systems. Deployed worldwide. Headquarters Svezia.

La vulnerabilità: il client SMTP non valida la dimensione degli input → buffer overflow → crash o RCE remoto. La correzione è una patch git (commit 614420f) che il maintainer upstream ha rilasciato. Ma chi la applica? Savannah (il maintainer originario di lwIP) non vende prodotti finiti. I vendor che incorporano lwIP nei loro dispositivi devono: accorgersi della patch, backportarla sul loro fork, ricompilare firmware, testare, rilasciare, distribuire agli asset owner. Ogni passaggio introduce latenza. Nel frattempo, milioni di dispositivi energy/water espongono un client SMTP vulnerabile — spesso su interfacce di gestione non segmentate.

L'eredità EOL: quando il vendor non può (o non vuole) patchare

Il sesto advisory Hitachi (ICSA-26-279-06) e quello Johnson Controls su EasyIO FG (ICSA-26-279-01) rivelano l'altra faccia del problema: prodotti a fine vita che non riceveranno mai patch (Hitachi Energy RTU500) (Johnson Controls EasyIO FG).

Hitachi RTU500 CMU firmware ≤ 11.x: Dragos ha trovato vulnerabilità (CVE-2026-8065/66/67 più CVE storiche 2010, 2014). Hitachi risponde: "versioni legacy sviluppate secondo requisiti cybersecurity dell'epoca... non incorporano controlli standard moderni... strongly recommends upgrading to currently supported version". Traduzione: niente patch per versioni EOL, comprate il nuovo.

Johnson Controls EasyIO FG (firmware ≤ 2.0b52): hard-coded credentials + improper privilege management → full device compromise. Risposta ufficiale: "prodotto EOL/EOS dal 2019, source code non più disponibile, nessun firmware patch verrà emesso". Mitigazioni: isolamento rete, VLAN, no Internet exposure, trusted workstations only, block remote login. Difesa perimetrale come unica opzione.

Ma questi dispositivi sono ancora in campo. EasyIO FG gestisce building automation in critical manufacturing, commercial facilities, government, transportation, energy. RTU500 sta in sottostazioni elettriche e reti idriche. La catena di fornitura invisibile non finisce con il vendor: finisce quando l'asset owner riesce a sostituire l'hardware — anni, spesso decenni dopo.

Il paradosso del vendor responsabile: Asset Suite e il servlet di test in produzione

L'advisory ICSA-26-279-03 su Hitachi Asset Suite ≤ 9.9.0 mostra un altro pattern sistemico: codice di test lasciato esposto in produzione (Hitachi Energy Asset Suite). CVE-2026-7395 (CVSS 8.1 HIGH): servlet HTTPPublishAdapterTestServlet — "meant for testing purposes in non-production environment" — accessibile senza autenticazione, permette upload file di configurazione → information disclosure + integrity compromise. Hitachi: aggiornare a 9.9.1 "when available" e nel frattempo disabilitare il servlet.

Quanto spesso accade? Debug endpoint, test servlet, interfacce di manutenzione, default credentials "per commissioning" — artefatti del ciclo di sviluppo che sopravvivono in produzione perché il processo di release non include hardening automatizzato. E quando il componente vulnerabile è una libreria embedded (come ActiveMQ in SOI o Armatura), il vendor non controlla nemmeno la configurazione di default del componente upstream.

Implicazioni per le aziende italiane: perimetro OT esteso e responsabilità condivisa

Per un'azienda italiana che gestisce infrastrutture critiche — energy, water, transportation, manufacturing — questi advisory non sono "notizie estere". Hitachi Energy, Johnson Controls, Armatura hanno base installata significativa in Italia. REB500 protegge sottostazioni Terna e distributori locali. EasyIO (FG e Neo) controlla HVAC in ospedali, data center, PA, impianti industriali. Armatura One gestisce accessi in siti sensibili. RTU500 sta in reti idriche ed elettriche regionali.

La lezione operativa è triplice:

1. Inventario componenti, non solo asset. Sapere di avere "un relè Hitachi REB500" non basta. Serve sapere: che versione di libexpat gira sotto IEC 61850? Che versione di ActiveMQ è embedded in SOI? lwIP è nel firmware del mio RTU? Questo richiede SBOM (Software Bill of Materials) dai vendor — e pressione contrattuale per ottenerli.

1. Segmentazione come compensazione per EOL. Dove il vendor non patcha (EasyIO FG, RTU500 legacy), l'unica difesa è architettura di rete: zone OT isolate, jump host controllati, monitoraggio anomalie traffico IEC 61850/Modbus/BACnet, blocco interfacce di gestione non necessarie. Le mitigazioni CISA per EasyIO FG sono un template valido per qualsiasi dispositivo non patchabile.

1. Monitoraggio KEV incrociato. CISA ha aggiunto al KEV Catalog nel 1-4 ottobre: CVE-2026-104286 (FortiMail path traversal), CVE-2026-102489/90 (Zammad session fixation/privilege), CVE-2026-88779 (Citrix NetScaler buffer overflow) (CISA Adds One Known Exploited Vulnerability to Catalog) (CISA Adds Two Known Exploited Vulnerabilities to Catalog) (CISA Adds One Known Exploited Vulnerability to Catalog). Nessuna di queste è OT-specific, ma tutte colpiscono infrastrutture che l'OT usa: VPN, mail gateway, helpdesk ticketing. La superficie d'attacco è ibrida.

La catena di fornitura invisibile non si spezza con un advisory. Si gestisce con processi continui: richieste SBOM nelle gare d'appalto, clausole di manutenzione sicurezza per 10+ anni, test di componenti embedded in laboratorio prima del deploy, threat modeling che assume "la libreria X è vulnerabile" non "il vendor Y ha patchato". Perché la prossima libexpat, ActiveMQ, lwIP è già nel firmware che installerete domani.