mySCADA myPRO Manager corregge due falle di autenticazione, una classificata critica
mySCADA myPRO Manager presenta ora due falle di sicurezza divulgate, inclusa una con valutazione 9.8, perché interfacce sensibili accettavano richieste senza autenticazione. Sono interessate le versioni 2.1 e precedenti. La versione 2.2 contiene le correzioni del fornitore.
La vulnerabilità più grave espone funzioni di gestione privilegiate tramite l'API dei comandi del prodotto. La seconda espone un endpoint HTTP in grado di inviare messaggi di testo arbitrari attraverso un modem GSM connesso. Nessuno dei due percorsi richiede un account autenticato prima di accettare la richiesta pertinente.
Ciò crea un netto conflitto tra la praticità della gestione industriale e i controlli di accesso di base. myPRO Manager aiuta gli operatori a configurare ambienti connessi, ma le interfacce vulnerabili non verificavano chi impartisse comandi sensibili. Il problema va oltre una normale applicazione web perché i prodotti mySCADA sembrano essere presenti in ambienti di tecnologia operativa in tutto il mondo.
La risposta immediata è chiara. Gli operatori devono individuare le installazioni interessate, aggiornarle e verificare quali reti possano raggiungere le loro interfacce di gestione. Il lavoro più difficile inizia successivamente, soprattutto per sistemi isolati, installazioni non gestite e ambienti in cui i tempi di inattività complicano gli aggiornamenti.
Cosa è cambiato in mySCADA myPRO Manager
La divulgazione identifica due distinti fallimenti dell'autorizzazione, ma la vulnerabilità dell'API dei comandi comporta il maggiore rischio operativo.
Il 15 settembre 2026, CISA ha pubblicato un avviso industriale relativo a mySCADA myPRO Manager. Identifica CVE-2026-73807 e CVE-2026-82567 nelle versioni 2.1 e precedenti.
La versione 2.2 è indicata come non interessata. mySCADA Technologies afferma che tale rilascio risolve entrambi i problemi e raccomanda l'aggiornamento all'ultima versione disponibile.
CVE-2026-73807 riguarda l'API dei comandi, ovvero l'interfaccia utilizzata dai componenti software per inviare richieste di gestione. Secondo il record ufficiale, l'API non applica correttamente l'autenticazione per le funzioni privilegiate.
Un attaccante non necessita di un account esistente. Gli serve l'accesso di rete all'interfaccia interessata, quindi può tentare di richiamare funzioni normalmente riservate a un amministratore autorizzato.
Il record CVE assegna alla falla un punteggio CVSS 3.1 di 9.8, che rientra nella fascia critica. Il suo vettore descrive una vulnerabilità raggiungibile via rete, con bassa complessità di attacco, nessun privilegio richiesto e nessuna interazione utente necessaria.
Il record assegna inoltre un punteggio CVSS 4.0 di 9.3. Entrambe le valutazioni indicano un elevato potenziale impatto su riservatezza, integrità e disponibilità all'interno del sistema vulnerabile.
Tale punteggio non dimostra che ogni installazione sia esposta allo stesso modo. CVSS misura la gravità tecnica secondo presupposti standardizzati. Non può sapere se una specifica API dei comandi si trovi dietro diversi firewall o sia raggiungibile da una rete non attendibile.
CVE-2026-82567 interessa il gateway di notifica, che collega myPRO Manager alla consegna di SMS attraverso un modem GSM. L'endpoint HTTP vulnerabile accetta un numero di telefono e un messaggio, quindi istruisce il modem a inviare quel testo.
L'endpoint non richiede prima l'autenticazione. Un attaccante con adeguato accesso di rete può quindi inviare destinatari e messaggi arbitrari tramite il modem connesso.
Questa seconda vulnerabilità ha un punteggio CVSS 3.1 di 6.3, classificato come medio. Il suo vettore usa un percorso di attacco da rete adiacente anziché il percorso di rete più ampio assegnato a CVE-2026-73807.
Questa distinzione è importante. La falla SMS richiede generalmente che l'attaccante raggiunga la rete locale o adiacente pertinente. La falla critica dell'API dei comandi ha una classificazione di attacco di rete più ampia.
Entrambi i problemi condividono tuttavia la stessa debolezza di fondo. Un'operazione sensibile accetta input prima di stabilire se il richiedente abbia l'autorizzazione per eseguirla.
CISA attribuisce le scoperte ai ricercatori di SECNORA Rajivarnan R. e Shirshak. Le vulnerabilità sono state scoperte esternamente e coordinate attraverso il processo di divulgazione dell'agenzia per i sistemi di controllo industriale.
L'avviso colloca le distribuzioni interessate nei settori della produzione critica, dell'energia, dell'alimentare e agricoltura, dei trasporti e delle acque e acque reflue. Descrive la distribuzione come mondiale e indica la sede del fornitore in Cechia.
Tali etichette settoriali non dimostrano che ogni istanza interessata controlli direttamente un processo fisico. Mostrano però perché una lacuna di autenticazione in questo prodotto meriti particolare attenzione da parte dei team di tecnologia operativa.
Perché l'assenza di autenticazione conta di più nelle reti industriali
Una richiesta che raggiunge un'interfaccia di gestione industriale può avere conseguenze ben oltre il processo software che la riceve.
L'autenticazione risponde a una domanda fondamentale: chi sta effettuando questa richiesta? L'autorizzazione risponde alla domanda successiva: cosa è autorizzata a fare tale identità?
CVE-2026-73807 infrange tale confine attorno alle funzioni di gestione privilegiate. La descrizione ufficiale non elenca ogni funzione esposta, quindi i difensori non dovrebbero presumere un esito specifico oltre l'accesso documentato.
Tuttavia, “funzioni di gestione privilegiate” segnala una significativa violazione della fiducia. Un'interfaccia progettata per l'amministrazione accettava richieste di rete senza applicare il controllo che dovrebbe separare gli amministratori dagli altri sistemi.
Il vettore CVSS riflette questa preoccupazione. Presuppone nessun privilegio, nessuna interazione utente, bassa complessità e un potenziale impatto elevato su riservatezza, integrità e disponibilità.
Per un sito web aziendale, un fallimento del controllo degli accessi può esporre dati o impostazioni dell'applicazione. In un ambiente di tecnologia operativa, il software di gestione può trovarsi vicino a sistemi che monitorano apparecchiature, raccolgono dati di processo, distribuiscono allarmi o supportano le decisioni degli operatori.
La conseguenza esatta dipende da ogni distribuzione. La progettazione della rete, le apparecchiature connesse, la configurazione del prodotto e le funzioni esposte determinano tutti il rischio reale.
Questa variabilità rende essenziale il contesto delle risorse. Un'installazione di laboratorio disconnessa non presenta la stessa esposizione di un gestore di produzione raggiungibile da un segmento aziendale condiviso.
Un'installazione esposta a Internet rappresenta un caso ancora più urgente. Sebbene l'avviso non pubblichi un conteggio dei sistemi esposti, qualsiasi accesso diretto non attendibile rimuove una rilevante barriera difensiva.
La debolezza SMS presenta un impatto più circoscritto, ma illustra lo stesso problema architetturale. I gateway di notifica spesso veicolano avvisi operativi di cui ci si aspetta che gli utenti si fidino.
Un attaccante che inviasse messaggi arbitrari tramite un modem noto potrebbe creare confusione, impersonare notifiche di routine o consumare la capacità di messaggistica. Il record ufficiale non afferma che gli attaccanti possano leggere messaggi esistenti o riconfigurare il modem.
I difensori dovrebbero preservare questa distinzione. La capacità divulgata è la trasmissione SMS non autorizzata, non il controllo dimostrato di ogni funzione di notifica.
Ciononostante, i messaggi arbitrari possono essere rilevanti durante un incidente. Gli operatori possono dipendere dagli avvisi via testo quando sono lontani da una sala di controllo o quando un altro canale di comunicazione non funziona.
Un messaggio fraudolento potrebbe essere scambiato per un avviso legittimo del sistema. Un'ondata di messaggi indesiderati potrebbe inoltre rendere più difficili da riconoscere le notifiche reali.
Questi scenari sono considerazioni ragionevoli sul rischio, non segnalazioni documentate di sfruttamento. L'avviso stabilisce il percorso di invio non autorizzato, mentre ogni organizzazione deve valutarne le conseguenze operative.
Il contesto industriale cambia anche la rapidità con cui i team possono applicare le patch. Gli ambienti di produzione possono richiedere interruzioni pianificate, test di compatibilità, coordinamento con il fornitore o una revisione della sicurezza prima di modificare il software di gestione.
Questi controlli riducono le interruzioni accidentali, ma possono prolungare il periodo in cui il codice vulnerabile rimane installato. Le restrizioni di rete sono quindi importanti prima, durante e dopo il processo di aggiornamento.
La praticità si è scontrata con il controllo degli accessi
Il problema centrale non è una catena di exploit avanzata, ma funzionalità sensibili esposte senza un efficace punto di controllo dell'identità.
Le API di gestione esistono perché l'amministrazione manuale non è scalabile. Consentono a componenti software, console e servizi di scambiare comandi tramite richieste definite.
I gateway di notifica offrono una praticità simile. Collegano gli eventi industriali ai canali di comunicazione, consentendo al software di distribuire avvisi tramite un modem GSM.
Entrambe le soluzioni possono essere utili. La loro sicurezza dipende dal considerare ogni richiesta in ingresso come non attendibile finché il richiedente non dimostri un'identità accettata e riceva un'autorizzazione esplicita.
Le falle divulgate mostrano cosa accade quando questa sequenza si interrompe. Nell'API dei comandi, un richiedente può raggiungere funzionalità privilegiate senza la prevista applicazione dell'autenticazione.
Nel gateway di notifica, l'endpoint HTTP accetta i dati di destinazione e messaggio prima di verificare un utente autorizzato. Trasmette quindi il messaggio richiesto al modem connesso.
In nessuno dei percorsi documentati è richiesto social engineering. Nessun amministratore deve aprire un file dannoso o approvare una richiesta.
Ciò non rende lo sfruttamento automatico. L'attaccante deve comunque ottenere la raggiungibilità di rete richiesta, identificare l'interfaccia e inviare una richiesta accettata dal servizio.
Questi prerequisiti spiegano perché l'architettura di rete rimanga importante. Un servizio vulnerabile isolato in una zona di gestione strettamente controllata offre meno percorsi di attacco rispetto a uno esposto su ampie reti interne.
Tuttavia, la segmentazione è un controllo compensativo, non una correzione per l'assenza di autenticazione. Le reti cambiano, le regole dei firewall si accumulano, i percorsi di accesso remoto si espandono e i dispositivi interni compromessi possono aggirare le supposizioni sulle posizioni attendibili.
La progettazione più sicura combina più livelli. L'applicazione autentica ogni richiesta sensibile, l'autorizzazione limita le azioni disponibili e la rete restringe quali sistemi possano raggiungere l'interfaccia.
La registrazione dovrebbe quindi documentare l'attività accettata e rifiutata. Il monitoraggio dovrebbe identificare comandi insoliti, indirizzi di origine inattesi e destinazioni SMS irregolari.
CVE-2026-73807 e CVE-2026-82567 sono importanti perché indeboliscono il livello applicativo di tale modello. La versione 2.2 ripristina la correzione software supportata dal fornitore, mentre i controlli di rete ne riducono l'esposizione.
Il contrasto spiega anche la differenza di gravità. Il problema dell'API dei comandi è valutato per effetti potenzialmente elevati sulle tre proprietà di sicurezza centrali del sistema vulnerabile.
L'endpoint SMS riceve valutazioni di impatto inferiori e una classificazione da rete adiacente. Il suo esito documentato è limitato all'invio di messaggi arbitrari attraverso un modem collegato.
Trattare entrambe le scoperte come identiche oscurerebbe le priorità di correzione. Ignorare il problema con punteggio inferiore trascurerebbe un pratico percorso di abuso attraverso un canale di notifica attendibile.
I team dovrebbero pertanto dare priorità all'esposizione critica dell'API dei comandi, risolvendo al contempo entrambe le vulnerabilità tramite lo stesso aggiornamento. Un unico confine di versione semplifica la decisione software, anche se il lavoro di distribuzione rimane complesso.
Il fornitore afferma che i dispositivi connessi notificano agli utenti in mySCADA Pro Manager quando è disponibile una nuova versione. Gli ambienti offline richiedono agli operatori di ottenere l'aggiornamento separatamente dalla pagina di download del manager.
I sistemi offline meritano particolare attenzione. Il loro isolamento può ridurre l'esposizione, ma elimina anche le notifiche automatiche degli aggiornamenti e può nascondere software obsoleto agli strumenti centralizzati di inventario.
Un air gap non dovrebbe mai sostituire la consapevolezza delle versioni. Supporti portatili, connessioni temporanee per la manutenzione, laptop e routing configurato in modo errato possono creare percorsi assenti nella progettazione originale.
La patch è chiara, ma il rischio di distribuzione rimane
La versione 2.2 colma la lacuna software documentata, ma le organizzazioni hanno comunque bisogno di prove che ogni installazione interessata abbia raggiunto lo stato corretto.
La correzione del fornitore è semplice: aggiornare mySCADA myPRO Manager alla versione 2.2 o successiva. L'intervallo interessato termina con la versione 2.1.
Questa chiarezza elimina una comune fonte di confusione. Per queste due CVE, i team non devono confrontare più patch destinate a rami diversi.
La sfida operativa è l'inventario. Le organizzazioni devono individuare dove è in esecuzione il prodotto, quale versione utilizza ogni installazione e quali interfacce siano raggiungibili da ciascuna zona di rete.
Questa attività può far emergere lacune non correlate al nuovo advisory. Il software industriale può risiedere su workstation di progettazione, sistemi manager dedicati, dispositivi temporanei per la messa in servizio o macchine gestite al di fuori dei normali processi aziendali.
Un inventario affidabile dovrebbe includere la versione dell'applicazione, l'identità dell'host, la posizione in rete, il responsabile del sistema, la funzione operativa e i percorsi di comunicazione consentiti. Dovrebbe inoltre registrare se è collegato un modem GSM.
Il dettaglio relativo al modem determina se il percorso SMS documentato esista in una determinata distribuzione. Un'installazione priva di quel componente non presenta lo stesso scenario pratico della CVE-2026-82567.
L'API dei comandi richiede un'analisi separata. I team dovrebbero identificare ogni origine autorizzata a raggiungerla e verificare se qualche percorso provenga da reti utente, segmenti wireless, sistemi di accesso dei fornitori o dalla rete Internet pubblica.
Una sola regola firewall non dimostra l'isolamento. I test del flusso dei pacchetti e la revisione della configurazione forniscono prove più solide che solo i sistemi di gestione previsti possano connettersi.
Prima dell'aggiornamento, gli operatori dovrebbero confermare le procedure di backup e ripristino. Dovrebbero inoltre comprendere le dipendenze che potrebbero non funzionare se il manager modificasse il proprio comportamento dopo l'aggiornamento.
I test dovrebbero concentrarsi sulle normali operazioni di gestione, la consegna degli allarmi, le notifiche SMS, l'autenticazione e la connettività con i sistemi gestiti. Lo scopo è individuare problemi di compatibilità prima della distribuzione in produzione.
I team dovrebbero quindi registrare la versione installata dopo la modifica. Una notifica di aggiornamento o un programma di installazione scaricato non dimostrano che ogni host abbia completato con successo l'upgrade.
Quando l'applicazione immediata della patch è impossibile, ridurre l'esposizione diventa urgente. L'accesso alle interfacce di gestione dovrebbe essere limitato ai sistemi esplicitamente autorizzati tramite firewall e zone di rete segmentate.
L'amministrazione remota dovrebbe utilizzare percorsi di accesso controllati anziché esporre direttamente l'applicazione. Le consolidate linee guida industriali di CISA raccomandano di ridurre al minimo l'esposizione, separare le reti di controllo dalle reti aziendali e utilizzare metodi di accesso remoto sicuri.
Le sue linee guida sulla difesa in profondità considerano l'architettura di rete, il controllo degli accessi, il monitoraggio e la risposta agli incidenti come salvaguardie complementari. Nessuna dovrebbe essere considerata un sostituto permanente del software corretto.
I controlli temporanei dovrebbero avere responsabili e date di scadenza. Altrimenti, una restrizione firewall d'emergenza può diventare silenziosamente la risposta a lungo termine mentre la versione vulnerabile rimane installata.
Anche il monitoraggio necessita di segnali specifici per la distribuzione. I team possono esaminare le connessioni all'API dei comandi, gli eventi di autenticazione rifiutata dopo l'aggiornamento e richieste insolite agli endpoint di notifica.
Per i sistemi abilitati agli SMS, gli operatori dovrebbero confrontare l'attività del modem con gli avvisi previsti. Numeri di destinazione non riconosciuti, contenuti dei messaggi insoliti e una frequenza di invio anomala meritano approfondimenti.
I log storici possono aiutare a determinare se si sia verificata attività sospetta prima della correzione. Tuttavia, l'assenza di una voce nei log non può stabilire che non vi sia stato alcun tentativo, se l'endpoint vulnerabile non disponeva di una registrazione adeguata.
I responsabili della risposta agli incidenti dovrebbero conservare i dati di rete, host, applicazione e modem pertinenti. Se l'attività appare sospetta, dovrebbero seguire le procedure consolidate di escalation e segnalazione.
L'advisory non fornisce una descrizione pubblica dello sfruttamento. Ciò limita le conclusioni che i difensori possono trarre sul comportamento degli attaccanti, sugli strumenti o sulle vittime osservate.
Non riduce la gravità tecnica di un percorso di gestione non autenticato. L'esposizione e l'impatto sulla missione dovrebbero determinare la velocità della risposta di ciascuna organizzazione.
mySCADA ha già affrontato in passato vulnerabilità ad alta gravità
Le nuove falle fanno parte di un quadro più ampio, nel quale le funzionalità di gestione diventano confini di sicurezza che gli attaccanti possono testare direttamente.
CISA ha pubblicato advisory precedenti riguardanti prodotti mySCADA. Questi casi precedenti non dimostrano una causa tecnica comune, ma forniscono un contesto utile ai difensori.
Nel 2022, CISA ha descritto una vulnerabilità di command injection in mySCADA myPRO versioni 8.26.0 e precedenti. Un utente autenticato poteva modificare parametri ed eseguire comandi del sistema operativo.
Quel precedente problema di myPRO aveva un punteggio CVSS 3 di 9,9. Il fornitore consigliava l'aggiornamento alla versione 8.27.0 o successiva.
La falla dell'API dei comandi del 2026 differisce in un aspetto cruciale. Il suo vettore pubblicato non richiede privilegi, mentre il problema del 2022 richiedeva un utente autenticato.
Anche i prodotti e gli schemi di versione differiscono nei rispettivi record, pertanto gli operatori non dovrebbero dedurre un percorso di aggiornamento diretto tra questi advisory. Ogni installazione interessata deve essere confrontata con le informazioni specifiche sul prodotto e sulla versione.
Un advisory separato del 2025 riguardava molteplici vulnerabilità di myPRO Manager, inclusa l'iniezione di comandi del sistema operativo. Questa cronologia rafforza la necessità di trattare i componenti di gestione come risorse ad alto valore.
La lezione non è che un singolo fornitore sia particolarmente vulnerabile. Le interfacce amministrative nei prodotti industriali concentrano regolarmente capacità che gli attaccanti considerano preziose.
Espongono configurazioni, comunicazioni, credenziali, aggiornamenti o connessioni ad ambienti controllati. Una singola misura di controllo mancante può quindi compromettere diverse salvaguardie a valle.
Per questo la gestione delle vulnerabilità dovrebbe monitorare i prodotti in base alla funzione, non soltanto al numero di CVE. Un server di gestione merita priorità perché il suo ruolo può amplificare l'impatto di una compromissione.
Lo stesso ragionamento si applica agli appliance per l'accesso remoto, alle workstation di progettazione, agli storici dei dati e ai gateway di notifica. La loro vicinanza alle operazioni conferisce alle comuni debolezze software una maggiore rilevanza dipendente dal contesto.
Le organizzazioni dovrebbero inoltre evitare di basarsi interamente sui punteggi in evidenza. CVE-2026-82567 ha un punteggio medio, ma il suo abuso potrebbe comunque interrompere il processo affidabile di avvisi di un sito.
Al contrario, un punteggio di 9,8 non dimostra che un'istanza isolata possa essere attaccata da Internet. Indica gravi caratteristiche tecniche una volta che un attaccante raggiunge il servizio vulnerabile.
Una prioritizzazione efficace combina gravità, esposizione, sfruttabilità, funzione operativa e difficoltà di ripristino. Considera inoltre se per un sistema sia disponibile una versione corretta.
In questo caso, la versione corretta esiste. Ciò rende sempre più difficile giustificare l'uso prolungato della versione 2.1 o precedente, salvo che un vincolo operativo ne impedisca la distribuzione.
Se tale vincolo esiste, la direzione dovrebbe documentarlo. Il record dovrebbe indicare il responsabile, spiegare la dipendenza, elencare i controlli temporanei e definire la prossima data di revisione.
Questo trasforma il ritardo nell'applicazione della patch in una decisione di rischio gestita. Senza questo processo, il ritardo diventa un'impostazione predefinita invisibile.
Cosa dovrebbero monitorare gli operatori
I prossimi segnali utili sono una copertura di aggiornamento verificata, prove di sfruttamento e la conferma che le interfacce sensibili non siano più ampiamente raggiungibili.
In primo luogo, le organizzazioni dovrebbero misurare l'adozione della versione 2.2 o successiva. La metrica interna più importante non è se una patch sia stata scaricata, ma se ogni risorsa interessata ora segnali una versione corretta.
Questa misurazione dovrebbe includere i sistemi esterni ai normali strumenti aziendali. Installazioni offline, dispositivi gestiti da appaltatori e ambienti di test possono conservare versioni vulnerabili molto tempo dopo il completamento degli aggiornamenti in produzione.
Un risultato completo rafforza l'argomentazione secondo cui il rischio software immediato è stato contenuto. Risorse non identificate o irraggiungibili indeboliscono questa conclusione.
In secondo luogo, i difensori dovrebbero seguire fonti autorevoli per eventuali cambiamenti nello stato di sfruttamento. Nuovo codice proof-of-concept, attacchi confermati o l'inclusione in un catalogo governativo di sfruttamento cambierebbero l'urgenza della risposta.
Al momento della pubblicazione, il materiale disponibile nell'advisory descrive le vulnerabilità e le correzioni senza accertare una campagna di sfruttamento attiva. I lettori dovrebbero distinguere questa assenza da una prova che lo sfruttamento sia impossibile.
Le informazioni sulle minacce possono cambiare rapidamente dopo la divulgazione. Gli attaccanti ottengono un nome chiaro del prodotto, l'intervallo di versioni interessate, la categoria della debolezza e una descrizione delle funzionalità esposte.
In terzo luogo, gli operatori dovrebbero convalidare l'architettura circostante. L'aggiornamento dell'applicazione non dovrebbe concludere la revisione dell'esposizione delle interfacce di gestione.
Una scansione dalle zone di rete appropriate può confermare se l'API dei comandi e il gateway di notifica accettino connessioni solo da origini approvate. La revisione del firewall dovrebbe fornire la stessa risposta.
Se un segmento esteso può ancora raggiungere questi servizi, l'ambiente rimane inutilmente esposto a futuri difetti. Una patch chiude vulnerabilità note, mentre la segmentazione limita il raggio d'azione della prossima vulnerabilità sconosciuta.
I team dovrebbero inoltre verificare il comportamento dell'applicazione dopo l'aggiornamento. I comandi sensibili devono richiedere accesso autenticato e autorizzato e l'endpoint SMS deve rifiutare richieste non autenticate.
Questi test dovrebbero utilizzare procedure approvate in un ambiente controllato. Effettuare test in produzione senza coordinamento può creare rischi operativi.
Le conclusioni giustificano anche una revisione della progettazione di account e accessi. Le organizzazioni dovrebbero identificare chi amministra il manager, quali account di servizio interagiscono con esso e come vengono protette le credenziali.
Il principio del privilegio minimo rimane importante dopo il ripristino dell'autenticazione. Un account valido dovrebbe ricevere solo le funzioni necessarie al proprio ruolo.
I log meritano un controllo finale. I team di sicurezza necessitano di dettagli sufficienti per collegare una richiesta a una fonte, un'identità, un'azione, un risultato e un orario.
Per le notifiche supportate da modem, i record dovrebbero collegare ogni messaggio all'evento o all'utente che lo ha avviato. Ciò aiuta a distinguere l'automazione legittima dall'uso non autorizzato.
La risposta pratica a mySCADA myPRO Manager è quindi più ampia dell'installazione di una sola release. Prima applicare la patch, poi verificare raggiungibilità, applicazione dei controlli di accesso, logging e copertura delle risorse.
Se la vostra organizzazione utilizza myPRO Manager, può dimostrare che ogni installazione esegue la versione 2.2 o successiva? Può anche dimostrare che i sistemi non attendibili non possono raggiungere interfacce privilegiate?
Queste due risposte definiscono l'esito nel breve termine. Un aggiornamento confermato chiude le falle documentate. Un accesso alla rete limitato e un'autenticazione testata riducono la probabilità che la prossima interfaccia trascurata diventi un incidente operativo.
