Una sola falla, tutti i clienti a rischio
Cosa succede se qualcuno prende il controllo del server con cui il tuo fornitore IT gestisce mezzo parco macchine? Con N-able N-central adesso e' una domanda concreta. Il 5 settembre N-able ha rilasciato la Hotfix 4 (build 2026.3.1.14) per CVE-2026-86218, una vulnerabilita' con punteggio CVSS 10, il massimo possibile. Permette l'esecuzione di codice da remoto senza autenticazione: basta raggiungere la console via HTTP. Nessuna password, nessun account.
Cos'e' N-central e perche' conta
N-central e' una piattaforma RMM, cioe' remote monitoring and management. E' il cruscotto da cui gli MSP e i reparti IT strutturati tengono sotto controllo migliaia di endpoint: installano aggiornamenti, lanciano script, aprono sessioni remote. Ha per progetto un accesso privilegiato a tutti i sistemi che amministra. Se un attaccante entra nel server N-central non ha bucato un'azienda: ha bucato tutte quelle collegate a quel server. E' lo stesso schema gia' visto con Kaseya nel 2021.
Lo sfruttamento e' gia' in corso
Non e' teoria. La falla e' sotto attacco attivo almeno dal 4 settembre. CISA l'ha inserita nel catalogo Known Exploited Vulnerabilities e ha imposto alle agenzie federali statunitensi di aggiornare entro l'11 settembre. Huntress dice di aver osservato tentativi di sfruttamento nelle reti dei propri clienti. E non e' un episodio isolato: e' la terza ondata di attacchi a N-central in sei settimane. Pochi giorni prima erano stati corretti due bypass di autenticazione (CVE-2026-86206 e CVE-2026-86207, segnalati da Stephen Fewer di Rapid7) che permettevano di creare account amministrativi senza credenziali.
Cosa fare adesso
Le istanze cloud gestite da N-able (NCOD) sono gia' state aggiornate dal fornitore. Il problema sono le installazioni on-premise: li' l'aggiornamento va applicato a mano, subito. Dopo la patch, N-able consiglia di rivedere l'elenco degli utenti di N-central e cercare account che non dovrebbero esserci: se il server e' stato colpito prima dell'aggiornamento, un accesso potrebbe gia' essere stato piazzato. Vale la pena guardare anche i log di accesso alla console e gli script eseguiti negli ultimi giorni.
💬 Il mio commento
Gli strumenti di gestione remota sono comodissimi e sono anche il singolo punto in cui si concentra piu' rischio in assoluto. Un RMM ha le chiavi di tutto: se salta lui, salta il resto. Per questo, quando seguo un MSP o un reparto IT strutturato, la console RMM la tratto come tratterei un domain controller: non deve stare esposta su internet senza filtri. Accesso solo da VPN o da una lista di IP autorizzati, autenticazione a piu' fattori su ogni account, e un elenco aggiornato di chi puo' entrare. In questo caso specifico non sarebbe bastato a fermare tutto, perche' la falla e' pre-auth e colpisce chiunque raggiunga la console via HTTP, ma ridurre la superficie esposta avrebbe tolto il bersaglio a buona parte degli attacchi opportunistici che girano in questi giorni.
La cosa che mi preoccupa di piu' qui e' il tempismo: quattro patch in poche settimane sullo stesso prodotto, con sfruttamento attivo prima ancora che molti si accorgessero del bollettino. Chi ha un N-central on-premise e lo aggiorna una volta al mese, in questa finestra, e' rimasto scoperto per giorni. Il consiglio che ripeto sempre vale anche adesso: sui sistemi che governano altri sistemi, la patch critica non e' un'attivita' da pianificare per il weekend, e' roba da stessa giornata, e va accompagnata da un controllo degli account e dei log per capire se qualcuno e' gia' passato. Se gestisci un server N-central, o piu' in generale un RMM, e vuoi un parere su quanto e' esposto e su cosa verificare dopo questi aggiornamenti, scrivimi e lo guardiamo insieme.