428 vulnerabilità in un solo PLC Siemens: quando l'OT critico italiano scopre che il patching non basta più

Ventidue ottobre 2026. Mentre l'attenzione del settore era catalizzata dall'ingresso di due nuove vulnerabilità nel catalogo KEV di CISA — una command injection in Collabora Online (CVE-2026-110447) e una SQL injection in Arista VeloCloud Orchestrator (CVE-2026-114625) (Fonte 1) (Fonte 2) — CISA pubblicava silenziosamente dieci advisory ICS firmati Siemens. Non era un bollettino settimanale: era un'unica ondata coordinata che copriva controller logici, sistemi SCADA, gateway industriali, piattaforme edge e persino librerie di sviluppo .NET. Il conto totale superava i cinquecento CVE, con un picco di 428 vulnerabilità concentrate su un solo dispositivo: la CPU SIMATIC S7-1500 1518(F)-4 PN/DP MFP (Fonte 8).

Per le aziende italiane che gestiscono infrastrutture critiche — energia, trasporti, manifatturiero, sanità — quel giorno ha segnato uno spartiacque. Non per la gravità singola di ogni falla, ma per la dimostrazione plastica che il modello "trova-patcha-ripeti" ha raggiunto il limite fisico nell'OT. Quando un vendor del calibro di Siemens rilascia aggiornamenti per dieci linee di prodotto contemporaneamente, ammettendo che per alcune «non è prevista alcuna correzione» (Fonte 11), la domanda non è più «quando patchiamo?», ma «come operiamo in sicurezza sapendo che non tutto si può patchare?».

L'anatomia di una disclosure di massa

L'ondata del 22 ottobre non era un caso isolato. Siemens ha concentrato in un'unica data — ICSA-26-295 — advisory che spaziano dal path traversal nella libreria .NET per SIMATIC S7 Webserver API (Fonte 3) alla SQL injection autenticata in RUGGEDCOM CROSSBOW con CVSS 8.8 (Fonte 5), dall'escalation di privilegi nel database WinCC (Fonte 9) all'esecuzione remota di codice via certificate validation bypass in Industrial Edge App Publisher (Fonte 7). C'è persino un template injection in dispositivi RUGGEDCOM APE1808 che integravano componenti Nozomi Guardian/CMC (Fonte 6), a dimostrazione che la supply chain software nell'OT include ora anche gli strumenti di monitoraggio della sicurezza stessa.

La caratteristica comune non è la tipologia di vulnerabilità — buffer overflow, path traversal, privilege escalation, information disclosure — ma la pervasività: ogni advisory elenca gli stessi settori critici (Critical Manufacturing, Transportation Systems, Energy, Healthcare, Financial Services, Government Facilities) e la stessa area di deployment: "Worldwide". In Italia, dove Siemens è ubiqua nelle centrali termoelettriche, nei sistemi di segnalamento ferroviario RFI, negli acquedotti gestiti da utility multi-servizio e nelle linee di assemblaggio automotive, questa pervasività si traduce in superficie d'attacco sistemica.

Il caso limite: 428 CVE su un controller che non si può fermare

L'advisory ICSA-26-295-11 merita un'analisi a parte. La CPU SIMATIC S7-1500 1518(F)-4 PN/DP MFP include un sottosistema GNU/Linux (firmware V3.1.7) che eredita l'intero surface di vulnerabilità del kernel e dello userland Linux: type confusion, use-after-free, race condition, buffer overflow classici, deadlock, divide by zero, spectre/meltdown residuals (Fonte 8). Quattrocentoventotto CVE. Siemens sta «preparando correzioni» e raccomanda «mitigazioni specifiche per prodotti dove le correzioni non sono o non ancora disponibili». Tradotto: il dispositivo è in produzione, gestisce processi safety-critical, e il vendor non ha una patch pronta per la maggioranza delle falle.

Per un asset owner italiano, le opzioni sono tre: spegnere l'impianto (impossibile per continuità operativa e contratti di servizio), applicare mitigazioni di rete (segmentazione, firewall industriali, unidirectional gateways), o accettare il rischio residuo. La quarta — attendere la patch — è una scommessa temporale che la storia dell'OT insegna essere persa in partenza: i cicli di qualifica firmware per PLC safety-certificati (SIL 2/3) richiedono 12-18 mesi. Quando la patch arriverà, il firmware V3.1.7 sarà già end-of-life.

L'eccezione che conferma la regola: quando il fix non arriva mai

L'advisory su Capital Embedded AR Classic (Fonte 11) è il manifesto di questa nuova normalità. La versione 431-422, ancora diffusa in ECU automotive e sistemi di controllo motore, ha un out-of-bounds read (CVE-2026-89208, CVSS 5.3) per cui Siemens dichiara esplicitamente: "No fix planned. Currently no fix is planned". La mitigazione raccomandata è «applicare segmentazione di rete e mettere le ECU dietro gateway/firewall correttamente configurati».

Non è un caso unico. Lo stesso CVE-2026-89208 affligge i prodotti Desigo PXC/PXM per building automation (Fonte 4) e APOGEE/TALON per gestione edifici — settori dove i cicli di vita superano i 20 anni. In Italia, interi distretti di teleriscaldamento, ospedali e campus universitari girano su questi controller. La segmentazione non è una best practice: è l'unica barriera tra un exploit remoto e la manipolazione fisica di valvole, bruciatori, gruppi frigoriferi.

Il paradosso dell'edge industriale: più IT, più rischio

Due advisory illuminano la tendenza convergente: Industrial Edge Device Kit (Fonte 10) e Industrial Edge App Publisher (Fonte 7). Il primo porta path traversal autenticato su kit arm64 dalla V1.10 alla V1.23 — quattordici versioni consecutive vulnerabili. Il secondo combina improper certificate validation (CWE-295) e XSS per ottenere RCE via Node.js integration, CVSS 8.3. Sono componenti che portano paradigmi IT (container, microservizi, TLS mutual auth, supply chain npm/pip) dentro il perimetro OT.

Il problema non è l'innovazione: è che i processi di vulnerability management IT (scansione continua, patch mensile, staging pre-produzione) cozzano con i requisiti OT (disponibilità 99,99%, change management rigido, certificazione funzionale). Un edge device che richiede riavvio per applicare una patch al kernel Linux diventa un vettore di downtime non pianificato. La soluzione industriale — redundancy a caldo — raddoppia la superficie d'attacco: due dispositivi da patchare, due superfici da monitorare.

Il settore sanitario: TLS spento di default nel 2026

Fuori dall'ecosistema Siemens, l'advisory medico su InterSystems IRIS for Health (Fonte 12) rivela un fallimento architetturale che dovrebbe essere impossibile nel 2026: TLS/SSL disabilitato di default su un database che gestisce cartelle cliniche, immagini DICOM, dati di sperimentazione clinica. CVE-2026-111594 (CVSS 8.1) permette a chiunque sulla rete di sniffare credenziali e autenticarsi. La mitigazione del vendor è «configurate il superserver per richiedere SSL/TLS» — tre impostazioni: Disabled, Enabled, Required. La default è Disabled.

In Italia, dove la sanità digitale sta migrando verso fascicolo sanitario elettronico 2.0 e telemedicina strutturata, questa configurazione di default è una time bomb. Le ASL e le aziende ospedaliere che hanno deployato IRIS for Health senza hardening esplicito espongono dati sensibili GDPR (art. 9) su reti spesso flat, condivise con sistemi amministrativi, dispositivi IoT medicali, guest Wi-Fi. La patch non esiste: è una configurazione. Ma richiede change control, test di interoperabilità con PACS, RIS, LIS — settimane di validazione in ambienti dove ogni minuto di fermo ha costi clinici, non solo economici.

Implicazioni operative per le organizzazioni italiane

La lezione del 22-23 ottobre 2026 è che la vulnerability management classica — basata su CVE, CVSS, SLA di patching — è insufficiente per l'OT. Le aziende italiane devono adottare tre pilastri operativi:

1. Inventario vivo con contesto di exploitability
Non basta sapere «ho Siemens S7-1500». Serve sapere: firmware V3.1.7, sottosistema Linux attivo, esposto su VLAN OT senza jump host, gestisce processo batch chimico con rischio runaway reaction. Solo il contesto trasforma 428 CVE in 3 criticità azionabili (es. buffer overflow in modulo comunicazione PROFINET raggiungibile da HMI compromesso).

**2. Mitigazione come controllo primario, patch come *bonus***
Segmentazione purpose-built (ISA/IEC 62443 zones/conduits), unidirectional gateways per storicizzazione dati, application whitelisting su HMI/engineering workstation, network anomaly detection basato su baseline comportamentale (non signature-based). Per Capital Embedded AR 431-422, la segmentazione non è opzionale: è l'unico controllo tecnico disponibile (Fonte 11).

**3. Threat-informed defense per priorizzare l'inpriorizzabile**
Il catalogo KEV di CISA rimane la bussola per l'IT esposto su internet (Fonte 1) (Fonte 2). Ma per l'OT, serve mappare le tecniche ATT&CK ICS (MITRE ATT&CK for ICS) alle vulnerabilità presenti: T0883 (Program Download) via WinCC privilege escalation (Fonte 9), T0857 (Manipulate I/O) via RUGGEDCOM CROSSBOW SQL injection (Fonte 5), T0815 (Exploit Public-Facing Application) via Industrial Edge App Publisher RCE (Fonte 7). Solo così si decide dove investire il budget di mitigazione limitato.

La nuova normalità: convivere con il vulnerabile

Il 22 ottobre 2026 non è stato un'anomalia. È la fotografia di un settore — l'automazione industriale — che ha importato la complessità software dell'IT (Linux, container, microservizi, librerie open source, componenti third-party) senza importarne i cicli di vita della sicurezza. Il risultato è un installed base di milioni di dispositivi dove la vulnerabilità non è un bug da fixare, ma una condizione strutturale da governare.

Per l'Italia, che ha nell'OT il cuore della sua autonomia strategica — energia, trasporti, manifattura ad alto valore, sanità — la sfida non è tecnica ma organizzativa: spostare il center of gravity della cybersecurity dal vulnerability management all'exposure management, dal patching al resilience engineering, dalla conformità normativa all'operational continuity assurance. Il KEV di CISA guida l'IT; per l'OT serve una bussola diversa, costruita su asset criticality, process consequence, mitigation feasibility.

I vendor faranno la loro parte — advisory coordinate, patch quando possibile, mitigazioni documentate. Ma la responsabilità finale, come sempre nell'OT, ricade su chi preme il pulsante di start ogni mattina: l'asset owner. Che oggi, in Italia, deve decidere non «quale patch applicare per prima», ma «quale rischio posso accettare di non patchare, e come lo monitoro finché non lo posso eliminare».