NoMachine, grave falla mDNS: RCE senza password nelle reti locali. Patch subito

La TrendAI Zero Day Initiative ha pubblicato il 16 settembre 2026 l'advisory ZDI-26-710 su una vulnerabilità nel software di accesso remoto NoMachine che consente esecuzione di codice arbitrario senza richiedere credenziali. La falla, tracciata come CVE-2026-92208, risiede nel parsing dei record mDNS e interessa installazioni esposte nella stessa rete locale dell'attaccante. La coordinata disclosure è avvenuta a circa 40 giorni dalla segnalazione al vendor, con patch disponibili per tre rami di versione.

Il meccanismo: come il parser mDNS diventa un vettore di attacco

Il difetto specifico si colloca nel parsing dei resource record mDNS. Secondo l'advisory ZDI, la causa root è la mancata validazione della lunghezza dei dati utente prima della copia in un buffer allocato sull'heap. Questo errore di programmazione consente a un attaccante di sovrascrivere aree di memoria controllate, concretizzando l'esecuzione di codice nel contesto dell'account di servizio che esegue NoMachine.

Il protocollo mDNS (multicast DNS) opera tipicamente su UDP porta 5353 e permette la risoluzione dei nomi host in reti locali senza server DNS dedicato. La sua natura broadcast lo espone a qualsiasi dispositivo connesso alla stessa infrastruttura di rete: non servono credenziali né privilegi pregressi per iniettare pacchetti malevoli. La combinazione tra assenza di autenticazione e esposizione del servizio mDNS trasforma questa falla da bug di parsing a vettore di compromissione sistemica.

La superficie di attacco: chi è esposto e perché

L'advisory ZDI classifica il vettore come network-adjacent, una distinzione tecnica rilevante: non è sfruttabile da remoto su Internet arbitrario, ma richiede posizionamento nella stessa rete locale della vittima. Questa condizione non ne attenua la gravità in ambienti enterprise, istituzionali e di telemedicina dove NoMachine è ampiamente impiegato per desktop virtuali e accesso remoto a workstation condivise.

In questi contesti, la presenza di dispositivi non autorizzati sulla rete locale — tramite porte di accesso fisico compromesse, reti Wi-Fi guest malsegmentate, o endpoint precedentemente infetti — può fornire il posizionamento necessario all'attacco. Il servizio mDNS, quando attivo, annuncia la presenza dell'istanza NoMachine rendendo il target individuabile senza scansione attiva. Il dossier non specifica se il servizio mDNS sia abilitato di default o configurabile dall'amministratore: questo dato mancante costituisce un limite significativo per la valutazione dell'esposizione effettiva delle installazioni esistenti.

"This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of NoMachine. Authentication is not required to exploit this vulnerability." — Advisory ZDI-26-710

Timeline coordinata e disponibilità delle patch

La vulnerabilità è stata segnalata al vendor il 7 agosto 2026. La pubblicazione coordinata dell'advisory è avvenuta il 16 settembre 2026, con il record CVE-2026-92208 pubblicato il giorno precedente in stato reserved. Questo intervallo di circa 40 giorni tra segnalazione e disclosure riflette la finestra standard di coordinamento ZDI, sebbene non sia documentato se siano state rilasciate patch intermedie o mitigazioni temporanee nel periodo.

Le versioni che risolvono la vulnerabilità sono NoMachine v10.1.7, v9.9.6 e v8.27.1. L'advisory non elenca le versioni specifiche vulnerabili, indicando solo le release corrette: questo costringe gli operatori a verificare la propria versione installata contro l'elenco delle patch disponibili, senza poter escludere a priori che versioni intermedie o precedenti siano interessate.

Il punteggio CVSS e il vettore di punteggio non sono esplicitati nell'advisory ZDI disponibile. Non è possibile quindi posizionare la vulnerabilità con precisione nelle scale di severità standard senza ricorrere a valutazioni indipendenti. Analogamente, l'identità del ricercatore o dell'entità che ha scoperto la falla non risulta dai testi esaminati.

Cosa fare adesso

Le organizzazioni che impiegano NoMachine dovrebbero verificare immediatamente la versione in esecuzione e pianificare l'aggiornamento alle release patchate. Data la natura pre-autenticazione della vulnerabilità e la tipica criticità del servizio di accesso remoto nelle architetture che lo ospitano, la prioritizzazione dell'intervento è elevata.

È opportuno verificare se il servizio mDNS sia attivo nelle installazioni correnti e valutarne la necessità operativa: dove il discovery automatico non è essenziale, la sua disabilitazione può ridurre la superficie esposta anche prima dell'applicazione della patch. La segmentazione della rete locale, sebbene non menzionata nell'advisory come mitigazione specifica, rappresenta una barriera naturale contro il vettore network-adjacent.

Le installazioni su reti condivise — incluse reti Wi-Fi aziendali, ambienti istituzionali e infrastrutture di telemedicina — meritano attenzione prioritaria per la maggiore probabilità di presenza di dispositivi non autorizzati. Il monitoraggio del traffico mDNS anomalo sulla porta 5353 può offrire indicatori di tentativi di sfruttamento, sebbene l'advisory non documenti signature specifiche.

L'assenza di evidenza documentata di sfruttamento in-the-wild non esime dalla prontezza: la pubblicazione dell'advisory ZDI espone dettagli tecnici sufficienti a permettere la costruzione di exploit da parte di attori con competenze di reverse engineering sulle versioni non patchate.

Il contesto più ampio: i protocolli di discovery come perimetro dimenticato

La vulnerabilità ZDI-26-710 si inserisce in un pattern più ampio di debolezze legate all'implementazione di protocolli di discovery zero-configuration in software critici per l'accesso remoto. Il mDNS, progettato per semplificare la connettività in reti locali, introduce complessità di parsing che raramente riceve la stessa attenzione security-oriented riservata ai protocolli di trasporto principali. L'heap-based buffer overflow in questo contesto dimostra come la facilità d'uso del discovery automatico possa tradursi in un vettore di compromissione sistemica quando l'implementazione non valida rigorosamente i dati in ingresso.

L'industria ha già osservato vulnerabilità mDNS con impatto significativo in altri prodotti, inclusi eventi dimostrati in contesti di ricerca come Pwn2Own. La ricorrenza di questo pattern solleva interrogativi sulla maturità dei processi di secure coding applicati alle implementazioni di protocolli di discovery, spesso trattati come componenti accessorie piuttosto che come elementi del perimetro di sicurezza. La mancanza, nel dossier, di dettagli sulle pratiche di sviluppo di NoMachine impedisce di avanzare valutazioni specifiche in questo senso, ma la natura della falla — mancata validazione della lunghezza — indica una carenza nei controlli di bounds-checking classici.

La pubblicazione coordinata di ZDI-26-710, con CVE assegnato e patch disponibili, rappresenta un esempio di disclosure responsabile. Tuttavia, la persistenza di installazioni su rami di versione precedenti al v10, documentata dalla necessità di rilasciare patch anche per la v8.27.1, suggerisce una base installata frammentata che complica la risposta agli incidenti. Gli operatori di sicurezza devono mappare le versioni attive nei propri ambienti, inclusi eventuali deployment legacy, per assicurare copertura completa delle patch.

Non emergono, allo stato attuale, sovrapposizioni infrastrutturali che colleghino questa vulnerabilità a campagne di attacco note o a specifici gruppi di threat actor. L'attribuzione e il movente rimangono non documentati nel materiale disponibile.

Fonti

• http://www.zerodayinitiative.com/advisories/ZDI-26-710/
• http://www.zerodayinitiative.com/advisories/published/
• https://www.cve.org/CVERecord?id=CVE-2026-92208
• http://www.zerodayinitiative.com/advisories/upcoming/
• https://www.trendmicro.com/
• https://www.trendmicro.com/en_us/business/products/one-platform.html