N-able N-central CVE-2026-18577: un bypass di autenticazione, tutti gli endpoint gestiti

Il senso di una piattaforma di monitoraggio e gestione remota è che una sola console raggiunge ogni macchina che amministri. Ed è esattamente lì il problema. Il 3 agosto 2026 CISA ha aggiunto CVE-2026-18577 al catalogo Known Exploited Vulnerabilities, con scadenza di remediation federale fissata a oggi, 6 agosto — un bypass di autenticazione in N-able N-central sfruttato attivamente. Non è tanto una scoperta nuova quanto un secondo tentativo su una vecchia: N-able aveva già corretto la falla di fondo, e la correzione non ha tenuto.

Che cos'è davvero CVE-2026-18577: la patch che non ha tenuto

Il primo problema di N-central era CVE-2026-18556, un bypass di autenticazione che permetteva a un attaccante non autenticato di impossessarsi di un account amministrativo. Entrambe le falle sono classificate nello stesso modo — authentication bypass using an alternate path or channel — ed entrambe hanno un punteggio base CVSS 4.0 di 8.2. N-able ha rilasciato una correzione per CVE-2026-18556 nella versione 2026.2. I ricercatori hanno poi trovato una strada diversa verso lo stesso bug, che la correzione 2026.2 non aveva mai chiuso. Quella strada alternativa è CVE-2026-18577, e ha allargato la finestra di esposizione a ogni build di N-central precedente alla 2026.3.1.7.

È il tipo di fallimento che uno scanner basato su firme gestisce male per costruzione. La prima patch chiude la richiesta specifica usata dal primo proof-of-concept. La classe di vulnerabilità — un percorso alternativo verso lo stesso codice privilegiato — resta raggiungibile, solo non con l'input esatto che lo scanner ha imparato. Lo stesso aggiornamento di sicurezza N-able del 2 agosto è franco sulla sequenza: l'indagine è partita da errori anomali di licensing il 31 luglio, e il 2 agosto era già pronta la Hotfix 2026.3.1.7 per chiudere il percorso che la correzione precedente aveva lasciato aperto.

Il quadro versioni-e-fix è abbastanza corto da tenere a mente:

Build	Stato
Fino a 2026.1	Vulnerabile a CVE-2026-18556
2026.2	Fix incompleto — ancora sfruttabile via CVE-2026-18577
Precedenti a 2026.3.1.7	Vulnerabili
2026.3.1.7 (2026.3 HF1) e successive	Corretto

Da un server N-central a ogni endpoint gestito

Un bypass di autenticazione su una normale web app è grave. Su un server RMM è di categoria diversa, perché il compito legittimo del server è eseguire codice sui computer di altri. Nel momento in cui un attaccante ottiene una sessione amministrativa su N-central, eredita la portata che alla piattaforma è stata progettata.

Secondo Huntress e BleepingComputer, è esattamente ciò che è successo: dopo aver preso il controllo del server N-central, gli operatori hanno abusato della funzione integrata di accesso remoto Take Control per raggiungere gli endpoint gestiti a valle. Per questo secondo salto non serve alcun exploit. Take Control è una funzione amministrativa supportata. Per l'endpoint la sessione arriva dal server di gestione fidato, sul canale sancito. Niente in essa sembra un attacco perché, meccanicamente, è la stessa cosa che il tecnico dell'MSP fa ogni giorno.

Huntress ha riferito che nell'unica organizzazione in cui aveva visibilità l'attività hands-on era ancora iniziale: enumerazione di processi su nove endpoint. È il passo di ricognizione che precede la selezione. Il valore di una compromissione RMM è il fan-out che arriva dopo.

Il tunnel Cloudflare che sopravvive alla revoca del server

Il dettaglio che dovrebbe preoccupare di più i difensori è come gli operatori stabiliscono la persistenza. Sugli endpoint raggiunti, N-able e Huntress hanno osservato un servizio Windows chiamato Cloudflared e un binario svchost.exe depositato nella cartella Documenti di un utente. Cloudflared è il client tunnel legittimo e firmato di Cloudflare. Gli attaccanti lo registrano come servizio per aprire un tunnel in uscita dall'endpoint verso l'edge di Cloudflare, e da lì verso la propria infrastruttura.

"Abbiamo applicato la patch a N-central e revocato il server. Siamo puliti?"

Non necessariamente. Il tunnel non dipende da N-central. Una volta che Cloudflared gira come servizio sull'endpoint, fa beacon per conto proprio — attraverso l'edge di Cloudflare, sulla 443 — indipendentemente dal fatto che il server di gestione che lo ha piazzato esista ancora.

È la parte che rompe la remediation intuitiva. Ripulire il punto d'ingresso non evince una backdoor progettata per esserne indipendente. E poiché Cloudflared è un binario firmato e reputato che apre una normale connessione HTTPS/QUIC in uscita verso Cloudflare — una destinazione con cui metà della tua azienda già parla — gli strumenti endpoint hanno quasi nulla su cui agganciarsi. Nessun hash malevolo, nessun loader non firmato, nessun dominio raro. Gli IOC pubblicati includono IP di exit-node VPN (diversi indirizzi di uscita Mullvad e NordVPN) e domini dead-drop abusati su Synology QuickConnect, come mousears.synology.me e wagoosh.direct.quickconnect.to — infrastruttura deliberatamente insignificante.

L'unico posto in cui tutto questo emerge in modo affidabile è il traffico, come comportamento:

• Un endpoint che storicamente riceve solo traffico di gestione RMM apre all'improvviso sessioni di tunnel in uscita prolungate.
• Un singolo server N-central che avvia sessioni Take Control verso un'insolita ampiezza di endpoint in una finestra breve — la firma del fan-out.
• Nuovi flussi QUIC/443 a lunga durata verso l'edge di Cloudflare da host che non avevano mai usato Cloudflared, che persistono dopo l'isolamento del server di gestione.

Perché l'RMM è il bersaglio di più alto valore sulla tua rete

Non è la prima comparsa di N-able su KEV. Nell'agosto 2025 CISA aggiunse altre due falle di N-central — CVE-2025-8875 e CVE-2025-8876 — dopo sfruttamento in the wild. Il pattern è più vecchio: Kaseya VSA nel 2021, e il bypass RMM di SimpleHelp all'inizio di quest'anno, hanno entrambi trasformato una piattaforma di gestione in un canale di distribuzione. Una compromissione RMM è una compromissione di supply chain puntata verso l'interno — un server, migliaia di endpoint, e un canale fidato che trasporta l'attacco.

È per questo che l'inserimento in KEV richiama BOD 26-04, la direttiva risk-based che a giugno ha sostituito la regola piatta a 14 giorni della BOD 22-01. Un bypass di autenticazione in KEV su un management plane a larga diffusione è esattamente il caso di primo livello — sfruttato e raggiungibile — che la nuova direttiva impone di correggere per primo. Se usi N-central — direttamente o tramite un MSP — sei dentro quel livello, che tu sia un'agenzia federale o meno.

Remediation

Trattalo come un problema in due parti: applicare la patch al server N-central e fare hunting sugli endpoint che potrebbe aver già raggiunto. La sola patch non annulla un pivot Take Control né un tunnel Cloudflared.

1. Sono interessato? Verifica la build di N-central. Qualsiasi versione precedente alla 2026.3.1.7 è vulnerabile a CVE-2026-18577. Gli operatori on-premises ne rispondono direttamente; se un managed service provider gestisce il tuo N-central, fatti confermare per iscritto numero di build e data di patch — la sua esposizione è la tua. N-central non è pensato per essere esposto in internet agli utenti generici: verifica se la tua istanza è raggiungibile dall'esterno e da chi.

2. Patch — versione corretta esatta. Aggiorna a N-central 2026.3.1.7 (2026.3 Hotfix 1) o successiva (advisory N-able, 2 agosto 2026). Non considerare la 2026.2 come corretta — è la patch incompleta. Questo aggiornamento chiude sia CVE-2026-18556 sia CVE-2026-18577.

3. Non puoi applicare la patch subito? Controlli compensativi. Limita l'accesso amministrativo e a Take Control di N-central a una VLAN di gestione o a una VPN; rimuovi qualsiasi esposizione diretta della console su internet. Imponi l'MFA su tutti gli account amministrativi di N-central. Trattandosi di un bypass di autenticazione, l'MFA da sola non basta — l'isolamento di rete è la leva più forte finché la hotfix non è applicata.

4. Hunting della compromissione (IOC + MITRE ATT&CK). Assumi che il server possa già essere stato usato per raggiungere gli endpoint. Cerca:

• Un servizio Windows chiamato Cloudflared, e qualsiasi cloudflared.exe che non hai distribuito tu — T1543.003 (Windows Service), T1572 (Protocol Tunneling).
• svchost.exe in esecuzione dalla cartella Documenti di un utente o da qualsiasi percorso fuori da System32 — T1036.005 (Masquerading: Match Legitimate Name).
• Flussi di tunnel in uscita verso l'edge di Cloudflare da host senza storico Cloudflared, e connessioni verso gli IP degli IOC e i domini QuickConnect/Synology pubblicati — T1090 (Proxy), T1102 (Web Service).
• Nei log di N-central, accessi amministrativi inattesi — T1078 (Valid Accounts) — e un'ampiezza anomala di sessioni Take Control — T1219 (Remote Access Software).
• L'accesso iniziale stesso, nei log del server — T1190 (Exploit Public-Facing Application).

5. Eradica e verifica — nell'ordine giusto. Applicare la patch al server è il primo passo, non il traguardo. Poi: su ogni endpoint che l'N-central compromesso potrebbe aver raggiunto, rimuovi il servizio Cloudflared e l'svchost.exe piazzato, e termina il processo del tunnel — prima di dare per pulito il server di gestione, perché il tunnel è indipendente da esso. Ruota le credenziali amministrative di N-central e ogni credenziale di service-account o di agente transitata dalla piattaforma. Solo allora conferma la pulizia, per assenza: nessun servizio Cloudflared abusivo, nessun flusso di tunnel in uscita, nessuna nuova sessione amministrativa. Verifica dopo la patch, non prima.

Vedere il pivot mentre accade

Tutto ciò che rende efficace questo attacco è un punto cieco per gli strumenti che guardano file e firme: il secondo salto è una funzione legittima, la persistenza è un binario firmato, e il C2 è un normale tunnel HTTPS/QUIC verso una destinazione di cui già ti fidi. L'unica superficie che resta onesta è la rete, perché il comportamento è anomalo anche quando ogni artefatto è legittimo.

È il caso per cui è stato costruito il motore di AI Traffic Analysis di Zero Hunt. Il suo modello di deep learning esegue quattro teste di inferenza in parallelo — traffico sospetto, classificazione del malware, identificazione del tipo di attacco e fingerprinting applicativo — addestrato su miliardi di sequenze PCAP, a un baseline di 2.7+ Gbit/s sulla GPU dell'appliance, interamente on-premises. Non gli serve un hash per Cloudflared né una firma per il tunnel. Segnala la forma: un server di gestione che fa fan-out di sessioni Take Control verso un'ampiezza insolita di endpoint, un endpoint che storicamente solo riceveva traffico RMM e che ora sostiene flussi di tunnel in uscita, una nuova sessione a lunga durata verso l'edge di Cloudflare da un host che non aveva mai parlato quel protocollo — mentre accade, non nel digest SIEM del mattino dopo, e non scomparso nell'istante in cui revochi il server.

La metà relativa alla patch incompleta è dove il pentest generativo a 10 agenti chiude l'altro divario. Poiché ogni exploit è scritto per-bersaglio da un modello locale invece di essere rigiocato da un proof-of-concept fisso, la validazione sonda il percorso di codice vulnerabile, non l'unico input che il primo PoC ha usato. È la differenza tra confermare "la patch 2026.2 blocca la richiesta originale" e confermare "il percorso alternativo verso la stessa funzione privilegiata è davvero chiuso" — che, per CVE-2026-18577, era tutto il punto. Ogni finding validato è firmato ECDSA in scrittura, così l'evidenza che il tuo parco N-central è stato testato e chiuso regge nella conversazione con auditor e assicuratori che segue un incidente RMM.

Se usi N-central, applica oggi la patch alla 2026.3.1.7. Poi vai a cercare sugli endpoint — perché il tunnel è stato progettato per sopravvivere al server che lo ha aperto.