N-able N-central, RCE critica CVSS 10: Hotfix 4 urgente dopo exploit in-the-wild

🛡️ Executive Summary

• CVE-2026-86218 consente esecuzione remota di codice pre-authentication sui server N-able N-central e raggiunge il punteggio massimo CVSS 10.0.
• N-able ha pubblicato Hotfix 4, build 2026.3.1.14: Hotfix 3 non protegge dalla nuova vulnerabilità e gli ambienti on-premise devono aggiornare immediatamente.
• Le comunicazioni N-able sono contraddittorie: le release note negano exploit confermati, mentre lo status urgente afferma che la nuova falla è stata sfruttata in-the-wild.

N-able ha distribuito un quarto hotfix urgente per N-central dopo la scoperta di CVE-2026-86218, vulnerabilità con punteggio CVSS 10.0 che consente a un attaccante non autenticato di ottenere remote code execution sul server N-central. La correzione arriva a poche ore da altri due bug di authentication bypass e soprattutto durante una nuova fase di incidenti che interessa la piattaforma RMM utilizzata da MSP e reparti IT per amministrare interi parchi di endpoint. Il punto più delicato riguarda però le stesse comunicazioni del vendor: una pagina N-able afferma che non esistono conferme di sfruttamento, mentre lo status urgente pubblicato dalla società dichiara esplicitamente che la nuova vulnerabilità è stata osservata in-the-wild.

CVE-2026-86218 permette RCE prima dell’autenticazione

La vulnerabilità CVE-2026-86218 interessa N-able N-central e permette a un attaccante remoto di raggiungere il server prima della fase di autenticazione ed eseguire codice. Nelle release note ufficiali di N-central 2026.3 Hotfix 4, N-able definisce espressamente il problema una pre-authenticated remote code execution e assegna alla falla il massimo livello di criticità. La versione corretta è N-central 2026.3.1.14, corrispondente a Hotfix 4. Per gli ambienti hosted il produttore ha già applicato la patch, mentre gli amministratori delle installazioni self-hosted/on-premise devono procedere all’aggiornamento manuale. La gravità va letta anche in funzione del ruolo di N-central: non è una semplice applicazione web esposta su Internet, ma una piattaforma Remote Monitoring and Management dalla quale un MSP può amministrare server e workstation appartenenti a numerosi clienti. Una RCE pre-authentication sul server centrale crea quindi un potenziale punto di ingresso con capacità di propagazione downstream molto superiore a quella di un normale endpoint. Questa superficie era già diventata critica durante gli attacchi di agosto contro N-central, quando gli intrusi avevano utilizzato la console RMM per raggiungere direttamente i sistemi amministrati.

N-able dice contemporaneamente che l’exploit è confermato e non confermato

La gestione pubblica dell’incidente presenta una contraddizione che non può essere ignorata. Nelle note di Hotfix 4 pubblicate da N-able compare la formula secondo cui, al momento della pubblicazione, la società non dispone di conferme che CVE-2026-86218 sia stata sfruttata in ambienti di produzione. Ma la pagina relativa all’incidente urgente utilizza una formulazione differente e molto più netta. Nell’avviso “URGENT: N-CENTRAL IMMEDIATE HOTFIX REQUIRED”, N-able spiega che un terzo ricercatore indipendente ha segnalato una nuova vulnerabilità separata dai due bug appena corretti e aggiunge che, a differenza delle vulnerabilità precedenti, la nuova falla è stata osservata mentre veniva sfruttata in-the-wild. Non si tratta di una sfumatura terminologica: una comunicazione descrive un rischio potenziale senza compromissioni confermate, l’altra parla di sfruttamento reale. Alla luce dell’avviso operativo più recente, per un amministratore la scelta prudente è trattare CVE-2026-86218 come una vulnerabilità associata a un incidente attivo, indipendentemente dal fatto che N-able debba ancora chiarire formalmente se l’attacco osservato possa essere attribuito con certezza a quella specifica CVE.

Leggi anche: Storm-1175 usa StormEncryptor dopo gli attacchi a N-central

Hotfix 3 è già superato dopo meno di un giorno

Il ritmo delle correzioni rende l’incidente ancora più delicato. Il 5 settembre N-able aveva rilasciato Hotfix 3, build 2026.3.1.13, per correggere CVE-2026-86206 e CVE-2026-86207. La prima riguarda un bypass dei filtri di controllo degli accessi verso API interne, mentre la seconda permette di aggirare l’autenticazione e ottenere accesso non autorizzato a N-central. N-able attribuisce rispettivamente punteggi CVSS 6.9 e 7.7 e afferma che le vulnerabilità erano state segnalate attraverso il programma di responsible disclosure da ricercatori di Rapid7 Labs e Huntress. Per quei due bug il produttore sostiene di non avere evidenze confermate di sfruttamento. Poche ore dopo è però emersa CVE-2026-86218, separata dalle prime due e sufficientemente grave da rendere già obsoleto Hotfix 3. Chi ha installato 2026.3.1.13 non è protetto dalla RCE appena scoperta e deve passare a Hotfix 4. È un problema particolarmente importante per gli MSP che potrebbero aver considerato chiuso il ciclo di remediation dopo l’aggiornamento del 5 settembre. La sequenza ricorda quanto accaduto appena un mese prima, quando CISA aveva inserito le precedenti vulnerabilità N-central tra quelle sfruttate attivamente e un primo aggiornamento era stato rapidamente seguito da ulteriori interventi di hardening.

Huntress non riesce ad attribuire l’attacco a una delle tre nuove CVE

La ricostruzione di Huntress aggiunge un elemento fondamentale. Nella timeline tecnica pubblicata dalla società di sicurezza, i ricercatori spiegano di avere osservato una compromissione su un server N-central di un cliente che risultava già aggiornato. Inizialmente non era possibile escludere che l’intrusione avesse sfruttato CVE-2026-86206 o CVE-2026-86207; dopo la pubblicazione di CVE-2026-86218 è diventato possibile ipotizzare anche il terzo vettore. I log necessari a stabilirlo erano però già stati ruotati, impedendo una determinazione forense definitiva. Huntress non può quindi dire quale delle tre vulnerabilità sia stata utilizzata nell’incidente osservato e definisce la nuova RCE un possibile zero-day nel contesto dell’attività investigata. Questa incertezza spiega almeno in parte la contraddizione delle comunicazioni di N-able: esiste evidenza di compromissione e N-able stessa afferma che la nuova vulnerabilità è stata osservata in-the-wild, ma l’associazione forense tra un determinato accesso e CVE-2026-86218 potrebbe non essere dimostrabile per ogni sistema coinvolto. Per chi difende la rete, tuttavia, la distinzione cambia poco: HF4 va trattato come aggiornamento di emergenza, non come patch pianificabile nel normale ciclo mensile.

Quasi 1.500 server N-central risultano esposti su Internet

La superficie potenzialmente raggiungibile è tutt’altro che marginale. Il monitoraggio pubblico di Shadowserver dedicato alle istanze N-able N-central individua circa 1.500 server N-central visibili da Internet, con una forte concentrazione negli Stati Uniti e in Europa. Il numero non equivale automaticamente a 1.500 sistemi vulnerabili a CVE-2026-86218: l’esposizione del servizio non permette di determinare da sola versione, stato delle patch e configurazione di ogni istanza. Rappresenta però una superficie interessante per attività di scanning automatizzato immediatamente successive alla disclosure. Una RCE pre-auth con punteggio CVSS massimo è esattamente il tipo di vulnerabilità per cui la finestra tra pubblicazione della patch e tentativi di reverse engineering tende a essere molto ridotta. Nel caso di N-central il rischio è amplificato perché il server compromesso può disporre delle funzioni necessarie per amministrare gli endpoint dei clienti, come dimostrato dagli incidenti precedenti in cui gli attaccanti avevano utilizzato Take Control e successivamente distribuito Cloudflare Tunnel sui sistemi raggiunti.

Patchare N-central non basta se il server è già stato compromesso

Gli amministratori on-premise devono quindi installare N-central 2026.3 HF4, build 2026.3.1.14, anche se hanno già distribuito HF3. N-able permette l’aggiornamento diretto dalle versioni 2025.4, 2026.1, 2026.2, 2026.3, Hotfix 1 e Hotfix 2; per release più vecchie è necessario raggiungere prima una delle build supportate. L’azienda chiarisce inoltre che la correzione della vulnerabilità server non richiede obbligatoriamente l’upgrade degli agenti N-central, pur raccomandando di mantenerli aggiornati. La patch, però, risolve il vettore e non dimostra che un sistema precedentemente esposto sia pulito. Quando esistono indicazioni di exploit in-the-wild occorre ricostruire sessioni amministrative, nuovi account, attività Take Control, servizi installati, processi anomali, modifiche di configurazione e connessioni esterne avvenute prima dell’aggiornamento. L’esperienza di agosto ha già mostrato che un aggressore può spostare la persistenza dal server N-central agli endpoint amministrati e conservare l’accesso anche dopo la correzione della falla iniziale.

Continua con:

• Vulnerabilità enterprise sotto attacco tra LoadMaster, Metabase, Rovo e N-central

Il problema N-central è diventato una crisi continua per gli MSP

CVE-2026-86218 non arriva in un ambiente neutro. N-central era già finito sotto sfruttamento attivo ad agosto attraverso CVE-2026-18556 e CVE-2026-18577, con accesso amministrativo ai server RMM, movimento verso gli endpoint dei clienti e persistenza esterna. Settembre aggiunge prima due nuovi bypass dell’autenticazione e subito dopo una RCE pre-auth CVSS 10.0 che rende obsoleto un hotfix rilasciato appena poche ore prima. Per gli MSP il segnale operativo è chiaro: N-central non può essere gestito in questa fase come un normale prodotto enterprise sottoposto al calendario ordinario delle patch. Una console RMM concentra privilegi, accesso remoto e relazioni di fiducia verso sistemi downstream; trasformarla nel punto iniziale di un attacco significa moltiplicare immediatamente il potenziale impatto. La priorità è quindi installare HF4, ridurre quanto possibile l’esposizione diretta del server, verificare le attività pregresse e cercare segni di compromissione anche sugli endpoint amministrati. Resta infine necessario che N-able chiarisca la propria comunicazione: non possono restare contemporaneamente valide una release note che nega exploit confermati e un avviso urgente del vendor che dichiara la nuova vulnerabilità osservata in-the-wild.