Dell iDRAC9 (IPMI 2.0 over LAN): iDRAC9 generates predictable IPMI 2.0 session IDs, so an attacker can hijack somebody

Impact

iDRAC9 generates predictable IPMI 2.0 session IDs, so an attacker can hijack somebody else's live IPMI session rather than authenticate as themselves. The stolen session carries whatever privilege the legitimate user had - typically chassis power control, boot device selection, and sensor/SEL access. For a GPU fleet the concrete outcomes are unauthorised power cycling of running training nodes and boot-order manipulation that sets up an attacker-controlled boot on the next restart. Spans 14G, 15G and 16G PowerEdge, which is most of the current GPU-server installed base.

Who can reach it

Anything that can reach UDP 623 on the iDRAC address, plus the ability to observe or race a legitimate IPMI session. That means the OOB management VLAN, and in practice any automation host, monitoring collector, or DCIM system that already speaks IPMI to the fleet.

What to do

Flash iDRAC9 to 7.00.00.172 (14G) or 7.10.50.00 (15G/16G) or later - out-of-band, per-node, no host reboot and no drain of running jobs. The strong config-only mitigation here is to disable IPMI over LAN entirely: Redfish and racadm cover everything modern tooling needs, and turning IPMI off removes an entire legacy attack surface rather than patching one bug in it. Budget for the tooling migration if any of your automation still speaks ipmitool.

References