MSI EdgeXpert DGX Spark having identical Machine IDs

Accelerated Computing DGX Spark / GB10 User Forum DGX Spark / GB10
1

This will probably only applies to people who have purchased the MSI EdgeXpert version of the Spark, but even if you have a different model, might worth checking out.

Hi. I have two DGX Sparks from MSI. After finishing setup and SSH into the boxes, I noticed something strange: Their SSH Host Keys are exactly the same, which should have been impossible.

So I checked the devices’ machine IDs that is used to generate those keys. Lo and behold:

user@edgexpert-1:~$ cat /etc/machine-id 
295f5139615f4bbaa29921a29574c7a3
user@edgexpert-2:~$ cat /etc/machine-id 
295f5139615f4bbaa29921a29574c7a3

And then I throw this exact machine ID into Google and I found this thread

 1월 20 04:44:12 edgexpert-8de4 systemd-journald[830]: File /var/log/journal/295f5139615f4bbaa29921a29574c7a3/user-1000.journal corrupted or uncleanly shut down, renaming and replacing.

Are these things supposed to have completely identical Machine IDs (would be a massive issue) or did MSI/Nvidia failed to properly sanitize their factory OS images?

2

This is CVE-2026-24218. See NVD - CVE-2026-24218 and Security Bulletin: NVIDIA DGX Spark - May 2026.

3

Asus GX10 has the same issue. Basically because the clone the image, not a big issue, just refresh the Machine ID.

4

It actually is kinda a big deal if it wasn’t known, CNSS 8.1 after all. Reason being that, since SSH host keys being the same, someone could perfectly impersonate your Spark over SSH without you knowing.

And other things may break too like IPv6 that relies on DUID for its address generation which uses machine-id on Linux.

5

Calm down, don’t panic !

  1. Machine ID same doesn’t necessary means SSH host keys are the same.
  2. Even if SSH Host keys are the same (won’t be the first time Nvidia has done that) , host key only authenticate the keychange. You will still need an on-path attacker who can redirect a active connection.
  3. DUID is only used by stateful DHCPv6. Doesn’t affect SLAAC.
  4. Probably security best practices to always setup new machine-id and regenerate crypto keys etc.

** Or upgrade the patches as soon as you boot up. Seems like MSI patched this in May 2026.

6

Ah no don’t worry, I’m just saying those couple things could be an issue, not that they are 😅.

I’m just a bit baffled this isn’t addressed in like a package update during initial setup (I set these up today, guess OEMs are still shipping the original DGX OS image), perhaps we could have something in pre/postinst of an update that goes “if machine_id in (list of known keys): reset()”.

Oh and just for the people who (like me) googled their machine-id and ends up here, here’s the one liner

sudo rm -f /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup && sudo rm -f /etc/ssh/ssh_host_* && sudo ssh-keygen -A && sudo reboot
7

https://forum-en.msi.com/index.php?threads/nvidia-dgx-os-security-update-notice-for-msi-edgexpert-users-cve-2026-24218.419217/

8

Adding one more thing the shared machine-id quietly breaks, since it’s not in the bulletin — fwupd firmware reporting.

fwupd hashes /etc/machine-id into the report ID it sends LVFS, so every un-refreshed unit reports the same ID and LVFS bans it as spam:

server rejected report: abuse detected, 93bcc022…dd21e5 is banned

So firmware telemetry just silently goes nowhere until you happen to notice. @ohaibuzzle’s one-liner fixes this too — the exact report that got banned uploaded fine right after I regenerated.

(Small tell for the SSH side while I was in there: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub showed root@localhost on mine — a key generated on-device would show the hostname. Flipped to root@spark-65bd after regen.)

If anyone else pre-patch sees that same 93bcc022… hash, that’d confirm it’s fleet-wide and not just me.