N-able N-central sotto attacco: cosa devono fare le aziende

Una vulnerabilità grave in N-able N-central, piattaforma usata per il monitoraggio e la gestione remota dei sistemi IT, è stata sfruttata in attacchi reali. Il problema conta perché chi compromette un server N-central può ottenere accesso amministrativo e usare gli strumenti legittimi della piattaforma per muoversi verso PC, server e dispositivi gestiti.

Per un’azienda questo non è un tema “da addetti ai lavori”: se il vostro reparto IT interno o il vostro fornitore usa N-central, un singolo punto di gestione può diventare la porta d’ingresso verso l’intera infrastruttura. E quando l’attacco passa da software di amministrazione remota, il rischio è che le attività malevole si confondano con quelle normali.

Cosa è successo

Tra il 3 e il 4 agosto 2026 sono arrivate due conferme importanti. N-able ha avvisato i clienti che una vulnerabilità di bypass dell’autenticazione, identificata come CVE-2026-18577 con severità CVSS 8.2, è stata sfruttata attivamente. Poco dopo, la CISA statunitense ha inserito la falla nel catalogo KEV (Known Exploited Vulnerabilities), cioè l’elenco delle vulnerabilità note per essere già usate in attacchi reali.

Secondo le informazioni pubblicate, il difetto consente un account takeover amministrativo tramite un problema di autenticazione aggirabile. In pratica, un attaccante remoto può ottenere privilegi elevati sui server N-central vulnerabili. Da lì può abusare della funzione Take Control, integrata nel prodotto, per raggiungere gli endpoint gestiti e stabilire persistenza.

N-able ha dichiarato che è stato compromesso un numero limitato di clienti, senza indicare una scala più ampia degli incidenti. Huntress, citata nelle ricostruzioni pubbliche, ha però osservato tentativi contro più organizzazioni, pur senza segnali di una campagna indiscriminata su larga scala.

Quali versioni sono coinvolte

Le fonti pubbliche concordano su un punto fondamentale: il problema riguarda versioni di N-central precedenti alla correzione distribuita da N-able. La falla è stata risolta con la release 2026.3 HF1, indicata anche come hotfix 2026.3.1.7.

N-able ha inoltre precisato che:

• le installazioni hosted hanno già ricevuto l’aggiornamento;
• le installazioni on-premises devono essere aggiornate manualmente dai clienti.

Questo dettaglio è importante perché molte aziende, soprattutto quelle che delegano la gestione a un MSP o usano ambienti ibridi, potrebbero dare per scontato che la correzione sia già stata applicata ovunque. Non è così: per le istanze locali serve una verifica esplicita.

Le fonti descrivono inoltre CVE-2026-18577 come il risultato di una correzione incompleta di una vulnerabilità precedente. Qui c’è una differenza tra le ricostruzioni pubbliche: una fonte la collega a CVE-2026-18556, un’altra a CVE-2026-18576. Al netto di questa incongruenza, il punto operativo non cambia: chi usa N-central deve considerare urgente l’installazione della versione corretta disponibile dal vendor.

Perché N-central è un bersaglio così delicato

N-central non è un software qualunque: è una piattaforma RMM (Remote Monitoring and Management), cioè uno strumento che consente di amministrare da remoto grandi insiemi di PC, server, apparati di rete e sistemi multi-OS. È usata sia dagli MSP sia dai reparti IT interni.

Questo significa che, se un attore ostile compromette il server di gestione, non ottiene solo accesso a un’applicazione: ottiene un punto di controllo privilegiato su molti sistemi. È il motivo per cui le piattaforme RMM sono da tempo nel mirino. Negli anni recenti sono finite in incidenti o campagne di sfruttamento anche altre soluzioni note del settore, e N-central stessa era già stata presa di mira nel 2025.

Per i criminali informatici, colpire un RMM offre tre vantaggi:

• accesso centralizzato a molti endpoint;
• possibilità di usare strumenti legittimi già autorizzati in rete;
• minore visibilità iniziale, perché alcune azioni sembrano amministrazione ordinaria.

Come si manifesta un compromesso

Le indicazioni condivise pubblicamente aiutano a capire cosa cercare. N-able ha diffuso alcuni indicatori di compromissione (IoC) che meritano attenzione immediata.

Fra questi:

• un file chiamato svchost.exe nella cartella Documenti dell’utente del dispositivo;
• un servizio registrato con nome Cloudflared;
• connessioni in ingresso da questi indirizzi IP:
  • 173.249.252.200
  • 87.249.138.34
  • 37.19.210.32
  • 68.235.46.214

Le analisi pubbliche segnalano inoltre che alcuni di questi IP risultano associati a nodi di uscita VPN come NordVPN e Mullvad. Questo non significa che ogni traffico proveniente da tali reti sia necessariamente malevolo, ma nel contesto specifico rappresenta un indicatore da verificare senza ritardi.

Dopo lo sfruttamento, i comportamenti osservati includono:

• ricognizione verso server critici, come i domain controller;
• enumerazione dei processi in esecuzione sull’host compromesso;
• movimento laterale verso altri sistemi dell’organizzazione.

In almeno un caso, è stata osservata una connessione malevola attraverso “MSP Support”, nome utente predefinito associato a sessioni legittime Take Control. Questo è un dettaglio insidioso: l’attaccante può nascondersi dietro elementi che ricordano attività operative normali.

Cosa significa per la tua azienda

Se la vostra azienda usa N-central direttamente, oppure si affida a un fornitore IT che lo usa per l’assistenza, conviene agire come se il rischio fosse immediato. Non serve allarmismo, ma serve metodo.

Ecco le priorità pratiche.

1. Verificate subito se N-central è presente nel vostro perimetro Non tutte le aziende sanno quali strumenti RMM usa il proprio partner IT. Chiedete esplicitamente se N-central è in uso, se l’istanza è hosted o on-premises e se l’hotfix è stato applicato.

2. Controllate la versione e lo stato dell’aggiornamento Per ambienti on-premises, la correzione non va data per scontata. Serve conferma documentata dell’installazione della release corretta.

3. Riesaminate i log di accesso e le attività Take Control La CISA raccomanda di rivedere l’attività di Take Control. In particolare, cercate accessi amministrativi anomali, sessioni fuori orario, connessioni da IP non abituali e attività su sistemi che normalmente non richiedono interventi remoti.

4. Cercate gli indicatori di compromissione pubblicati La presenza di svchost.exe nei Documenti o del servizio Cloudflared va trattata come un campanello d’allarme da approfondire subito con il vostro team IT o con un partner di sicurezza informatica.

5. Isolate e investigate se trovate tracce sospette Se emergono indicatori o attività anomale, la priorità è contenere: limitare accessi remoti, segmentare, cambiare credenziali amministrative potenzialmente esposte e avviare un’analisi dei sistemi più sensibili.

6. Verificate la vostra capacità di ripristino Le piattaforme di gestione remota sono spesso usate come trampolino per attacchi più ampi. Per questo è prudente controllare subito stato, integrità e tempi di recupero dei backup, soprattutto dei server chiave, con soluzioni di remote backup.

7. Riducete la fiducia implicita negli strumenti di amministrazione remota Molte aziende considerano gli strumenti IT interni o del fornitore come “trusted by default”. Oggi è una semplificazione pericolosa. Vale la pena rivedere permessi, accessi, MFA, account predefiniti e procedure di controllo operativo sui tool di gestione endpoint, anche nell’ambito di un servizio di desktop IT management.

Un campanello d’allarme anche per gli MSP

La notizia riguarda indirettamente anche le aziende clienti degli MSP. Se il vostro fornitore gestisce più clienti tramite una piattaforma centralizzata, la robustezza dei suoi processi di patching e monitoraggio incide direttamente sulla vostra sicurezza.

Per questo, oltre alla domanda “siamo vulnerabili?”, conviene porne un’altra: come viene governata la catena di fornitura IT? Alcuni temi da chiarire con il partner sono:

• tempi di applicazione delle patch critiche;
• monitoraggio delle sessioni remote;
• segregazione tra ambienti cliente;
• gestione delle credenziali privilegiate;
• procedure di incident response.

Non è sfiducia: è normale governance del rischio.

Perché l’inserimento nel catalogo KEV è rilevante

Quando la CISA aggiunge una vulnerabilità al catalogo KEV, manda un segnale chiaro al mercato: non si tratta di una falla teorica, ma di un problema già sfruttato con impatto operativo reale. Nel caso specifico, le agenzie federali civili statunitensi sono state invitate a correggere il problema entro il 6 agosto 2026.

Per una PMI italiana questa scadenza non è un obbligo normativo diretto, ma è un ottimo indicatore di priorità. In altre parole: se un ente come la CISA considera la finestra di intervento di pochi giorni, anche un’azienda privata dovrebbe trattare l’aggiornamento come urgente, non come attività da rimandare.

La lezione più ampia: gli strumenti IT sono bersagli ad alto valore

Questa vicenda conferma una tendenza ormai stabile: gli attaccanti cercano sempre più spesso software che hanno visibilità e controllo centralizzati, come RMM, console di amministrazione, strumenti di accesso remoto e piattaforme di supporto.

Per le aziende, la conseguenza è semplice: la sicurezza non dipende solo da firewall e antivirus, ma anche dalla disciplina con cui si governano gli strumenti usati ogni giorno per gestire l’infrastruttura. Patch tempestive, revisione dei privilegi, monitoraggio delle attività remote e capacità di ripristino non sono più misure “avanzate”: sono requisiti di base.

Domande frequenti

Se uso un fornitore IT esterno, devo preoccuparmi lo stesso?

Sì. Se il fornitore usa N-central per assistervi, un suo problema può riflettersi sui vostri sistemi. Chiedete conferma di aggiornamenti, controlli e verifiche effettuate.

Gli endpoint gestiti vanno aggiornati subito?

Secondo le informazioni pubbliche, per mitigare questa vulnerabilità la priorità è il server N-central. L’aggiornamento degli agent resta comunque raccomandato per avere fix e miglioramenti più recenti.

Come capisco se c’è stato un accesso anomalo?

Controllate sessioni Take Control inattese, accessi amministrativi insoliti, attività fuori orario, presenza degli IoC pubblicati e movimenti verso server critici come i domain controller.