N-able oscura N-central: 30 zero-day e una piattaforma RMM al buio

N-able ha preso offline la sua piattaforma cloud N-central e ordinato ai clienti on-premises di spegnere i server il 9 novembre 2026, dopo che il ricercatore indipendente Sean Bales ha pubblicato nella notte tra l'8 e il 9 novembre oltre 30 presunte zero-day con proof-of-concept. La catena più critica, documentata con video dimostrativo, consente a un attaccante non autenticato di passare da XXE a RCE con esecuzione comandi come utente nable e creazione di account amministratore rogue. Nota editoriale: BleepingComputer, unica fonte primaria strutturata su questo evento, non ha verificato indipendentemente tutte le vulnerabilità divulgate da Bales; le affermazioni del ricercatore riguardo alla portata e alla gravità delle falle restano, per gran parte, non confermate da terzi.

La catena XXE-to-RCE che compromette il server RMM

Il nucleo tecnico della disclosure è una catena di exploit che parte da una vulnerabilità XXE injection non autenticata nella funzionalità service-import di N-central. Secondo il ricercatore, da questo entry point è possibile rubare una sessione trusted locale, resettare la password di un account esistente ed eseguire comandi come utente nable. La stessa catena consente di creare un Default Administrator account abilitato con credenziali controllate dall'attaccante.

Bales ha testato le vulnerabilità su N-central Appliance 2026.4.0.31, versione pre-release, e ritiene che la maggior parte o tutte le falle interessino anche versioni precedenti. Questa affermazione non è stata confermata da N-able. Il ricercatore ha reso pubblico un video dimostrativo con terminal output che mostra la creazione dell'account admin, l'autenticazione, l'accesso a funzionalità protette e l'esecuzione remota di comandi.

Le vulnerabilità divulgate includono, oltre alla catena XXE-to-RCE, authentication bypass, credential disclosure, arbitrary file writes, directory traversal, XSS e ulteriori RCE. N-central è la console che i managed service providers usano per patchare, monitorare e controllare remotamente i computer dei propri clienti. Per design, la piattaforma ha accesso privilegiato a tutti gli endpoint gestiti: la compromissione del server equivale a compromissione di tutte le reti e i dispositivi sotto la sua gestione.

La rottura del contratto di disclosure

La disclosure di Bales è avvenuta senza pre-notifica a N-able. Il ricercatore ha motivato questa scelta con un precedente frustrante: "I disclosed 2 unrelated RCEs for a different N-able product, along with a priv esc vulnerability 5 or 6 months ago. These have yet to be patched", ha dichiarato a BleepingComputer. Bales afferma di aver inviato email di follow-up nelle ultime 4-6 settimane senza ricevere risposta, e di non aver ottenuto pagamento attraverso la piattaforma bug bounty di N-able per i report precedenti.

Questo schema — ricercatore che abbandona il responsible disclosure dopo mesi di silenzio istituzionale — non è un caso isolato nell'industria della sicurezza. La perdita di fiducia nel processo coordinato diventa essa stessa un fenomeno sistemico, con conseguenze imprevedibili per vendor e utenti finali. Bales ha scelto la pubblicazione totale come forma di pressione, non come prima opzione.

Dopo la pubblicazione del repository Able2Shell, CEO e CTO di N-able hanno contattato direttamente Bales. "They did not threaten me or anything though. Only asked to take down the repo, work with them, etc.", ha precisato il ricercatore. Il repository non risulta rimosso al momento delle fonti. N-able non ha risposto alle domande di BleepingComputer sulle allegazioni relative ai report precedenti non patchati, lasciando senza replica le accuse di negligenza.

Il pattern ricorrente: perché le piattaforme RMM sono bersagli sistemici privilegiati

La disclosure di novembre 2026 non è il primo incidente critico per N-central. In agosto 2026, la CVE-2026-18577 — un authentication bypass con CVSS 8.1 HIGH — è stata sfruttata attivamente per prendere il controllo di account admin e distribuire tool di remote access su endpoint gestiti. Huntress ha confermato exploitation in corso, rilevando che oltre il 55,6% dei server cloud N-central raggiungibili restava ancora non patchato. Sophos ha identificato un'organizzazione compromessa con installazione di tool remote access e Cloudflare Tunnel. CISA ha aggiunto CVE-2026-18556 e CVE-2026-18577 al catalogo KEV con ordine di remediation in 3 giorni per agenzie federali.

Questa sequenza — KEV attivo a agosto, piattaforma oscurata a novembre — incide direttamente sulla credibilità delle rassicurazioni attuali di N-able. Il vendor dichiara che "protecting our customers remains our highest priority", ma la cronologia documenta un gap tra retorica corporate e risposta operativa. Avere già avuto un'emergenza KEV tre mesi prima, con percentuali di patching così basse, solleva interrogativi sulla maturità del programma di sicurezza di N-able che la dichiarazione ufficiale non affronta.

Le piattaforme RMM costituiscono una classe di rischio particolare: un singolo server compromesso offre accesso a centinaia o migliaia di endpoint gestiti, inverte la logica della difesa perimetrale rendendo il gestore stesso il punto di ingresso, e concentra in un unico target le funzioni di patching, monitoraggio e accesso remoto che gli attaccanti cercano di compromettere. La scelta di N-able di oscurare completamente N-central, piuttosto che isolare componenti specifici, testimonia la gravità percepita e l'assenza di alternative tecniche immediate.

"As a precautionary measure, we took our Hosted N-central environment offline today, November 9, and provided guidance to customers operating on-premises N-central servers to temporarily take their servers offline until further notice" — N-able

Cosa fare adesso

Le azioni disponibili derivano direttamente dalle dichiarazioni di N-able e dallo stato documentato dell'incidente. N-able ha ordinato ai clienti on-premises di spegnere i server N-central "until further notice" e sta sviluppando una hotfix. I clienti hosted non hanno azioni disponibili: la piattaforma è offline e il vendor controlla il ripristino. N-able pianifica aggiornamenti ogni quattro ore sulla situazione; i servizi Ecoverse accessibili tramite N-able Login rimangono operativi.

Per i clienti on-premises, la decisione di spegnere interrompe patching, monitoraggio e accesso remoto: questa è la conseguenza documentata della misura, non un'opzione tecnica. Non risultano dalla fonte primaria indicazioni su backup, policy, strumenti temporanei o verifiche aggiuntive al di fuori dell'attesa della hotfix e del ripristino dei servizi hosted.

La tensione non risolta

N-able afferma di non aver osservato exploitation attivo delle nuove vulnerabilità e di non aver trovato evidenza di accesso non autorizzato ai dati. La dichiarazione, tuttavia, non entra nel merito delle allegazioni di Bales sui report precedenti non gestiti, né spiega perché un ricercatore con precedenti vulnerabilità non patchate da mesi abbia dovuto ricorrere alla disclosure pubblica per ottenere risposta.

Il contrasto tra la retorica corporate e l'evidenza documentata costituisce il cuore del conflitto. N-able ha le risorse per contattare Bales a livello esecutivo entro ore dalla pubblicazione, ma non ha risposto alle sue email nelle settimane precedenti. Questa asimmetria — reattività mediatica, latenza istituzionale — è il pattern che la disclosure di Bales espone e che il vendor non ha ancora confutato.

La piattaforma resta al buio. I clienti attendono hotfix e ripristino senza timeline certe. Il caso Able2Shell, indipendentemente dalla verifica finale di ogni singola vulnerabilità, ha già dimostrato che il meccanismo di disclosure coordinata è rotto per questa coppia ricercatore-vendor, con conseguenze che ricadono sugli utenti finali.

Fonti

• bleepingcomputer.com
• mezha.net
• mlq.ai
• helpnetsecurity.com
• adaptivesecurity.com
• wiz.io