NVIDIA DGX OS CVE-2026-24218

Exploitation requires three concrete prerequisites: (1) attacker possession of the cloned SSH host private key material from any DGX system provisioned from the same factory base image - obtainable by purchasing, leasing, or compromising one peer DGX appliance; (2) a network on-path or DNS/ARP-redirection position between the legitimate DGX server and the SSH client to intercept connections (reflected in CVSS AC:H); and (3) the victim must be initiating SSH to a DGX hostname/IP the attacker can intercept. Limiting factors: the issue only impacts DGX OS systems provisioned via the affected cloning workflow (DGX Spark per the CPE), AitM positioning is non-trivial outside shared LANs, and deployments using SSH certificate authorities or strict out-of-band fingerprint verification would detect the impersonation.

The CVSS:3.1 vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H yields 8.1 (High): network-reachable, unauthenticated, no user interaction, but with high attack complexity reflecting that the attacker must already possess the cloned key material (e.g., by purchasing or accessing one DGX appliance) and be positioned on a network path between victim and legitimate server to mount an AitM. There is no EPSS score, KEV listing, SSVC decision, or public POC referenced in the provided intelligence, which is consistent with a recently disclosed vendor-reported issue rather than mass-exploited bug. The realistic risk is targeted rather than opportunistic - high for organizations operating multiple DGX systems on shared or hostile networks, lower for isolated lab deployments, but the C/I/A:H triad means a successful AitM can fully compromise SSH-tunneled workloads including model weights and credentials. Note that CPE lists only DGX Spark while the description says 'DGX OS' broadly - defenders should verify exact affected SKUs with NVIDIA before scoping.

An attacker who obtains one DGX appliance (lab loaner, second-hand purchase, or compromised peer system) extracts /etc/ssh/ssh_host_ed25519_key and then, from a network position between an operator's workstation and a target DGX system on a shared corporate or colo network, presents the stolen key during SSH negotiation; because the fingerprint matches the victim's pinned known_hosts entry from a prior session, the operator authenticates and tunnels credentials, training data, or model artifacts through the attacker. No public POC is referenced, but the technique mirrors well-documented historical issues such as Cisco/Juniper shared-key advisories and is straightforward to weaponize with standard SSH MITM tooling like ssh-mitm.