GPU VulnDB

Database/Firmware, BMC & network fabric

OpenBMC phosphor-net-ipmid: unauthenticated RAKP handler leaves default key, allowing BMC login bypass

CVSS 8.1CVE-2026-16141Firmware, BMC & network fabriccurated

Impact

An unauthenticated client on the network can make the RAKP Message 1 handler return early, before it replaces the authentication object's constructor defaults. The session then validates RAKP Message 3 against a constant 20-byte 'userKey' seeded from the string '0penBmc' plus a BMC random number that is often predictable, so an attacker can complete IPMI session setup without knowing any credential. A BMC session is full out-of-band control of the host: power cycling, serial-over-LAN, virtual media, boot order, and on many platforms firmware update. On a GPU fleet that is a path to taking nodes down mid-training or booting an attacker-supplied image under a tenant's workload, and the record notes downstream vendors including NVIDIA and H3C ship phosphor-net-ipmid as their IPMI stack.

Who can reach it

Anyone with network reach to the BMC's IPMI port (UDP 623), typically the management VLAN. No authentication and no valid account are required.

What to do

The record names no fixed OpenBMC release or vendor build. Treat this as mitigate-first: confirm BMC management interfaces are off any tenant-reachable network and reachable only from a hardened jump host, and disable the IPMI/RMCP+ network channel where Redfish already covers your workflows. When your platform vendor ships a corrected BMC image, flashing it is a per-node BMC firmware update; on most server platforms the BMC can be updated with the host running, but plan a maintenance window per node since a failed BMC flash leaves the node unmanageable.

References

Related entries

All Firmware, BMC & network fabric entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.