Il 5 settembre 2026 N-able ha rilasciato Hotfix 4 per N-central 2026.3, portando la build alla versione 2026.3.1.14. Correggeva CVE-2026-86218, descritta dal vendor come una vulnerabilità di gravità critica che consente esecuzione di codice remoto senza autenticazione sul server N-central. È la terza volta in poco più di un mese che gli amministratori della piattaforma RMM di N-able devono applicare una correzione d'emergenza, dopo le due CVE finite nel catalogo KEV di CISA a inizio agosto e di cui avevamo scritto.

Il fatto nuovo non è solo la vulnerabilità. È il modo in cui è stata comunicata.

I fatti

N-central è una piattaforma di remote monitoring and management: il cruscotto da cui un Managed Service Provider inventaria, monitora, aggiorna e amministra da remoto i sistemi di tutti i suoi clienti. Chi controlla il server N-central controlla, per costruzione, gli agenti installati sugli endpoint gestiti.

Nelle note di rilascio pubbliche N-able ha scritto che la falla è stata segnalata responsabilmente da terze parti attraverso il programma di disclosure e che «al momento non abbiamo conferme che questa vulnerabilità sia stata sfruttata in ambienti di produzione», pur avvertendo che i sistemi non aggiornati restano a rischio.

In una comunicazione separata inviata direttamente ai clienti, marcata come urgente, la stessa azienda ha invece dichiarato che CVE-2026-86218 «è stata osservata mentre veniva sfruttata in rete» e l'ha definita una zero-day. L'avviso indicava come interessate sia le installazioni on-premise sia quelle ospitate da N-able, in America, Asia-Pacifico ed Europa.

Le due affermazioni sono incompatibili. E non si tratta di una sfumatura: cambia completamente la priorità con cui un'organizzazione pianifica l'intervento.

Attorno alla stessa finestra temporale N-able ha corretto anche CVE-2026-86206 e CVE-2026-86207, due falle di gravità alta che consentono di aggirare l'autenticazione e ottenere accesso senza restrizioni alla piattaforma. Huntress, che segue il caso dall'inizio di agosto, ha segnalato che sul server N-central compromesso di un proprio cliente i log erano già stati ruotati: non è quindi possibile stabilire quale delle vulnerabilità sia stata effettivamente usata in quell'attacco. La stessa società ha raccontato di aver appreso dell'esistenza della nuova falla da un messaggio pubblicato da un dipendente N-able su un canale Discord della community MSPGeek, prima dell'annuncio ufficiale.

Il problema non è la patch, è il segnale

Un difetto di sicurezza in un prodotto complesso è fisiologico. Tre in sei settimane sullo stesso componente indicano piuttosto che quel componente è finito stabilmente nel mirino della ricerca offensiva, ed è un'informazione che vale più della singola CVE: significa che è ragionevole aspettarsene altre.

Ma il punto critico qui è la comunicazione a due velocità. Chi legge solo le note di rilascio pubbliche — tipicamente il tecnico che la mattina controlla i bollettini, o il consulente esterno che non è nella mailing list clienti — riceve il messaggio «nessuna conferma di sfruttamento» e programma l'aggiornamento per la finestra di manutenzione successiva. Chi riceve l'avviso diretto legge «zero-day sfruttata in rete» e interviene la sera stessa. Stesso prodotto, stessa falla, due decisioni operative opposte.

Per un'organizzazione questo si traduce in un requisito pratico: la sottoscrizione ai canali di avviso del fornitore va trattata come un controllo di sicurezza, con un responsabile nominato e un indirizzo di posta monitorato, non come una casella spuntata in fase di acquisto. Se il canale che riceve la comunicazione urgente è la casella di un dipendente che non lavora più in azienda, l'avviso più importante non arriverà mai.

Cosa significa per le aziende italiane

La maggior parte delle PMI italiane non ha un server N-central e non saprebbe riconoscerlo. Ce l'ha però il fornitore a cui ha esternalizzato la gestione dei sistemi, e questo rende il problema più difficile da governare, non meno.

Il modello di outsourcing IT diffuso nel nostro tessuto produttivo — un system integrator o un MSP che segue decine o centinaia di aziende dello stesso territorio, spesso dello stesso distretto industriale — crea una concentrazione di rischio che raramente compare nelle valutazioni. Un singolo server RMM compromesso non produce un incidente: ne produce cinquanta contemporaneamente, in aziende che non hanno alcun rapporto tra loro e che scopriranno di essere collegate solo il giorno in cui succede.

C'è poi un aspetto di asimmetria informativa. L'azienda cliente non può verificare la versione di N-central in esercizio, non riceve i bollettini del vendor, non sa se il proprio fornitore abbia applicato Hotfix 4 il 5 settembre o se lo farà a fine mese. L'unica leva disponibile è contrattuale e documentale: chiedere per iscritto, ottenere una risposta scritta, conservarla.

Vale la pena osservare che nessuno dei controlli difensivi tradizionalmente adottati dalla PMI aiuta in questo scenario. L'agente RMM è software legittimo, firmato, installato volontariamente, con privilegi di SYSTEM, che si connette a un server autorizzato ed esegue comandi da remoto: è esattamente ciò che deve fare. Un EDR non ha alcun motivo per bloccarlo. La compromissione arriva attraverso un canale di fiducia già concesso.

Il quadro normativo

Per i soggetti in perimetro NIS2 — il D.Lgs. 138/2024 in Italia — la sicurezza della catena di fornitura è una delle misure minime esplicitamente richieste, e le misure di sicurezza di base previste dalle determinazioni ACN devono essere pienamente operative entro il 31 ottobre 2026. Un fornitore di servizi gestiti che ha accesso amministrativo ai sistemi è, in questa cornice, il fornitore più critico di tutti: la valutazione del rischio deve trattarlo come tale, e non liquidarlo con un'autocertificazione generica.

Sul fronte GDPR, un MSP che gestisce i sistemi del cliente è quasi sempre responsabile del trattamento ai sensi dell'articolo 28. La compromissione della sua piattaforma di gestione è una violazione di dati personali che il responsabile deve comunicare al titolare «senza ingiustificato ritardo» (articolo 33, paragrafo 2): il termine di 72 ore per la notifica al Garante decorre da quando il titolare ne viene a conoscenza, e quindi dipende interamente dalla tempestività del fornitore. Se il contratto di nomina non prevede un termine espresso e un canale definito, quel meccanismo non funziona.

Cosa fare subito

Se gestite un'installazione N-central:

  • Aggiornare immediatamente a N-central 2026.3 Hotfix 4 (build 2026.3.1.14). Trattare la più prudente fra le due comunicazioni del vendor come quella corretta.
  • Verificare l'elenco degli account utente della piattaforma alla ricerca di utenze non previste: è la raccomandazione esplicita di N-able e il primo indicatore di una compromissione avvenuta.
  • Non affidarsi ai soli log locali per escludere lo sfruttamento: nel caso documentato da Huntress i log del server erano già stati ruotati. Verificare la finestra di ritenzione e, se possibile, esportare i log verso un sistema esterno.
  • Rimuovere l'interfaccia di amministrazione da Internet o limitarla a indirizzi noti; imporre l'autenticazione a più fattori su tutti gli account amministrativi.
  • In caso di sospetta compromissione, ruotare le credenziali e i token di integrazione presenti sulla piattaforma: la patch chiude la porta, non revoca ciò che è già uscito.

Se siete un'azienda cliente di un MSP:

  • Chiedere per iscritto al fornitore se utilizza N-able N-central e, in caso affermativo, quale versione è in esercizio e quando è stato applicato Hotfix 4.
  • Chiedere quale canale riceve gli avvisi di sicurezza dei vendor e chi li presidia.
  • Inserire nel contratto un obbligo di notifica degli incidenti che coinvolgono la piattaforma di gestione, con un termine espresso in ore e un referente nominato.
  • Verificare i privilegi dell'agente RMM installato sulle proprie macchine e valutare se il perimetro di gestione possa essere ridotto ai sistemi che ne hanno effettivamente bisogno.
  • Pretendere visibilità sui log: senza accesso ai log delle azioni eseguite dal fornitore sui vostri sistemi, in caso di incidente non sarete in grado di ricostruire nulla.