CVE-2026-24218: NVIDIA DGX OS RCE Vulnerability

CVE-2026-24218 Overview

NVIDIA DGX OS contains a hard-coded cryptographic key vulnerability [CWE-321] introduced during factory provisioning. The cloning of a base image deploys identical SSH host keys across multiple DGX systems. Every system provisioned from the same image shares the same private host key material. Attackers who obtain the key from any one system can impersonate any other system that shares it. This enables attacker-in-the-middle (AiTM) attacks against SSH sessions targeting affected DGX hosts.

Critical Impact

Successful exploitation can lead to remote code execution, data tampering, privilege escalation, information disclosure, and denial of service against NVIDIA DGX systems.

Affected Products

• NVIDIA DGX OS (factory-provisioned systems built from cloned base image)
• DGX hardware platforms running affected DGX OS images
• Refer to the NVIDIA Support Response for the authoritative product and version list

Discovery Timeline

• 2026-05-20 - CVE-2026-24218 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-24218

Vulnerability Analysis

The vulnerability stems from a flaw in NVIDIA's DGX OS factory provisioning workflow. SSH host keys are generated once and embedded into a master image. That image is then cloned across many DGX systems shipped to customers. The result is a fleet of distinct machines that all present identical SSH host key fingerprints.

SSH host keys exist to cryptographically bind a server identity to a specific machine. When a client first connects, it pins the fingerprint in known_hosts and uses it to detect impersonation on subsequent connections. Shared keys destroy this guarantee. Any party with access to one DGX system can extract /etc/ssh/ssh_host_*_key and reuse it to masquerade as another.

The attack vector is network-based and requires no authentication or user interaction. Attack complexity is high because the adversary must obtain the private key material and position themselves on a network path between the client and a target DGX host. Once those conditions are met, the attacker can decrypt or modify SSH traffic, capture credentials, inject commands, or deliver tampered data to administrators.

Root Cause

The root cause is improper provisioning logic that fails to regenerate per-host cryptographic identifiers after image cloning. Host key regeneration via ssh-keygen -A or equivalent first-boot logic was not enforced. This is a textbook instance of [CWE-321: Use of Hard-coded Cryptographic Key] applied to SSH server identity material.

Attack Vector

An attacker first acquires the shared private host key from any accessible DGX system, a recovered disk image, or a leaked backup. The attacker then establishes a network position between an administrator and a target DGX host through ARP spoofing, DNS poisoning, BGP hijacking, or rogue infrastructure. The attacker presents the stolen host key, completes the SSH handshake as the legitimate server, and proxies or manipulates the session. Because the fingerprint matches the client's known_hosts entry, no warning is shown.

No verified public exploit code is available. See the NVIDIA Support Response for vendor technical details.

Detection Methods for CVE-2026-24218

Indicators of Compromise

• Identical SSH host key fingerprints reported by ssh-keyscan across two or more DGX systems that should be cryptographically distinct
• Unexpected SSH host key change warnings on clients after the patch is applied, indicating regeneration occurred
• Anomalous SSH sessions originating from network segments that should not host DGX management traffic
• ARP table, DNS, or routing anomalies on networks carrying DGX administrative SSH connections

Detection Strategies

• Inventory SSH host key fingerprints across all DGX systems and flag any duplicates using ssh-keyscan followed by hash comparison
• Compare /etc/ssh/ssh_host_ed25519_key.pub, ssh_host_rsa_key.pub, and ssh_host_ecdsa_key.pub fingerprints across the fleet
• Monitor for SSH sessions to DGX hosts arriving from unexpected source addresses or at unusual times
• Correlate SSH authentication logs with network telemetry to identify potential AiTM positioning

Monitoring Recommendations

• Centralize SSH server and client logs and alert on host key mismatch events post-remediation
• Deploy network detection for ARP spoofing and rogue gateway activity on subnets carrying DGX management traffic
• Track administrator workstation known_hosts files for entries that resolve to shared fingerprints
• Audit privileged sessions to DGX systems for command patterns inconsistent with operator baselines

How to Mitigate CVE-2026-24218

Immediate Actions Required

• Apply the fix described in the NVIDIA Support Response to all affected DGX systems
• Regenerate SSH host keys on every DGX host using sudo rm /etc/ssh/ssh_host_* followed by sudo dpkg-reconfigure openssh-server or sudo ssh-keygen -A
• Restart sshd and distribute the new fingerprints to administrators through an out-of-band channel
• Purge stale entries from administrator known_hosts files and re-pin the new fingerprints

Patch Information

NVIDIA has published guidance and remediation steps in the NVIDIA Support Response. Refer to the NVD CVE-2026-24218 Detail and the CVE.org Record for CVE-2026-24218 for authoritative references. Apply vendor updates before performing any host key regeneration steps to ensure first-boot logic operates correctly going forward.

Workarounds

• Restrict SSH access to DGX systems to a dedicated, authenticated management network or bastion host
• Enforce SSH certificate-based host authentication signed by an internal certificate authority instead of relying solely on raw host keys
• Require multi-factor authentication and session recording for all administrative access to DGX hardware
• Segment DGX management traffic with private VLANs and disable SSH on untrusted interfaces until host keys are regenerated

# Regenerate per-host SSH keys on a DGX system after patching
sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh

# Capture and distribute the new fingerprints
for key in /etc/ssh/ssh_host_*_key.pub; do
  ssh-keygen -lf "$key"
done