N-able N-central: 30+ zero-day pubblicati, piattaforma spenta

Un server RMM è la macchina che un attaccante vuole di più, perché possiede già ogni endpoint che gestisce. La notte di domenica 8 novembre un ricercatore ha pubblicato più di trenta presunti zero-day in N-able N-central — la piattaforma di monitoraggio e gestione remota che migliaia di MSP usano — con exploit proof-of-concept funzionanti e nessuna patch esistente. Lunedì 9 novembre N-able ha messo offline l'intero parco hosted di N-central in Americhe, Europa e Asia-Pacifico e ha detto ai clienti on-premise di spegnere i server "fino a nuovo avviso". Non c'è una versione corretta a cui aggiornarsi, e non c'è un CVE da cercare. Se gestisci N-central, la domanda sulla tua esposizione va risolta senza nessuna delle due.

Notizia in evoluzione — pubblicata alle 22:36 (21:36 UTC) del 9 novembre 2026. Aggiornata man mano che vendor e CISA pubblicano.

Cosa è successo

Il ricercatore, Sean Bales, ha rilasciato i bug senza coordinarsi con N-able e ha pubblicato un repository di exploit proof-of-concept, annunciato su LinkedIn. Secondo la cronaca di BleepingComputer, dice di essere andato pubblico perché segnalazioni precedenti su un altro prodotto N-able — due RCE non correlate e un difetto di privilege escalation — erano rimaste non corrette per cinque-sei mesi, con circa cinque email di sollecito in quattro-sei settimane e nessuna risposta, e nessun pagamento di bug bounty. N-able non ha replicato a queste accuse specifiche; dopo la pubblicazione, CEO e CTO avrebbero contattato Bales chiedendogli di rimuovere il repository.

Le oltre trenta vulnerabilità non sono minori. Vanno dai bypass di autenticazione alla divulgazione di credenziali, scritture arbitrarie di file, directory traversal, cross-site scripting, XXE injection ed esecuzione di codice remoto. La catena peggiore descritta è un'XXE non autenticata nella funzione di import dei servizi: ruba una sessione locale fidata, resetta la password di un account ed esegue comandi come utente di servizio nable — e da lì crea un account Default Administrator abilitato. Una XSS stored separata esegue comandi come root quando un amministratore si limita a visualizzare metadati di patch malevoli, e un difetto di privilege escalation porta il codice da nable a root. Tutti i test sono stati fatti su una build pre-release, N-central Appliance 2026.4.0.31, che il ricercatore dice fosse non patchata al momento della pubblicazione; ritiene che quasi tutte le falle colpiscano anche le versioni precedenti.

La posizione di N-able, a oggi, è di "non aver osservato sfruttamento attivo di queste vulnerabilità" e di non vedere "nessuna prova di sfruttamento attivo o accesso non autorizzato ai dati", e di stare sviluppando e validando un hotfix. Va letta per quello che è: un'affermazione sulla telemetria del vendor, non un via libera per un'appliance on-prem che il vendor non vede.

Perché compromettere N-central è compromettere l'intera flotta

N-central non è una normale applicazione web. È la console con cui un MSP distribuisce script, applica patch ed esegue comandi su ogni endpoint gestito, in ogni rete cliente che tocca. Un attaccante che arriva a Default Administrator su un N-central eredita quella portata. È il raggio d'azione della supply chain MSP, e N-central ci è già finito dentro: ad agosto un bypass di autenticazione già sfruttato (CVE-2026-18577) ha portato la piattaforma nel catalogo CISA Known Exploited Vulnerabilities, e prima ancora SecurityWeek riportava oltre 870 istanze ancora non patchate contro due falle sfruttate del 2025, secondo Shadowserver.

L'architettura peggiora le cose. Quando Horizon3 ha fatto patch-diffing delle correzioni dell'anno scorso, ha scoperto che la catena, combinata, "permette a un attaccante non autenticato di interagire con API legacy e leggere file sensibili", e che "in quasi tutti i deployment… le credenziali trafugate hanno portato a compromettere il database di N-central" — un database che conserva segreti di integrazione, credenziali di dominio, chiavi API e chiavi SSH private in forma recuperabile. Ha anche contato circa 3.000 istanze N-central esposte su internet.

Remediation

Non c'è ancora una patch. Prima contenimento, poi bonifica.

• Sono esposto? Se gestisci N-central in qualsiasi forma, parti dal sì finché non dimostri il contrario. Hosted / cloud: N-able ha messo l'ambiente offline; non serve azione del cliente oltre a seguire la pagina di stato. On-premise: sei esposto, e le catene peggiori sono non autenticate contro la console web.
• Patch — versione corretta: non esiste. N-able dice che un hotfix è in sviluppo e che pubblicherà aggiornamenti sulla pagina di stato circa ogni quattro ore. Non restare online ad aspettarlo.
• Non puoi spegnere? Controlli compensativi. Segui il vendor e metti offline N-central on-prem fino all'hotfix. Se lo spegnimento è davvero impossibile, come minimo togli la console di gestione da internet — solo VPN o allowlist di IP — perché le falle critiche non richiedono credenziali. L'isolamento di rete non corregge i bug; rimuove il percorso dell'attaccante non autenticato verso di essi.
• Caccia alla compromissione. Partendo dai meccanismi pubblicati, cerca: un account Default Administrator inatteso o appena abilitato; account admin con password resettate senza un cambio corrispondente; processi o comandi generati dall'account di servizio nable; modifiche inspiegate ai metadati di patch o service template. Poiché N-central è il canale di distribuzione, rivedi anche script e task inviati di recente agli endpoint gestiti. Mappa su ATT&CK: Exploit Public-Facing Application (T1190), Valid Accounts (T1078), Create Account (T1136) e il fan-out da relazione fidata che un RMM abilita (T1199 / T1219).
• Bonifica e verifica. Se trovi indicatori, tratta l'appliance come non fidata: ricostruiscila da un'immagine sana e ruota ogni segreto che conteneva — credenziali di integrazione e di dominio, chiavi API, chiavi SSH — perché il database le conserva in forma recuperabile. Quando arriva l'hotfix, verifica che chiuda davvero il percorso non autenticato invece di fidarti del numero di versione.

Cosa non si sa ancora

Non sono stati assegnati identificativi CVE. Non esiste una versione corretta, quindi per questa divulgazione non c'è ancora nulla nel catalogo CISA KEV. La conferma indipendente di ciascuna delle oltre trenta falle è in corso — BleepingComputer nota di non averle verificate tutte. L'affermazione di N-able sul "nessuno sfruttamento attivo" non è stata corroborata in modo indipendente, e non è chiaro se il repository del ricercatore sia stato rimosso. Aggiorneremo man mano che arrivano hotfix, assegnazioni CVE ed eventuali report di sfruttamento.

Scansionare una versione qui non dice nulla

Ogni playbook di detection ancorato a un numero CVE o a una build patchata fallisce su questa storia, perché non esistono né l'uno né l'altra. L'unica risposta onesta a "il mio N-central è sfruttabile" è lanciare la catena contro di esso e vedere. È ciò che un red team AI autonomo fa diversamente da uno scanner: lo swarm a 10 agenti di Zero Hunt identifica la versione esatta installata, scrive un proof-of-concept funzionante per *quell'*ambiente invece di cercare una firma, e lo esegue in un container effimero e irrobustito che non tocca mai l'host dell'appliance — gray-box contro il tuo stesso parco, con un umano che approva ogni passo e ogni finding firmato alla scrittura. Gira on-premise su modelli privati, quindi puntarlo su un RMM che custodisce le credenziali dei tuoi clienti non invia mai quelle credenziali a terzi. Quando non c'è un CVE da aspettare, dimostrare da soli la sfruttabilità — come ha fatto il ricercatore — è il modo più rapido per sapere se sei il prossimo titolo. La validazione continua e governata di questo tipo è trattata nella nostra guida al penetration testing automatizzato.

E poiché un N-central compromesso è la compromissione di tutto ciò che gestisce, la detection non può fermarsi all'appliance. L'AI Traffic Analysis di Zero Hunt — un modello di deep learning con quattro teste di inferenza che gira sulla GPU dell'appliance — osserva il fan-out stesso: una console RMM che all'improvviso spinge verso host che non ha motivo di raggiungere, sessioni cariche di credenziali verso ASN mai visti, lo staging e l'esfiltrazione di un prelievo massivo di dati mentre accade. Il "nessuna prova di sfruttamento attivo" di un vendor è un'affermazione sulla sua visibilità. Il traffico sul tuo filo è la parte che puoi davvero verificare.