NoMachine Critical mDNS Flaw: Unauthenticated RCE on Local Networks. Patch Now

The Trend Micro Zero Day Initiative published advisory ZDI-26-710 on September 16, 2026, covering a vulnerability in the NoMachine remote access software that enables unauthenticated arbitrary code execution. Tracked as CVE-2026-92208, the flaw resides in the parsing of mDNS records and affects installations exposed on the same local network as the attacker. Coordinated disclosure occurred roughly 40 days after vendor notification, with patches released for three version branches.

The Mechanism: How the mDNS Parser Becomes an Attack Vector

The specific defect lies in the parsing of mDNS resource records. According to the ZDI advisory, the root cause is the failure to validate the length of user-supplied data before copying it into a heap-allocated buffer. This programming error allows an attacker to overwrite controlled memory regions, achieving code execution in the context of the service account running NoMachine.

The mDNS (multicast DNS) protocol typically operates on UDP port 5353 and enables hostname resolution on local networks without a dedicated DNS server. Its broadcast nature exposes it to any device connected to the same network infrastructure: no credentials or prior privileges are needed to inject malicious packets. The combination of missing authentication and mDNS service exposure turns this bug from a parsing flaw into a systemic compromise vector.

The Attack Surface: Who Is Exposed and Why

The ZDI advisory classifies the vector as network-adjacent, a technically significant distinction: it is not exploitable from arbitrary remote internet locations, but requires positioning on the same local network as the victim. This condition does not diminish severity in enterprise, institutional, and telemedicine environments where NoMachine is widely used for virtual desktops and remote access to shared workstations.

In these contexts, the presence of unauthorized devices on the local network — via compromised physical access ports, missegmented guest Wi-Fi networks, or previously infected endpoints — can provide the necessary positioning for an attack. The mDNS service, when active, announces the presence of the NoMachine instance, making the target discoverable without active scanning. The dossier does not specify whether the mDNS service is enabled by default or configurable by the administrator: this missing data constitutes a significant limitation for assessing the actual exposure of existing installations.

"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

Coordinated Timeline and Patch Availability

The vulnerability was reported to the vendor on August 7, 2026. Coordinated publication of the advisory occurred on September 16, 2026, with the CVE-2026-92208 record published the previous day in reserved state. This roughly 40-day window between reporting and disclosure reflects the standard ZDI coordination window, though it is not documented whether intermediate patches or temporary mitigations were released during the period.

The versions that resolve the vulnerability are NoMachine v10.1.7, v9.9.6, and v8.27.1. The advisory does not list specific vulnerable versions, indicating only the fixed releases: this forces operators to verify their installed version against the list of available patches, without being able to rule out a priori that intermediate or earlier versions are affected.

The CVSS score and scoring vector are not stated in the available ZDI advisory. It is therefore not possible to precisely position the vulnerability on standard severity scales without resorting to independent assessments. Similarly, the identity of the researcher or entity that discovered the flaw does not appear in the examined texts.

Immediate Actions

Organizations running NoMachine should immediately verify the running version and plan upgrades to the patched releases. Given the pre-authentication nature of the vulnerability and the typical criticality of the remote access service in architectures hosting it, prioritization of remediation is high.

It is advisable to verify whether the mDNS service is active in current installations and assess its operational necessity: where automatic discovery is not essential, disabling it can reduce the exposed surface even before patch application. Local network segmentation, while not mentioned in the advisory as a specific mitigation, represents a natural barrier against the network-adjacent vector.

Installations on shared networks — including corporate Wi-Fi, institutional environments, and telemedicine infrastructure — warrant priority attention due to the higher likelihood of unauthorized device presence. Monitoring for anomalous mDNS traffic on port 5353 can offer indicators of exploitation attempts, though the advisory does not document specific signatures.

The absence of documented evidence of in-the-wild exploitation does not relieve urgency: publication of the ZDI-26-710 advisory exposes sufficient technical detail to allow exploit construction by actors with reverse-engineering skills against unpatched versions.

The Broader Context: Discovery Protocols as a Forgotten Perimeter

Vulnerability ZDI-26-710 fits a broader pattern of weaknesses tied to the implementation of zero-configuration discovery protocols in software critical for remote access. mDNS, designed to simplify connectivity on local networks, introduces parsing complexity that rarely receives the same security-oriented attention reserved for primary transport protocols. The heap-based buffer overflow in this context demonstrates how the convenience of automatic discovery can translate into a systemic compromise vector when implementation fails to rigorously validate inbound data.

The industry has already observed significant-impact mDNS vulnerabilities in other products, including events demonstrated in research contexts like Pwn2Own. The recurrence of this pattern raises questions about the maturity of secure coding processes applied to discovery protocol implementations, often treated as ancillary components rather than security perimeter elements. The lack, in the dossier, of details on NoMachine development practices prevents specific assessments in this regard, but the nature of the flaw — missing length validation — indicates a deficiency in classic bounds-checking controls.

The coordinated publication of ZDI-26-710, with an assigned CVE and available patches, represents an example of responsible disclosure. However, the persistence of installations on version branches prior to v10, documented by the need to release patches even for v8.27.1, suggests a fragmented installed base that complicates incident response. Security operators must map active versions in their environments, including any legacy deployments, to ensure complete patch coverage.

No infrastructural overlaps currently emerge linking this vulnerability to known attack campaigns or specific threat actor groups. Attribution and motive remain undocumented in the available material.

Sources

• 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