Introduction
Every node in an NVIDIA DGX AI cluster sharing the same SSH private keys is the kind of provisioning oversight that turns a single compromised host into a skeleton key for the entire fleet. CVE-2026-24218 exposes exactly this scenario: the DGX OS factory provisioning process clones a golden image complete with pre-generated SSH host keys, meaning every system built from that image is cryptographically indistinguishable from every other.
NVIDIA DGX systems ship preinstalled with DGX OS and serve as 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, broadening the footprint of potentially affected systems.
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, then captured into a golden image. That image is subsequently cloned to all other DGX nodes. The 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, yielding a base score of 8.1. The attack is network accessible, requires no privileges and no user interaction, but carries high attack complexity due to the need for 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 distinguish between them. This is by design: SSH assumes host keys are unique per system.
Attack Flow
An attacker who can position themselves on the network between a client and a target DGX node can exploit this vulnerability through the following sequence:
-
Network positioning. The attacker gains access to the network segment where DGX nodes communicate. In data center environments, this could be achieved through a compromised adjacent host, a misconfigured switch, ARP spoofing, or BGP hijacking.
-
Host impersonation. The attacker intercepts an SSH connection destined for a legitimate DGX node. Because all nodes share the same host private key, the attacker presents the identical key material. The connecting client validates the key against its
known_hostsentry and accepts the connection as authentic. -
Session interception. With the attacker in the middle position established, the attacker can relay traffic between the client and the real server while inspecting or modifying it in transit. This enables command injection into SSH sessions, exfiltration of credentials and data, tampering with AI training data or model parameters, and privilege escalation 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 possesses 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 attack complexity rating in the CVSS score reflects the requirement for network positioning, but this is a realistic scenario in the data center environments where DGX clusters operate, particularly if an attacker has already established an initial foothold.
Remediation Steps
For already deployed systems, administrators should verify whether the SSH host key files are duplicated across nodes. If they are, the keys must be regenerated:
rm /etc/ssh/ssh_host_* ssh-keygen -A
After regeneration, the /etc/machine-id file should also be checked and regenerated if it matches across systems.
For future deployments, NVIDIA recommends capturing the golden image before the initial boot of the system, ensuring SSH host keys and the machine identifier have not yet been generated at the time of image capture.
NVIDIA has also released an official update: all affected systems should be updated to version OTA0, which addresses the vulnerability.
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 provisioned through the same cloning workflow.
