Il 4 agosto 2026 la Cybersecurity and Infrastructure Security Agency (CISA) ha aggiunto tre vulnerabilità al suo catalogo Known Exploited Vulnerabilities (KEV): una in N-able N-central, una in Apache Tomcat e una in IBM Langflow. Non è la solita infornata trimestrale di bug corretti in silenzio. Le tre falle sono già state usate in attacchi reali, e una di esse riguarda una piattaforma di gestione remota (RMM) che migliaia di Managed Service Provider in Europa, Italia inclusa, usano ogni giorno per amministrare le reti dei loro clienti. Quando un fornitore di RMM viene bucato, il rischio non resta confinato a un’azienda: si propaga a tutti i clienti che quel fornitore gestisce. È lo schema che nel 2021 aveva reso famoso il caso Kaseya, ed è lo schema che si sta ripetendo con N-able cinque anni dopo.
Cosa è successo il 4 agosto 2026: le tre CVE aggiunte al KEV
Nell’avviso pubblicato sul proprio sito, CISA ha elencato tre vulnerabilità con prove di sfruttamento attivo: CVE-2026-9198 (IBM Langflow, code injection, CVSS 9,8), CVE-2026-18556 (N-able N-central, bypass di autenticazione tramite percorso alternativo, CVSS 8,1) e CVE-2026-34486 (Apache Tomcat, mancata cifratura di dati sensibili, CVSS 7,5). Le tre falle appartengono a categorie molto diverse tra loro, dal codice generato da agenti AI alla gestione remota di endpoint fino ai server applicativi Java, ma condividono lo stesso destino: sono finite nel mirino di attaccanti prima ancora che molte organizzazioni avessero completato il patching.
La direttiva vincolante BOD 26-04 impone alle agenzie federali civili statunitensi (FCEB) di correggere le vulnerabilità del catalogo KEV entro scadenze fissate caso per caso. Diverse testate specializzate, tra cui BleepingComputer e Windows Forum, hanno riportato una finestra di appena tre giorni, con scadenza al 7 agosto 2026, per applicare le patch alle tre falle. CISA precisa che la direttiva vincola solo le agenzie federali americane, ma raccomanda a ogni organizzazione, pubblica o privata, di adottare lo stesso approccio basato sul rischio.
Il catalogo KEV: perché conta anche fuori dagli Stati Uniti
Il KEV Catalog nasce nel 2021 come strumento interno del governo statunitense, ma nel tempo è diventato un riferimento globale per la prioritizzazione delle patch. A differenza del punteggio CVSS, che misura la gravità teorica di una falla, il KEV elenca solo vulnerabilità già sfruttate concretamente. Per un team di sicurezza italiano o europeo questo significa una cosa semplice: se una CVE compare nel KEV, qualcuno la sta già usando per entrare nei sistemi, non è più un’ipotesi accademica.
Sul proprio sito, CISA descrive il catalogo come la fonte autorevole delle vulnerabilità sfruttate in ambiente reale, mantenuta “a beneficio della comunità della cybersicurezza e dei difensori delle reti, e per aiutare ogni organizzazione a gestire meglio le vulnerabilità e a tenere il passo con l’attività delle minacce”. Lo stesso ente raccomanda esplicitamente di usare il catalogo come input per il framework di prioritizzazione della gestione delle vulnerabilità, non come un elenco statico da consultare una volta al mese.
Anche il National Vulnerability Database gestito dal NIST rimanda alla stessa logica operativa. Come riportato sul portale NVD, “CISA raccomanda vivamente a tutte le organizzazioni di monitorare il catalogo KEV e di dare priorità alla remediation delle vulnerabilità elencate per ridurre la probabilità di compromissione da parte di attori delle minacce conosciuti”. In pratica, il KEV ha smesso da tempo di essere un problema solo statunitense: fa parte del vocabolario quotidiano di chi gestisce infrastrutture IT in Italia e nel resto d’Europa, come dimostrano anche i precedenti aggiornamenti del catalogo KEV di agosto 2026.
N-able N-central: dal bypass di autenticazione al controllo totale della console
N-central è la piattaforma RMM di punta di N-able, usata da migliaia di Managed Service Provider nel mondo per monitorare endpoint, distribuire patch, gestire backup e accedere da remoto ai dispositivi dei clienti. È esattamente il tipo di software che, se compromesso, dà a un attaccante le chiavi di centinaia di reti diverse con un solo salto.
Il 1° agosto 2026 N-able ha reso pubblico CVE-2026-18556, un bypass di autenticazione individuato dopo un’indagine partita da un aumento anomalo di segnalazioni relative a problemi di licenza sulla piattaforma. Il vendor aveva già rilasciato una prima correzione nella versione 2026.2, ma quella patch si è rivelata incompleta: da qui è nata CVE-2026-18577, la falla gemella che ha permesso agli attaccanti di continuare a bypassare l’autenticazione anche dopo il primo intervento. Secondo l’analisi tecnica pubblicata da Rapid7, CVE-2026-18577 ha un punteggio CVSS di 8,1 e consente a un attaccante remoto non autenticato di ottenere il controllo amministrativo completo della console N-central, sia nelle installazioni on-premise sia in quelle hosted.
N-able ha rilasciato un primo hotfix il 2 agosto e un secondo, più completo, il 6 agosto 2026, con la raccomandazione esplicita di aggiornare tutti i sistemi alla versione 2026.3.1.10. Il vendor ha confermato che lo sfruttamento attivo della falla era in corso almeno dal 1° agosto, quindi prima ancora della divulgazione pubblica: un dettaglio che riduce drasticamente il tempo utile che i difensori avrebbero avuto per reagire.
Cosa fanno gli attaccanti dopo aver preso il controllo di N-central
La parte più preoccupante dell’incidente non è il bypass in sé, ma quello che succede dopo. Secondo la ricostruzione pubblicata da Help Net Security, gli attaccanti che ottengono l’accesso amministrativo alla console usano la funzione integrata Take Control per raggiungere direttamente gli endpoint gestiti dai clienti dell’MSP compromesso. Da lì, registrano un servizio Windows che avvia un tunnel Cloudflare (cloudflared.exe), rinominato come MicrosoftEdgeUpdate64.exe o msmp.exe per confondersi con processi legittimi. Il tunnel garantisce agli attaccanti un canale di accesso persistente che sopravvive anche dopo che l’accesso diretto a N-central viene revocato.
Nulla indica che l’infrastruttura di Cloudflare sia stata compromessa: il servizio di tunneling viene semplicemente usato come strumento di occultamento, una tecnica sempre più comune perché il traffico verso domini Cloudflare raramente fa scattare allarmi nei firewall aziendali. Sugli endpoint colpiti sono stati osservati anche altri strumenti di accesso remoto legittimo installati per garantire ridondanza: AnyDesk, TacticalRMM (distribuito con lo script install_server.ps1 e il pacchetto tacticalagent-v2.11.0-windows-amd64.exe), TeamViewer, RustDesk, SimpleHelp e HopToDesk. È una tattica nota come “living off trusted software”: invece di introdurre malware personalizzato, facilmente rilevabile dagli antivirus, gli attaccanti riusano strumenti di amministrazione IT che già godono di whitelist e permessi ampi.
Apache Tomcat CVE-2026-34486: la crittografia che smetteva di funzionare
La seconda vulnerabilità del trio riguarda Apache Tomcat, il server applicativo Java più diffuso al mondo. CVE-2026-34486 colpisce il componente EncryptInterceptor, responsabile di cifrare le comunicazioni tra i nodi in un deployment Tomcat in cluster. Il bug nasce, paradossalmente, da un refactoring introdotto per correggere una vulnerabilità precedente, CVE-2026-29146: la modifica ha spostato la chiamata super.messageReceived(msg) fuori dal blocco try-catch che gestiva i fallimenti di decifratura, permettendo così a messaggi non cifrati di passare comunque alla catena di gestori invece di essere scartati. Il risultato è un’esecuzione di codice remoto non autenticata tramite deserializzazione Java, sfruttabile sulla porta 4000 nelle installazioni in cluster.
Le versioni interessate coprono un intervallo ampio: da 9.0.0.M1 a 9.0.116, da 10.1.0-M1 a 10.1.53 e da 11.0.0-M1 a 11.0.20. Le correzioni sono disponibili nelle release 9.0.117, 10.1.54 e 11.0.21. Trattandosi di un componente cluster, il rischio reale riguarda soprattutto ambienti enterprise e cloud che eseguono Tomcat in configurazioni ad alta disponibilità, uno scenario comune tra i provider cloud europei e i data center che ospitano applicazioni Java per la pubblica amministrazione.
Langflow CVE-2026-9198: quando la superficie d’attacco diventa l’intelligenza artificiale
La terza vulnerabilità segna un punto di svolta simbolico: è una delle prime volte in cui una piattaforma di orchestrazione per agenti AI finisce nel catalogo KEV con questa rilevanza. Langflow è un builder visuale open source per costruire flussi di lavoro basati su modelli linguistici, usato da team che sperimentano con agenti AI collegati a database, API esterne e chiavi di provider come OpenAI, Anthropic o Google. CVE-2026-9198 è una vulnerabilità di code injection non autenticata, con CVSS 9,8, che colpisce le versioni da 1.0.0 a 1.10.0 (corretta nella 1.10.1).
Il meccanismo di sfruttamento è quasi disarmante nella sua semplicità: nella configurazione di default, l’endpoint /api/v1/auto_login rilascia un token SUPERUSER a chiunque lo chiami dalla rete, senza richiedere credenziali. Con quel token in mano, l’attaccante chiama /api/v1/validate/code, un endpoint che esegue codice Python arbitrario tramite exec(). Da un endpoint pubblico a un’esecuzione di codice completa, in due chiamate HTTP. Poiché una tipica installazione Langflow custodisce chiavi API di più provider AI e credenziali verso sistemi a valle, la compromissione non è solo un problema del server Langflow, ma diventa un varco verso l’intera catena di strumenti collegati.
Perché la tripletta N-central, Tomcat e Langflow è un problema di supply chain
Le tre vulnerabilità non condividono codice, vendor o tecnologia, ma condividono una proprietà che le rende pericolose insieme: colpiscono tutte software infrastrutturale, cioè strumenti che stanno sopra molte altre organizzazioni. N-central gestisce reti di terzi. Tomcat esegue applicazioni di terzi. Langflow orchestra credenziali e API di terzi. Bucare uno di questi livelli non compromette un’azienda: compromette tutte le aziende che dipendono da quel livello, spesso senza saperlo.
È lo stesso principio dietro gli attacchi alla catena di fornitura software che negli ultimi anni hanno colpito ecosistemi come OAuth e i registri di pacchetti open source, casi già documentati anche in Italia con l’attacco supply chain a 700 aziende via token OAuth e con la violazione di 153 GB di credenziali tramite LiteLLM. In ciascuno di questi episodi, il punto di ingresso non è mai il bersaglio finale, ma uno strumento che il bersaglio usa e di cui si fida ciecamente.
| CVE | Prodotto | Tipo di vulnerabilità | CVSS | Versione corretta |
|---|---|---|---|---|
| CVE-2026-9198 | IBM Langflow OSS | Code injection non autenticata | 9,8 | 1.10.1 |
| CVE-2026-18556 | N-able N-central | Bypass di autenticazione | 8,1 | 2026.3.1.10 (hotfix 2) |
| CVE-2026-18577 | N-able N-central | Bypass autenticazione (patch incompleta della 18556) | 8,1 | 2026.3.1.10 (hotfix 2) |
| CVE-2026-34486 | Apache Tomcat | Mancata cifratura (bypass EncryptInterceptor) | 7,5 | 9.0.117 / 10.1.54 / 11.0.21 |
L’impatto sul mercato: la fiducia degli MSP e il titolo N-able
Per un vendor come N-able, quotato al NYSE con ticker NABL, un incidente di questo tipo tocca il cuore stesso del modello di business: gli MSP pagano per delegare la gestione della sicurezza dei loro clienti, e una falla che permette di aggirare quella sicurezza mina la proposta di valore dell’intera piattaforma. Il titolo N-able ha attraversato un periodo di forte pressione ad agosto 2026, scendendo fino a circa 3,21 dollari l’11 agosto rispetto a una chiusura precedente di 4,99 dollari, dentro un intervallo a 52 settimane compreso tra 2,92 e 8,74 dollari. È corretto precisare che il calo ha coinciso anche con notizie su una revisione al ribasso delle previsioni di ricavo e una riorganizzazione del personale, quindi non è possibile attribuire l’intero movimento del titolo alla sola vulnerabilità. Resta però il fatto che un incidente di sicurezza reso pubblico in questa fase difficilmente aiuta a rassicurare gli investitori o i clienti MSP che stanno valutando se rinnovare il contratto.
Per gli MSP italiani ed europei che usano N-central, il danno reputazionale indiretto è forse più rilevante del danno tecnico diretto. Un MSP che gestisce reti di PMI, studi professionali o enti locali deve ora spiegare ai propri clienti perché lo strumento con cui li protegge è stato per giorni una porta aperta. In un mercato dove la concorrenza tra piattaforme RMM (ConnectWise, Datto, Atera, Kaseya stessa) si gioca sempre di più sulla fiducia percepita in materia di sicurezza, ogni CVE ad alto impatto sposta clienti verso i competitor, indipendentemente da quanto rapida sia stata la risposta del vendor.
Contesto storico: da Kaseya 2021 a N-able 2026
Il paragone più immediato è con l’attacco a Kaseya VSA del luglio 2021, ancora oggi il caso di scuola per gli incidenti supply chain nel mondo RMM. In quell’occasione il gruppo ransomware REvil sfruttò una vulnerabilità zero-day (CVE-2021-30116) per colpire circa 60 MSP e, attraverso di loro, oltre 1.000 aziende clienti, cifrando quasi un milione di dispositivi secondo le stime riportate all’epoca e ripercorse anche su Wikipedia. REvil chiese un riscatto record da 70 milioni di dollari. Kaseya dichiarò di non averlo pagato e di aver ottenuto un decryptor universale da una “terza parte fidata”.
Cinque anni dopo, la dinamica tecnica del caso N-able è per certi versi meno grave, nel senso che finora N-able parla di un numero limitato di clienti compromessi e non risulta, al momento della pubblicazione di questo articolo, che sia stato distribuito ransomware su larga scala attraverso N-central. Ma la logica di fondo, un fornitore RMM come moltiplicatore di rischio per centinaia di reti a valle, è identica. La differenza principale è la velocità della risposta: N-able ha rilasciato due hotfix in cinque giorni, contro le settimane che servirono nel 2021 per stabilizzare completamente l’ecosistema Kaseya. Resta da vedere se questa rapidità basterà a evitare un effetto a catena.
L’Italia e l’Europa nel mirino: MSP, PMI e obblighi normativi
Il mercato italiano dei servizi IT gestiti si appoggia in larga parte su MSP di dimensioni medio-piccole che a loro volta servono PMI, studi professionali e, in alcuni casi, enti pubblici locali. Sono realtà che spesso non hanno un team di sicurezza dedicato e che si affidano quasi interamente agli strumenti forniti dal loro RMM per individuare e correggere le vulnerabilità. Quando lo strumento stesso diventa il vettore d’attacco, l’intera catena di difesa salta, un tema che torna spesso nella copertura di sicurezza informatica di questi mesi.
Con l’entrata in vigore della direttiva NIS2 e l’ampliamento del perimetro di aziende soggette a obblighi di gestione del rischio della catena di fornitura, un incidente come quello N-central diventa anche una questione di conformità, non solo di sicurezza operativa. Le organizzazioni che rientrano nel perimetro NIS2 e che si appoggiano a un MSP devono ora dimostrare di aver valutato anche il rischio introdotto dai fornitori dei loro fornitori, un livello di due diligence che fino a pochi anni fa quasi nessuno applicava in modo sistematico. Anche i team che già usano strumenti di monitoraggio automatico del catalogo KEV, come descritto nella guida su come integrare il feed CISA KEV in un SIEM con Python, si trovano ora a dover tracciare non solo le vulnerabilità dei propri sistemi, ma anche quelle del software usato dai fornitori a cui hanno delegato parte della gestione IT.
Cosa dicono le fonti ufficiali
Non essendo ancora emerse dichiarazioni pubbliche di singoli dirigenti su questo specifico incidente, vale la pena riportare come le fonti istituzionali descrivono il ruolo del catalogo KEV nella gestione di casi come questo. CISA definisce il catalogo come uno strumento pensato per la comunità della sicurezza, come si legge sulla pagina ufficiale del catalogo.
“Le organizzazioni dovrebbero usare il catalogo KEV come input per il proprio framework di prioritizzazione della gestione delle vulnerabilità.”
CISA, U.S. Cybersecurity and Infrastructure Security Agency — cisa.gov
Sulla stessa linea si muove il National Vulnerability Database del NIST, che nella propria pagina informativa scrive: “CISA raccomanda vivamente a tutte le organizzazioni di rivedere e monitorare il catalogo KEV e di dare priorità alla remediation delle vulnerabilità elencate per ridurre la probabilità di compromissione da parte di attori delle minacce conosciuti”, come riportato su nvd.nist.gov.
Anche fuori dal perimetro governativo, chi si occupa di gestione delle vulnerabilità sottolinea lo stesso punto operativo. Secondo l’azienda di sicurezza del software FOSSA, “il catalogo KEV, abbreviazione di Known Exploited Vulnerabilities Catalog, è mantenuto da CISA (l’agenzia governativa statunitense per la cybersicurezza e la sicurezza delle infrastrutture) ed è usato come un input prezioso per la prioritizzazione delle vulnerabilità”, come spiegato nel blog ufficiale di FOSSA. La stessa fonte aggiunge che il catalogo “fornisce un elenco centralizzato di vulnerabilità sfruttate attivamente, aiutando le agenzie federali e gli enti del settore privato a dare priorità agli interventi di remediation per mitigare tempestivamente le minacce più critiche”.
Come verificare se i propri sistemi sono esposti
Per un team IT che vuole controllare rapidamente se una delle tre CVE compare tra le vulnerabilità note sfruttate, CISA pubblica il catalogo anche in formato JSON, interrogabile via script senza bisogno di consultare manualmente il sito. Un controllo minimo si può fare così:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
| python3 -c "
import json, sys
data = json.load(sys.stdin)
target = {'CVE-2026-9198', 'CVE-2026-18556', 'CVE-2026-18577', 'CVE-2026-34486'}
for v in data['vulnerabilities']:
if v['cveID'] in target:
print(v['cveID'], '-', v['vulnerabilityName'])
"Per chi usa N-central, il primo passo pratico resta comunque verificare la versione in esecuzione confrontandola con la 2026.3.1.10 e, se necessario, applicare l’hotfix in via prioritaria prima di qualsiasi altra attività di manutenzione pianificata.
Confronto con gli altri incidenti KEV recenti
Agosto 2026 non è stato un mese isolato per il catalogo KEV. Nelle settimane precedenti CISA aveva già aggiunto altre vulnerabilità critiche, e nelle settimane successive il ritmo non ha rallentato, un segnale che lo sfruttamento attivo di software ampiamente diffuso è diventato la normalità più che l’eccezione. La tabella seguente mette a confronto la tripletta di agosto con altri episodi recenti del catalogo per dare un’idea della cadenza con cui questi eventi si susseguono.
| Periodo 2026 | Prodotto colpito | N. CVE aggiunte | Categoria di rischio principale |
|---|---|---|---|
| 4 agosto | N-able N-central, Apache Tomcat, IBM Langflow | 3 | RMM supply chain, AI orchestration, server applicativi |
| 11 agosto | Cisco Secure Firewall ASA/FTD, Microsoft Windows, Metabase | 3 | Firewall perimetrali, sistemi operativi, business intelligence |
| 21 luglio | Adobe, Joomla, Langflow (CVE precedente) | 4 | CMS e piattaforme AI |
| 26 agosto | Diversi prodotti enterprise | 6 | Vulnerabilità enterprise miste |
Il quadro che emerge conferma una tendenza già osservata in altri report italiani sul tema, come quello dedicato alle falle del catalogo KEV con oltre 15 anni di età: gli attaccanti non si limitano più a colpire solo software nuovo o di nicchia, ma tornano sistematicamente a caccia di codice legacy e di componenti infrastrutturali maturi, spesso dati per scontati proprio perché in funzione da anni.
Previsioni: cosa aspettarsi nei prossimi mesi
Sulla base della cronologia dell’incidente e dei pattern osservati in casi simili, si possono delineare alcuni scenari plausibili per l’autunno 2026.
- È probabile che emergano nuove varianti o bypass parziali degli hotfix N-able, sulla falsariga di quanto già successo tra CVE-2026-18556 e CVE-2026-18577: le patch rilasciate sotto pressione temporale hanno statisticamente più probabilità di lasciare margini di sfruttamento residui.
- Gli MSP europei accelereranno probabilmente l’adozione di autenticazione a più fattori obbligatoria sulle console RMM e di segmentazione di rete tra la piattaforma di gestione e gli endpoint dei clienti, una misura che oggi resta opzionale in molte configurazioni.
- È ragionevole attendersi un aumento delle richieste assicurative e contrattuali da parte dei clienti di MSP italiani, con clausole specifiche sulla gestione delle vulnerabilità del software RMM stesso, non solo degli endpoint gestiti.
- Con l’inclusione di Langflow nel KEV, altre piattaforme di orchestrazione AI (framework di agenti, tool di automazione basati su LLM) finiranno probabilmente sotto scrutinio più stretto da parte dei ricercatori di sicurezza nei prossimi mesi, essendo un’area relativamente giovane e poco irrobustita.
- È verosimile che l’ACN e le autorità europee competenti in materia NIS2 pubblichino indicazioni più specifiche sulla valutazione del rischio dei fornitori RMM entro la fine del 2026, dato il crescente peso di questi strumenti nella catena di fornitura digitale.
Checklist pratica per MSP e team IT
Per chi gestisce o si affida a una piattaforma RMM, alcune azioni concrete riducono l’esposizione anche in assenza di un incidente confermato nel proprio ambiente.
- Aggiornare N-central alla versione 2026.3.1.10 o successiva e verificare i log di accesso amministrativo per il periodo dal 1° al 6 agosto 2026.
- Controllare la presenza di processi cloudflared.exe rinominati come MicrosoftEdgeUpdate64.exe o msmp.exe sugli endpoint gestiti.
- Verificare installazioni non autorizzate di AnyDesk, TacticalRMM, TeamViewer, RustDesk, SimpleHelp o HopToDesk sugli host critici.
- Per chi esegue Apache Tomcat in cluster, aggiornare alle versioni 9.0.117, 10.1.54 o 11.0.21 e verificare l’esposizione della porta 4000.
- Per chi usa Langflow, aggiornare alla versione 1.10.1 e disabilitare l’auto-login se non strettamente necessario in produzione.
- Integrare il feed JSON del catalogo KEV in un processo automatico di controllo, così da ridurre il tempo tra pubblicazione della CVE e verifica interna.
Domande frequenti
Cos’è il catalogo CISA KEV?
È l’elenco ufficiale mantenuto da CISA delle vulnerabilità già sfruttate attivamente in attacchi reali, a differenza di un semplice database di CVE teoriche. Viene usato come riferimento per stabilire le priorità di patching, sia dalle agenzie federali statunitensi sia, su base volontaria, da organizzazioni private in tutto il mondo.
N-able N-central è sicuro da usare oggi?
Sì, a condizione che sia stato aggiornato alla versione 2026.3.1.10 o successiva, che include il secondo hotfix rilasciato da N-able il 6 agosto 2026. Le installazioni non aggiornate restano potenzialmente esposte al bypass di autenticazione descritto in CVE-2026-18556 e CVE-2026-18577.
Quali dati sono stati esposti nell’incidente N-central?
N-able ha dichiarato che il numero di clienti compromessi è limitato, senza fornire una cifra precisa. Gli attaccanti che hanno sfruttato la falla hanno ottenuto accesso amministrativo alla console e, da lì, potenzialmente agli endpoint dei clienti gestiti tramite la funzione Take Control.
Cosa rende diversa CVE-2026-34486 su Apache Tomcat dalle altre falle Tomcat del passato?
È nata da un errore introdotto durante la correzione di una vulnerabilità precedente (CVE-2026-29146), non da un bug originario. Il refactoring ha spostato una chiamata di codice fuori dal blocco che gestiva i fallimenti di decifratura, riaprendo di fatto un problema che si credeva già risolto.
Perché una vulnerabilità in Langflow è considerata così grave?
Perché con un CVSS di 9,8 permette esecuzione di codice remoto senza autenticazione, e perché una tipica installazione Langflow custodisce chiavi API di più provider di intelligenza artificiale e credenziali verso sistemi collegati. Compromettere il server significa spesso compromettere anche tutto ciò a cui quel server è connesso.
Le aziende italiane sono obbligate a segnalare questo tipo di incidenti?
Le organizzazioni che rientrano nel perimetro della direttiva NIS2 hanno obblighi di notifica in caso di incidenti significativi, e devono anche valutare il rischio introdotto dai fornitori terzi, incluse le piattaforme RMM usate dai propri MSP. Le PMI che non rientrano nel perimetro NIS2 non hanno obblighi di notifica diretti, ma restano comunque esposte al rischio operativo.
Come si confronta questo incidente con l’attacco a Kaseya del 2021?
Kaseya coinvolse circa 60 MSP e oltre 1.000 aziende clienti, con distribuzione su larga scala di ransomware REvil. L’incidente N-able, al momento della pubblicazione di questo articolo, riguarda un numero di clienti definito limitato dal vendor stesso, senza conferme di distribuzione massiva di ransomware. La dinamica di fondo, però, resta la stessa: una piattaforma RMM come moltiplicatore di rischio per centinaia di reti a valle.
