Introduction
When every node in an NVIDIA DGX AI cluster shares the same SSH private keys, a single compromised host becomes a skeleton key for the entire fleet. That provisioning oversight is what CVE-2026-24218 describes. The DGX OS factory provisioning process clones a golden image that already contains pre-generated SSH host keys, so every system built from that image is cryptographically indistinguishable from every other.
NVIDIA DGX systems ship preinstalled with DGX OS and are turnkey platforms for enterprise AI and analytics workloads. The DGX platform is widely deployed in data centers running large-scale machine learning training and inference, and the DGX Ready Software Program extends this ecosystem with enterprise-grade MLOps tooling for cluster management, scheduling, and orchestration. DGX OS also runs on partner hardware such as the HP ZGX Nano for AI Development, which widens the set of systems that may be affected.
Technical Information
The vulnerability is classified under CWE-321 (Use of Hard-coded Cryptographic Key). During factory provisioning, SSH host keys and the system's machine identifier are generated on the first system and then captured into a golden image. That image is cloned to all other DGX nodes. As a result, every provisioned system shares identical cryptographic material.
The CVSS v3.1 vector string is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, for a base score of 8.1. The attack is network accessible and requires no privileges and no user interaction. Attack complexity is high because the attacker needs a suitable network position. Impacts on confidentiality, integrity, and availability are all rated high.
Affected Files
The following files are duplicated across all systems provisioned from the same golden image:
/etc/ssh/ssh_host_ecdsa_keyand/etc/ssh/ssh_host_ecdsa_key.pub/etc/ssh/ssh_host_ed25519_keyand/etc/ssh/ssh_host_ed25519_key.pub/etc/ssh/ssh_host_rsa_keyand/etc/ssh/ssh_host_rsa_key.pub/etc/machine-id
Why This Matters
SSH host keys are the foundation of the SSH trust model. When a client connects to a server, it verifies the server's identity by checking the presented host key against its known_hosts file. If two servers present the same host key, the client cannot tell them apart. SSH works this way by design, because it assumes every system has its own unique host key.
Attack Flow
An attacker who can get between a client and a target DGX node on the network can exploit this vulnerability in the following sequence:
-
Network positioning. The attacker gains access to the network segment where DGX nodes communicate. In data center environments, an attacker could do this through a compromised adjacent host, a misconfigured switch, ARP spoofing, or BGP hijacking.
-
Host impersonation. The attacker intercepts an SSH connection meant for a legitimate DGX node. Because all nodes share the same host private key, the attacker presents the identical key material. The connecting client checks the key against its
known_hostsentry and accepts the connection as authentic. -
Session interception. From the attacker-in-the-middle position, the attacker can relay traffic between the client and the real server while inspecting or modifying it in transit. That lets the attacker inject commands into SSH sessions, exfiltrate credentials and data, tamper with AI training data or model parameters, and escalate privileges by hijacking administrative sessions.
-
Lateral movement. An attacker who extracts the SSH host private keys from any single DGX node (even one they legitimately have access to) now has the private keys for every other node provisioned from the same image. This dramatically lowers the barrier to impersonating any node in the cluster.
The high rating for attack complexity in the CVSS score reflects the need for network positioning. That position is realistic in the data center environments where DGX clusters operate, particularly if an attacker has already established an initial foothold.
Remediation Steps
For systems already deployed, administrators should check whether the SSH host key files are duplicated across nodes. If they are, administrators must regenerate the keys:
rm /etc/ssh/ssh_host_* ssh-keygen -A
After regenerating the keys, administrators should also check the /etc/machine-id file and regenerate it if it matches across systems.
For future deployments, NVIDIA recommends capturing the golden image before the system's first boot, so the SSH host keys and the machine identifier have not yet been generated when the image is captured.
NVIDIA has also released an official update that addresses the vulnerability. All affected systems should be updated to version OTA0.
Affected Systems and Versions
This vulnerability affects NVIDIA DGX Spark products running NVIDIA DGX OS on all versions prior to OTA0. Systems provisioned from a cloned golden image that included pre-generated SSH host keys are vulnerable regardless of when they were deployed. Partner hardware running DGX OS, such as the HP ZGX Nano for AI Development, may also be affected if it was provisioned through the same cloning workflow.
