N-able corregge una RCE critica pre-autenticazione in N-central, mentre le segnalazioni di sfruttamento sono contraddittorie

N-able ha rilasciato un aggiornamento di emergenza per N-central, la sua piattaforma on-premises di monitoraggio e gestione remota, correggendo una vulnerabilità critica che consente l’esecuzione di codice da remoto senza autenticazione.

Identificata come CVE-2026-86218, la vulnerabilità interessa tutte le build di N-central precedenti alla 2026.3.1.14, inclusa la 2026.3.1.13, distribuita come Hotfix 3 poco prima della divulgazione della nuova vulnerabilità.

La build corretta, N-central 2026.3.1.14, è disponibile come 2026.3 Hotfix 4. N-able ha pubblicato e aggiornato la scheda CVE il 6 settembre 2026 e invita tutti i clienti on-premises a eseguire immediatamente l’aggiornamento.

Non è ancora chiaro se gli attaccanti stiano già sfruttando la vulnerabilità. N-able ha rilasciato dichiarazioni contraddittorie: alcuni avvisi dell’azienda affermano che non risultano casi confermati di sfruttamento in ambienti di produzione, mentre un avviso separato relativo a un incidente sostiene che lo sfruttamento sia stato osservato in the wild.

Una vulnerabilità di gravità massima che non richiede credenziali

CVE-2026-86218 ha ottenuto il punteggio massimo CVSS 4.0 di 10,0, con il seguente vettore:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

La valutazione descrive una vulnerabilità raggiungibile via rete e sfruttabile con una bassa complessità d’attacco. L’attaccante non ha bisogno di un account, di privilegi o dell’interazione di un utente legittimo.

Lo sfruttamento riuscito può compromettere gravemente la riservatezza, l’integrità e la disponibilità sia del server N-central sia dei sistemi a valle. L’impatto è particolarmente rilevante per un prodotto RMM, poiché i server N-central amministrano flotte di endpoint dei clienti e offrono funzionalità di controllo remoto.

La debolezza alla base del problema è classificata come CWE-96, ovvero neutralizzazione impropria delle direttive nel codice salvato staticamente. Questa categoria viene comunemente descritta come iniezione di codice statico: direttive controllate dall’attaccante vengono incorporate nel codice o in un’altra risorsa eseguibile, che viene poi salvata ed elaborata.

N-able non ha reso noto quale componente sia vulnerabile, né ha pubblicato il formato delle richieste necessario, la procedura di sfruttamento o altri dettagli tecnici sufficienti a riprodurre il problema. Non sono stati forniti indicatori pubblici di compromissione.

Secondo la scheda CVE, l’intervallo interessato parte dalla versione 0 e comprende tutte le release precedenti alla 2026.3.1.14. Il prodotto vulnerabile è il server N-central, non gli agent gestiti.

I sistemi con Hotfix 3 restano esposti

Hotfix 4 è necessario anche sui server che hanno già ricevuto Hotfix 3, build 2026.3.1.13. La release precedente correggeva due vulnerabilità distinte:

• CVE-2026-86206 riguardava l’accesso non autorizzato alle API interne attraverso il filtro di controllo degli accessi alle API interne di N-central. N-able le ha assegnato un punteggio CVSS di 6,9, Medio, mentre NVD la classifica come CWE-791. È corretta in N-central 2026.3 HF3 e 2026.4.
• CVE-2026-86207 era un bypass dell’autenticazione che interessava le API riservate all’uso interno. N-able le ha assegnato un punteggio CVSS di 7,7, Alto ed è classificata come CWE-305. Sono interessate le versioni precedenti alla 2026.3 HF3.

N-able afferma che queste due vulnerabilità non sono correlate a CVE-2026-86218. Di conseguenza, l’installazione di Hotfix 3 non mitiga il nuovo percorso di esecuzione del codice pre-autenticazione.

Hotfix 4 è il quarto aggiornamento per il ramo N-central 2026.3 nell’arco di cinque settimane. Hotfix 1, build 2026.3.1.7, è arrivato il 2 agosto per correggere CVE-2026-18577, una correzione incompleta di un precedente bypass dell’autenticazione. Hotfix 2, build 2026.3.1.10, è seguito il 6 agosto con ulteriori misure di hardening.

Hotfix 3, build 2026.3.1.13, è stato rilasciato il 5 settembre. Hotfix 4 è seguito il 6 settembre.

Questa rapida sequenza implica che gli amministratori non possano considerare la presenza di un hotfix 2026.3 recente come prova del fatto che un server sia protetto. È necessario verificare direttamente il numero di build.

N-able fornisce versioni contrastanti sullo sfruttamento attivo

Lo stato dello sfruttamento resta irrisolto.

Il materiale di rilascio di Hotfix 4 e l’aggiornamento sullo stato pubblicati da N-able affermano che una parte esterna ha segnalato responsabilmente la vulnerabilità attraverso il programma di divulgazione dell’azienda. Secondo queste comunicazioni, N-able non dispone di prove confermate di sfruttamento in ambienti di produzione.

Un avviso separato di N-able relativo a un incidente fornisce una versione diversa. Afferma che un terzo ricercatore indipendente di sicurezza ha segnalato una nuova vulnerabilità non correlata, osservata durante uno sfruttamento in the wild.

L’avviso non indica chi abbia osservato gli attacchi, quali ambienti siano stati interessati, quando si sia verificata l’attività né come sia stato verificato lo sfruttamento. La documentazione di N-able definisce inoltre CVE-2026-86218 una “critical zero-day”, ma l’azienda non ha spiegato come utilizzi questo termine.

L’incidente risultava ancora aperto nella pagina di stato di N-able il 7 settembre 2026. Non è stato attribuito ad alcun attore delle minacce.

Huntress ha iniziato a esaminare una compromissione il 4 settembre, dopo che l’ambiente N-central di produzione completamente aggiornato di un cliente era stato violato. I suoi ricercatori hanno riprodotto una catena di exploit contro la build 2026.3.1.10, che potrebbe aver coinvolto una o entrambe le vulnerabilità corrette successivamente da Hotfix 3.

Tuttavia, i log pertinenti dell’appliance erano già stati sovrascritti. Huntress non ha potuto determinare se CVE-2026-86218 facesse parte di quell’intrusione.

Esiste quindi un motivo concreto per considerare la vulnerabilità una minaccia immediata, ma non sono ancora disponibili prove documentate pubblicamente che dimostrino uno specifico attacco basato su questa CVE.

Le vulnerabilità precedenti di N-central sono state aggiunte al catalogo KEV di CISA

Non risulta che CVE-2026-86218 sia stata aggiunta al catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency degli Stati Uniti. Non è nota alcuna scadenza KEV per la correzione della vulnerabilità.

Tuttavia, diverse vulnerabilità recenti di N-central sono entrate nel catalogo.

CVE-2026-18577, una correzione incompleta che consentiva il bypass dell’autenticazione e la presa di controllo degli account, è stata aggiunta al catalogo KEV il 3 agosto 2026. Alle agenzie federali è stata assegnata una scadenza per la correzione al 6 agosto 2026. La vulnerabilità interessa le release di N-central precedenti alla 2026.3 e ha un punteggio CVSS 3.1 di 8,1.

CVE-2026-18556 è stata aggiunta il 4 agosto 2026, con correzione prevista entro il 7 agosto 2026. Questo bypass dell’autenticazione tramite un percorso alternativo interessa N-central <= 2026.1 e ha un punteggio CVSS di 7,4.

Per entrambe le vulnerabilità, CISA richiede l’adozione di misure di mitigazione in linea con le istruzioni del fornitore, con le indicazioni di gestione del rischio e applicazione delle patch previste da BOD 26-04 e con i requisiti di triage forense dell’agenzia.

Due vulnerabilità precedenti di N-central, CVE-2025-8875 e CVE-2025-8876, sono entrate nel catalogo KEV il 13 agosto 2025, con scadenza federale fissata al 20 agosto 2025. Hanno ricevuto rispettivamente punteggi CVSS di 7,8 e 8,8. CISA ha indicato alle organizzazioni di applicare le misure di mitigazione del fornitore, seguire le indicazioni cloud applicabili di BOD 22-01 oppure dismettere il prodotto qualora non fossero disponibili mitigazioni.

La storia recente è operativamente rilevante: N-central è stato preso di mira ripetutamente attraverso vulnerabilità che garantiscono accesso privilegiato o consentono l’esecuzione di codice.

Prima applicare la patch, poi verificare la presenza di accessi persistenti

Tutte le organizzazioni che utilizzano N-central on-premises dovrebbero installare 2026.3 Hotfix 4, portando il server alla build 2026.3.1.14. N-able fornisce percorsi di aggiornamento diretti da:

• 2025.4
• 2026.1
• 2026.2
• 2026.3
• Build hotfix 2026.3.1 esistenti

Gli agent gestiti non devono essere aggiornati per CVE-2026-86218. Secondo quanto riferito, anche N-central Online, noto anche come NCOD, è già stato aggiornato.

Se l’installazione immediata non è possibile, gli amministratori dovrebbero limitare l’accesso in ingresso alla console tramite un elenco di indirizzi IP consentiti o una VPN. Un server N-central accessibile da Internet che non possa essere aggiornato tempestivamente dovrebbe essere rimosso temporaneamente dalla rete.

L’applicazione della patch non dimostra che un sistema già esposto sia integro. Gli amministratori dovrebbero verificare la presenza in N-central di utenti non autorizzati, creazioni impreviste di account e modifiche ai privilegi prive di spiegazione.

Gli attacchi precedenti, rilevati dopo un’intrusione del 31 luglio, hanno utilizzato l’accesso amministrativo per abusare della funzionalità Take Control di N-central. Gli attaccanti hanno quindi registrato Cloudflare tunnel services sugli endpoint gestiti, mantenendo così l’accesso anche dopo la rimozione del loro percorso attraverso N-central.

I responsabili della difesa dovrebbero quindi verificare:

• Modifiche agli account amministrativi e utente;
• Attività di Take Control sugli endpoint gestiti;
• Accesso alle API interne di N-central;
• Nuovi Cloudflare tunnel o tunnel non autorizzati;
• Sessioni di gestione remota impreviste;
• Log disponibili del server e dell’appliance prima che vengano sovrascritti.

N-able non ha pubblicato indicatori specifici per CVE, workaround o regole di rilevamento dettagliate. Finché la discrepanza sullo sfruttamento non sarà chiarita, le organizzazioni dovrebbero considerare la build 2026.3.1.14 come versione minima sicura e conservare le evidenze prima che la normale conservazione dei log le elimini.