EUVD-2026-31142
GHSA-849r-hj58-p84g
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from Vendor (nvidia) · only source for this CVE.
CVSS VectorVendor: nvidia
Lifecycle Timeline
1DescriptionCVE.org
NVIDIA DGX OS contains a vulnerability in the factory provisioning process, where the cloning of a base image causes identical SSH host keys to be deployed across multiple systems. The sharing of cryptographic identifiers across all similarly provisioned systems enables host impersonation or attacker-in-the-middle attacks. A successful exploit of this vulnerability might lead to code execution, data tampering, escalation of privileges, information disclosure, and denial of service.
AnalysisAI
Host impersonation and machine-in-the-middle attacks against NVIDIA DGX OS systems are possible because the factory provisioning process clones a base image that ships identical SSH host keys onto every similarly provisioned system, primarily affecting DGX Spark deployments. With a CVSS of 8.1 and a CWE-321 (Use of Hard-Coded Cryptographic Key) root cause, an unauthenticated network attacker who possesses the shared key material from any one device can impersonate peers, potentially leading to code execution, data tampering, privilege escalation, information disclosure, or denial of service. There is no public exploit identified at time of analysis and the CVE is not listed in CISA KEV.
Technical ContextAI
The vulnerability stems from NVIDIA's factory provisioning workflow for DGX OS, the Ubuntu-derived operating system shipped on NVIDIA's DGX AI/ML appliances (CPE cpe:2.3:a:nvidia:dgx_spark identifies DGX Spark as the affected product). During image cloning, the SSH server's host key pair (typically generated once per host by openssh-server on first boot) was baked into the master image rather than regenerated per device, so every appliance provisioned from that image presents the same /etc/ssh/ssh_host_*_key fingerprint. This is a textbook CWE-321 (Use of Hard-Coded Cryptographic Key) condition: the cryptographic identity intended to uniquely bind a TLS/SSH endpoint becomes a shared secret across the fleet, defeating SSH's trust-on-first-use and known_hosts pinning protections that normally detect impostor servers.
RemediationAI
Follow NVIDIA's security bulletin at https://nvidia.custhelp.com/app/answers/detail/a_id/5835 for the official fix; patch status from the available data corresponds to 'Patch available per vendor advisory' without an exact fixed version enumerated in the provided intelligence. Operationally, regenerate unique SSH host keys on every affected DGX system by deleting /etc/ssh/ssh_host_*_key* and running dpkg-reconfigure openssh-server (or ssh-keygen -A), then restart sshd and purge stale entries from all clients' known_hosts files - note the side effect that legitimate users will see host-key-changed warnings and must re-pin the new fingerprints out of band. As compensating controls until remediation, restrict SSH access to DGX management interfaces to trusted management VLANs, require certificate-based SSH host authentication via an internal CA rather than TOFU fingerprint pinning, and audit any inter-DGX SSH trust relationships for replay or impersonation exposure.
NULL pointer dereference in NVIDIA DGX Spark system firmware enables a local privileged attacker to achieve code executi
Out-of-bounds write in NVIDIA DGX Spark system firmware enables a privileged local attacker to corrupt memory and achiev
Out-of-bounds write in NVIDIA DGX Spark system firmware permits a locally authenticated, highly privileged attacker to c
UEFI protection mechanism failure in NVIDIA DGX Spark allows a privileged local user to bypass the UEFI administrator pa
Out-of-bounds read in the NVIDIA DGX Spark standalone Memory Management (MM) firmware enables a local high-privileged at
Same weakness CWE-321 – Use of Hard-coded Cryptographic Key
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today