The IPMI 2.0 authenticated-session mechanism as specified and as implemented across multiple vendors: An attacker

Impact

An attacker hijacks an established IPMI session by spoofing packets with a predicted session ID, bypassing authentication entirely. What they inherit is the privilege of whoever's session they stole - typically an operator or automation account with power control, boot-device selection, sensor access and often virtual media. This is a spec-level weakness rather than one vendor's bug, so it is one of the few entries here that an operator should assume applies to their whole heterogeneous fleet, not just the boards from one manufacturer. Session IDs are predictable and BMC random number generation is weak, so the values that are supposed to make a session unforgeable are guessable. CERT/CC tracks it as VU#163057 and the affected list spans vendor BMC implementations built to the Intel IPMI specification.

Who can reach it

Network reachability to the BMC's IPMI-over-LAN port (UDP 623) with the ability to observe or infer session state. Unauthenticated in effect, since the whole point is that authentication is bypassed. Anything on the out-of-band management VLAN qualifies, as does anything that can reach a BMC exposed by a routing mistake.

What to do

Firmware updates exist from individual vendors, but there is no single fix because the weakness is in the protocol's assumptions - so the durable remediation is to stop using IPMI-over-LAN. Disable IPMI-over-LAN on the BMC and drive management through Redfish over TLS instead; that is a config-only change on most modern BMCs and is the single highest-value action in this entire database for an operator who still has UDP 623 open. Where legacy tooling forces IPMI, restrict UDP 623 to an explicit allowlist of management hosts at the switch, and treat the management VLAN as a network where session hijacking is assumed possible.

References