Il 6 settembre 2026, alle prime ore del mattino (UTC), N-able ha rilasciato la quarta hotfix di emergenza in cinque settimane per N-central, la sua piattaforma di remote monitoring and management (RMM) usata da migliaia di managed service provider in tutto il mondo. Questa volta il problema non è di secondo piano: CVE-2026-86218 ha ottenuto il punteggio massimo, CVSS 10.0, ed è una vulnerabilità di code injection statica (CWE-96) che permette l’esecuzione di codice remoto senza bisogno di autenticazione. È la terza falla critica in N-central in sei settimane, e la Cybersecurity and Infrastructure Security Agency (CISA) l’ha inserita nel catalogo delle vulnerabilità sfruttate attivamente (KEV) l’8 settembre 2026, imponendo alle agenzie federali statunitensi una scadenza di rimedio fissata all’11 settembre.
Per chi si occupa di sicurezza informatica in Italia ed Europa, la notizia non è un dettaglio tecnico isolato. N-central è uno dei pilastri dell’infrastruttura IT gestita da centinaia di MSP europei, ognuno dei quali amministra decine o centinaia di reti clienti attraverso un’unica console centralizzata. Quando quella console cade, non cade un’azienda: cadono tutte le aziende a valle. È lo schema che ha reso famosi gli attacchi a Kaseya nel 2021 e che nel 2026 si ripresenta, con numeri diversi ma la stessa logica di fondo.
Cos’è CVE-2026-86218 e perché è diversa dalle falle precedenti
CVE-2026-86218 è stata classificata da N-able stessa, in qualità di CVE Numbering Authority, come vulnerabilità di tipo static code injection (CWE-96) capace di produrre esecuzione di codice remoto pre-autenticazione. In pratica, un aggressore non ha bisogno di credenziali valide: basta inviare richieste HTTP appositamente costruite a un’istanza N-central esposta su internet perché il server esegua codice arbitrario con i privilegi del servizio N-central stesso.
Il dettaglio che cambia le carte in tavola è il salto di gravità rispetto alle due vulnerabilità scoperte ad agosto. Quelle, tracciate come CVE-2026-18556 (CVSS 7.4) e CVE-2026-18577, erano bypass di autenticazione: permettevano cioè di aggirare il login, ma un aggressore doveva comunque muoversi dentro l’applicazione per ottenere un impatto significativo. CVE-2026-86218 elimina questo passaggio intermedio. Non c’è login da aggirare, perché non serve autenticarsi affatto.
N-able ha corretto il difetto con N-central 2026.3 Hotfix 4, portato al build 2026.3.1.14. La società ha precisato che le istanze hosted (N-central Cloud, NCOD) sono state già patchate automaticamente e non richiedono azione da parte dei clienti. Chi gestisce un’installazione on-premise, invece, deve aggiornare manualmente, e N-able ha specificato che anche chi aveva già applicato la Hotfix 3 il giorno prima deve comunque installare la Hotfix 4 per essere protetto.
La cronologia: tre CVE e quattro hotfix in sei settimane
Per capire la portata del problema serve guardare la sequenza temporale nel suo complesso. Il 3 agosto 2026 CISA ha aggiunto al catalogo KEV le due vulnerabilità di bypass di autenticazione CVE-2026-18556 e CVE-2026-18577, dopo che erano state osservate sfruttate attivamente. Il 5 e 6 settembre, a distanza di un solo giorno, N-able ha rilasciato prima la Hotfix 3 e poi, appena scoperto un problema più grave, la Hotfix 4 che corregge CVE-2026-86218.
Il ricercatore che ha segnalato la falla lo ha fatto tramite il programma di disclosure responsabile di N-able, secondo quanto riportato dall’azienda nelle sue note di rilascio. Huntress, la società di threat detection specializzata proprio nella protezione degli MSP, ha definito CVE-2026-86218 la “terza ondata di attacco in sei settimane” contro la stessa piattaforma, sottolineando come gli aggressori abbiano probabilmente iniziato a testare sistematicamente ogni componente esposto di N-central dopo la prima disclosure di agosto.
Questo pattern, tre falle critiche nello stesso prodotto in un intervallo così breve, non è casuale. Quando una piattaforma finisce sotto i riflettori della comunità di ricerca sulla sicurezza dopo una prima disclosure pubblica, diventa automaticamente un bersaglio più attraente: i ricercatori (e gli aggressori) sanno che se è stata trovata una falla, probabilmente ce ne sono altre nello stesso codice.
Sfruttamento attivo: cosa dicono N-able, Huntress e CISA
Sulle prove di sfruttamento attivo le fonti non sono perfettamente allineate, ed è un dettaglio che vale la pena riportare con precisione. N-able, nelle proprie note di rilascio, ha dichiarato di non avere conferme che la vulnerabilità sia stata sfruttata in ambienti di produzione, pur avvertendo che i sistemi non aggiornati restano a rischio. Huntress, dal canto suo, ha riportato di aver osservato attività di sfruttamento in tutte e tre le ondate di vulnerabilità N-central emerse dal 3 agosto in poi, e ha raccomandato agli amministratori di dare per scontata l’esposizione, isolare i server N-central raggiungibili da internet, verificare gli account amministrativi e monitorare traffico anomalo.
CISA ha risolto l’ambiguità nel modo più diretto possibile: inserendo CVE-2026-86218 nel catalogo KEV l’8 settembre 2026, l’agenzia ha di fatto certificato che esistono prove di sfruttamento in ambienti reali, requisito indispensabile per l’ingresso in quel catalogo. Per le agenzie federali civili statunitensi (FCEB), la scadenza per applicare la patch è stata fissata all’11 settembre 2026, una finestra di appena tre giorni che riflette la gravità percepita della minaccia.
Sul fronte dell’attribuzione, al momento nessuna fonte pubblica ha collegato lo sfruttamento di CVE-2026-86218 a un gruppo ransomware o a un attore APT specifico con nome noto. Gli attacchi osservati vengono descritti genericamente come provenienti da “attori non autenticati” che colpiscono istanze esposte su internet, un dettaglio che non deve rassicurare: l’assenza di attribuzione spesso significa solo che l’attività è troppo recente o troppo dispersa per essere già stata ricondotta a un gruppo organizzato.
Numero di istanze esposte: la superficie d’attacco reale
Secondo l’analisi di F5 Labs pubblicata nel bollettino settimanale sulle minacce del 9 settembre 2026, circa 1.500 istanze N-central risultano attualmente raggiungibili da internet, concentrate soprattutto negli Stati Uniti e in Europa. È una cifra che va letta con cautela: rappresenta la superficie d’attacco visibile via scansione, non il numero totale di installazioni N-central nel mondo, che è certamente molto più alto se si contano anche le istanze protette dietro VPN o reti segmentate.
Nessuna fonte pubblica ha fornito, al momento della stesura di questo articolo, un numero preciso di clienti coinvolti né una ripartizione per singolo paese europeo, Italia inclusa. Questo silenzio statistico è comune nelle prime fasi di una disclosure di questo tipo: le cifre più affidabili emergono di solito nelle settimane successive, quando le società di threat intelligence completano le scansioni e le aziende colpite iniziano, se lo fanno, a comunicare pubblicamente l’impatto subito.
Quello che è certo è l’ambito delle versioni vulnerabili: ogni installazione on-premise di N-central con build precedente alla 2026.3.1.14 è considerata a rischio, indipendentemente dalla configurazione di rete, se raggiungibile da un aggressore capace di instradare traffico verso la porta di gestione.
Perché gli strumenti RMM sono bersagli così attraenti
Per capire perché una singola vulnerabilità in un prodotto RMM faccia notizia in modo sproporzionato rispetto, per esempio, a una falla in un singolo server web aziendale, bisogna guardare al modello operativo degli MSP. Una piattaforma come N-central è progettata per dare a un piccolo team IT il controllo centralizzato su decine, a volte centinaia, di reti clienti diverse: patch management, deployment di script, accesso remoto, gestione degli endpoint. È un moltiplicatore di efficienza per l’MSP, ma anche un moltiplicatore di danno per chiunque riesca a comprometterlo.
Compromettere il server N-central di un singolo MSP significa, in linea teorica, ottenere un punto di lancio verso ogni cliente gestito da quell’MSP. È esattamente lo schema che ha reso l’attacco a Kaseya VSA del 2021 uno dei più devastanti nella storia del ransomware, con oltre 1.000 aziende colpite in una singola ondata attraverso un’unica catena di compromissione. Il paragone non è casuale: gli analisti di sicurezza continuano a citare Kaseya come il caso di scuola che ha trasformato gli strumenti RMM in bersagli prioritari per i gruppi ransomware, proprio per il rapporto tra sforzo di compromissione e superficie di danno ottenibile.
Il confronto con lo storico degli attacchi alla supply chain IT
N-central non è la prima piattaforma di gestione IT a finire sotto attacco nel 2026. Nello stesso periodo, la community della sicurezza ha seguito da vicino anche la vicenda di JetBrains TeamCity, colpita da una RCE critica (CVSS 9,8) sfruttabile in contesti di supply chain del software, e la falla in JFrog Artifactory, anch’essa con CVSS 9,8, che ha esposto migliaia di repository aziendali a un bypass di autenticazione. Il filo conduttore tra questi tre casi è lo stesso: strumenti infrastrutturali con privilegi elevati su molte organizzazioni contemporaneamente, dove una singola vulnerabilità genera un effetto a cascata sproporzionato rispetto al singolo bug corretto.
Confronto tecnico: le tre vulnerabilità N-central del 2026
Mettere le tre falle a confronto aiuta a capire la traiettoria di gravità crescente che ha caratterizzato N-central quest’estate. La tabella seguente riassume i dati pubblicamente disponibili su ciascuna vulnerabilità.
| CVE | Tipo | CVSS | Autenticazione richiesta | Data ingresso KEV |
|---|---|---|---|---|
| CVE-2026-18556 | Bypass di autenticazione | 7.4 | No (per il bypass stesso) | 3 agosto 2026 |
| CVE-2026-18577 | Bypass di autenticazione / privilegi | Alta (non sempre quotata) | No | 3 agosto 2026 |
| CVE-2026-86218 | Static code injection (CWE-96) → RCE pre-auth | 10.0 | No | 8 settembre 2026 |
Il salto da 7.4 a 10.0 non è solo un numero più alto su una scala astratta: riflette il passaggio da “un aggressore può entrare senza credenziali valide” a “un aggressore può eseguire qualsiasi comando sul server, senza nemmeno provare a entrare”. Per chi gestisce la threat intelligence in un’azienda italiana con MSP terzi in outsourcing, questo genere di progressione dovrebbe automaticamente far scattare una verifica: quale piattaforma RMM usa il nostro fornitore, e con quale tempistica applica le patch critiche?
Il precedente diretto: i tre CVE di agosto e il catalogo CISA KEV
Prima di CVE-2026-86218, N-central era già finita sotto i riflettori di CISA con un altro gruppo di vulnerabilità che coinvolgeva, oltre a N-central stesso, anche componenti Apache Tomcat e Langflow integrati nella piattaforma. In quel caso, la gravità massima registrata tra le tre falle era CVSS 9,8, ancora inferiore rispetto al 10.0 pieno del caso di settembre. È un dettaglio che conferma quanto sia diventato frequente, nel 2026, l’inserimento di aggiornamenti multipli per lo stesso prodotto nell’arco di poche settimane, un ritmo di disclosure che mette sotto pressione i team di patch management degli MSP molto più che in passato.
Il catalogo KEV di CISA, più in generale, ha continuato a crescere a ritmo sostenuto in tutto il 2026: gli aggiornamenti di agosto includevano da soli 16 nuove vulnerabilità aggiunte in tre settimane, quattro delle quali classificate come critiche. Il trend riflette sia un aumento reale delle vulnerabilità sfruttate attivamente sia una maggiore capacità dell’agenzia di rilevarle e catalogarle in tempi rapidi rispetto agli anni precedenti.
Impatto di mercato: cosa significa per N-able e per il settore RMM
Dal punto di vista del business, tre vulnerabilità critiche nello stesso prodotto in sei settimane rappresentano un costo reputazionale difficile da ignorare per N-able, uno dei principali fornitori di software RMM per MSP a livello globale, insieme a nomi come ConnectWise, Datto (ora parte di Kaseya) e Atera. Il mercato RMM europeo, in particolare, ha visto una crescita costante negli ultimi anni proprio perché sempre più piccole e medie imprese italiane scelgono di esternalizzare la gestione IT a MSP locali invece di mantenere team interni, e ogni MSP a sua volta si appoggia a una manciata di piattaforme di gestione centralizzata.
Una sequenza di disclosure così ravvicinata mette sotto pressione N-able su due fronti contemporaneamente. Da un lato c’è la fiducia dei clienti diretti, gli MSP, che devono giustificare ai propri clienti finali perché uno strumento critico per la sicurezza della loro rete abbia richiesto quattro hotfix di emergenza in poco più di un mese. Dall’altro c’è la pressione regolatoria: con la direttiva NIS2 ormai pienamente operativa in Italia e la crescente attenzione dell’ACN verso la resilienza della catena di fornitura IT, un MSP che si affida a una piattaforma con un simile storico di vulnerabilità critiche rischia di finire sotto osservazione anche per obblighi di due diligence sui fornitori terzi.
Va detto, a favore di N-able, che l’azienda ha reagito con rapidità: quattro hotfix in cinque settimane indicano un processo di patch management interno capace di muoversi velocemente una volta ricevuta una segnalazione, e la scelta di patchare automaticamente le istanze hosted riduce il rischio residuo per una parte consistente della base clienti. Il problema resta concentrato sulle installazioni on-premise, dove la responsabilità dell’aggiornamento ricade interamente sul singolo MSP.
Panorama competitivo: come si posizionano gli altri strumenti RMM
Nessuna piattaforma RMM può dirsi immune da vulnerabilità critiche: il settore nel suo complesso ha vissuto anni difficili, a partire proprio dal caso Kaseya VSA del 2021. Quello che cambia da fornitore a fornitore è la velocità di risposta e la trasparenza nella comunicazione. La tabella seguente confronta, sulla base delle informazioni pubblicamente disponibili, il posizionamento generale dei principali attori del mercato RMM rispetto alla gestione delle vulnerabilità critiche nel 2026.
| Piattaforma RMM | Modello di distribuzione | CVE critiche note nel 2026 | Patch automatica su hosted |
|---|---|---|---|
| N-able N-central | On-premise e hosted (NCOD) | 3 (CVSS fino a 10.0) | Sì |
| ConnectWise Automate/RMM | Prevalentemente cloud | Storico di disclosure minore nel 2026 | Sì |
| Kaseya VSA / Datto RMM | On-premise e cloud | Storico noto dal 2021, monitoraggio rafforzato | Parziale |
| Atera | Cloud nativo | Nessuna disclosure critica rilevante nel periodo | Sì (by design) |
Il dato che emerge con più chiarezza è strutturale, non specifico di un singolo fornitore: le piattaforme nate come cloud-native tendono ad avere una superficie d’attacco più piccola e un ciclo di patching più rapido, semplicemente perché non esistono installazioni on-premise da aggiornare manualmente. Per gli MSP italiani che valutano un cambio di piattaforma o una nuova adozione, questo fattore dovrebbe pesare quanto il costo della licenza nella decisione finale.
Contesto storico: da Kaseya 2021 a N-central 2026
Il precedente più citato quando si parla di vulnerabilità RMM resta l’attacco alla supply chain di Kaseya VSA del luglio 2021, orchestrato dal gruppo ransomware REvil, che sfruttò una catena di vulnerabilità zero-day per colpire contemporaneamente oltre 1.000 aziende attraverso circa 60 MSP clienti di Kaseya. Quell’episodio ha cambiato in modo permanente la percezione del rischio associato agli strumenti di gestione centralizzata: da allora, ogni disclosure critica in un prodotto RMM viene valutata non solo per l’impatto sul singolo fornitore, ma per l’effetto moltiplicatore sulla sua intera base di clienti downstream.
Cinque anni dopo, il settore ha fatto passi avanti significativi sul fronte della velocità di risposta, come dimostra la reattività di N-able in questo episodio, ma la superficie d’attacco strutturale resta la stessa: un singolo punto di gestione con privilegi su molte reti diverse continuerà a essere un bersaglio prioritario finché il modello operativo degli MSP rimarrà centralizzato. Il report Fortinet 2026 sulle minacce globali ha del resto già segnalato una crescita del 389% negli attacchi ransomware rispetto all’anno precedente, con gli strumenti di gestione remota indicati tra i vettori di accesso iniziale in costante aumento.
Cosa devono fare ora gli MSP e i loro clienti
Per gli amministratori che gestiscono N-central
Per gli amministratori che gestiscono un’istanza N-central on-premise, la sequenza di azioni raccomandata da Huntress e ripresa da N-able è chiara e va eseguita nell’ordine seguente: verificare immediatamente la versione installata, aggiornare a Hotfix 4 (build 2026.3.1.14) anche se si è già passati alla Hotfix 3, isolare temporaneamente dall’accesso internet diretto qualunque istanza non ancora aggiornata, controllare i log per individuare richieste HTTP anomale verso gli endpoint di gestione, e infine effettuare un audit degli account amministrativi per escludere la presenza di accessi non autorizzati creati durante la finestra di esposizione.
Un semplice controllo della versione via riga di comando, sul lato client dell’endpoint N-central agent, può aiutare a identificare rapidamente i sistemi ancora vulnerabili prima di procedere con l’aggiornamento centralizzato.
curl -s -o /dev/null -w "%{http_code}\n" https://YOUR-NCENTRAL-SERVER/dms2/services/ServerEI2?wsdl
# Verificare poi la build da console: Amministrazione > Info sistema > Versione N-central
# Build sicura: 2026.3.1.14 o successiva (Hotfix 4)Per le aziende clienti di un MSP
Per le aziende clienti finali che si affidano a un MSP terzo, la raccomandazione pratica è chiedere esplicitamente al proprio fornitore conferma scritta dell’applicazione della patch, in linea con gli obblighi di due diligence sulla catena di fornitura previsti dalla direttiva NIS2. Non è un esercizio burocratico: in caso di incidente, la capacità di dimostrare di aver verificato la postura di sicurezza dei fornitori critici può fare la differenza in sede di valutazione delle responsabilità.
Previsioni: dove va questa storia nelle prossime settimane
Alcune previsioni ragionevoli, basate sui pattern osservati in casi simili degli ultimi anni, possono aiutare a orientare le priorità dei team di sicurezza nelle prossime settimane.
- Nuove disclosure in arrivo. La sequenza di tre CVE critiche in sei settimane suggerisce che ricercatori indipendenti stiano continuando a sottoporre a stress test l’intera base di codice di N-central: è plausibile attendersi almeno un’altra segnalazione significativa entro fine 2026.
- Attribuzione a un gruppo ransomware. Se lo sfruttamento attivo confermato da Huntress si tradurrà in incidenti concreti, è probabile che nelle prossime settimane emerga l’attribuzione a un gruppo organizzato, sul modello di quanto già accaduto con altre falle RMM sfruttate su larga scala.
- Pressione regolatoria sugli MSP europei. Con NIS2 pienamente in vigore, ci si può attendere un aumento delle richieste di audit da parte dell’ACN e delle autorità nazionali equivalenti verso gli MSP che gestiscono infrastrutture critiche o pubbliche amministrazioni.
- Consolidamento verso piattaforme cloud-native. Il divario di esposizione tra installazioni on-premise e hosted probabilmente accelererà la migrazione di alcuni MSP verso modelli RMM interamente cloud, dove il fornitore si assume la responsabilità del patching.
- Maggiore adozione di segmentazione di rete. È probabile che un numero crescente di MSP inizi a isolare le console di gestione dietro VPN dedicate o zero-trust network access, riducendo drasticamente il numero di istanze scansionabili da internet, oggi stimato attorno alle 1.500 unità.
Il ruolo della disclosure responsabile nel ciclo di vita delle vulnerabilità
Un aspetto spesso sottovalutato in questa vicenda è il ruolo giocato dal programma di disclosure responsabile di N-able, attraverso il quale è arrivata la segnalazione che ha portato alla scoperta di CVE-2026-86218. Programmi di questo tipo, quando funzionano bene, permettono ai fornitori di correggere le vulnerabilità prima che vengano rese pubbliche o sfruttate su larga scala. Il tempo di reazione di N-able, dalla segnalazione al rilascio della Hotfix 4, è stato di pochi giorni, un ritmo che si allinea alle best practice raccomandate dal settore per le vulnerabilità di gravità massima.
Resta però un nodo strutturale che la sola velocità di risposta non risolve: finché esisteranno installazioni on-premise che richiedono un intervento manuale dell’amministratore, ci sarà sempre una finestra di esposizione tra il rilascio della patch e la sua effettiva applicazione. È in quella finestra, tipicamente di giorni o settimane, che si concentra la maggior parte dei tentativi di sfruttamento opportunistico osservati dai ricercatori.
Implicazioni per il mercato italiano della cybersecurity gestita
In Italia il ricorso a MSP per la gestione della sicurezza IT è cresciuto in modo costante negli ultimi anni, trainato soprattutto dalle piccole e medie imprese che non dispongono di team interni dedicati. Questo rende il paese particolarmente sensibile a episodi come quello di N-central: un singolo MSP compromesso può propagare il danno su decine di PMI clienti, spesso senza che queste ultime abbiano piena visibilità sugli strumenti usati dal proprio fornitore per gestirle da remoto.
Il tema si collega direttamente al più ampio dibattito sulla resilienza della supply chain digitale che ha caratterizzato il 2026 in Europa, con episodi analoghi che hanno coinvolto piattaforme di sviluppo come TeamCity e JFrog Artifactory. La lezione comune a tutti questi casi è che la sicurezza di un’organizzazione oggi dipende in modo crescente dalla sicurezza degli strumenti usati dai suoi fornitori, un fattore che le valutazioni di rischio tradizionali, centrate sul perimetro interno, spesso continuano a sottovalutare. Per restare aggiornati su nuove CVE, campagne ransomware e violazioni di dati che riguardano l’Europa, la sezione sicurezza di shattered.io raccoglie la copertura quotidiana di questi temi.
Fonti e riferimenti tecnici
Per chi vuole approfondire i dettagli tecnici di CVE-2026-86218, la scheda ufficiale è consultabile sul National Vulnerability Database del NIST e su Tenable. La cronaca della disclosure e della quarta hotfix è stata seguita in dettaglio da The Hacker News, mentre l’analisi tecnica sullo sfruttamento attivo è pubblicata sul blog di Huntress. I dati sulla superficie d’attacco esposta provengono dal bollettino settimanale di F5 Labs, mentre la cronologia della prima ondata di CVE di agosto è documentata da The Hacker News nella sua copertura dell’aggiornamento del catalogo CISA KEV.
Domande frequenti
Cos’è esattamente CVE-2026-86218?
È una vulnerabilità di static code injection (CWE-96) in N-able N-central che consente l’esecuzione di codice remoto senza necessità di autenticazione. Ha ricevuto il punteggio CVSS massimo, 10.0, ed è stata corretta con la Hotfix 4 (build 2026.3.1.14) rilasciata il 5-6 settembre 2026.
La mia azienda usa N-central: sono a rischio?
Se la tua organizzazione si affida a un MSP che utilizza N-central on-premise con una build precedente alla 2026.3.1.14, e quell’istanza è raggiungibile da internet, il rischio è concreto. Le istanze hosted (NCOD) sono state patchate automaticamente da N-able e non richiedono azione da parte del cliente finale.
La vulnerabilità è stata sfruttata attivamente?
N-able dichiara di non avere conferme di sfruttamento in ambienti di produzione, ma Huntress ha riportato attività di sfruttamento osservata in tutte le ondate di vulnerabilità N-central emerse da agosto 2026. CISA ha inserito la falla nel catalogo KEV l’8 settembre 2026, un passaggio che richiede prove di sfruttamento attivo documentato.
Quali sono le altre due vulnerabilità N-central del 2026?
Sono CVE-2026-18556 (CVSS 7.4) e CVE-2026-18577, entrambe bypass di autenticazione aggiunte al catalogo KEV di CISA il 3 agosto 2026. Riguardavano, insieme ad altre falle nella stessa ondata, anche componenti Apache Tomcat e Langflow integrati nella piattaforma.
Come posso verificare se la mia istanza N-central è aggiornata?
Dalla console di amministrazione, sotto Amministrazione > Informazioni di sistema, è possibile verificare il numero di build installato. Qualsiasi versione precedente alla 2026.3.1.14 va considerata vulnerabile e va aggiornata immediatamente.
Cosa deve fare un’azienda italiana che si affida a un MSP con N-central?
La raccomandazione pratica è richiedere al proprio fornitore conferma scritta dell’applicazione della Hotfix 4, in linea con gli obblighi di due diligence sulla catena di fornitura previsti dalla direttiva NIS2, ormai pienamente operativa per le organizzazioni italiane rientranti nel suo perimetro.
Quante istanze N-central sono esposte su internet?
Secondo l’analisi di F5 Labs del 9 settembre 2026, circa 1.500 istanze risultano raggiungibili pubblicamente, concentrate soprattutto tra Stati Uniti ed Europa. Non esistono al momento cifre pubbliche disaggregate per singolo paese, Italia inclusa.
Chi ha scoperto la vulnerabilità?
Secondo N-able, la falla è stata segnalata attraverso il programma di disclosure responsabile dell’azienda da un ricercatore terzo, il cui nome non è stato reso pubblico nelle comunicazioni ufficiali disponibili al momento della stesura di questo articolo.
