Description

OpenBMC's IPMI implementation, phosphor-net-ipmid, contains a logic flaw in which an unauthenticated client can force the RAKP Message 1 handler to return before it overwrites the authentication object's constructor defaults. The IPMI service then accepts a RAKP Message 3 whose HMAC is computed with the constant 20-byte 'userKey' initialized from the string '0penBmc' and an often-predictable 'bmcRandomNum'. Several downstream vendors implement phosphor-net-ipmid as their IPMI stack, such as NVIDIA and H3C.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-15T14:16:50.430Z",
  "pubdate": "2026-09-15T14:16:50.430Z",
  "executiveSummary": "A critical logic flaw exists in the RAKP (Remote Authentication/Authorization Key Pseudo-random function) Message 1 handler within the OpenBMC phosphor-net-ipmid implementation. This vulnerability allows an unauthenticated remote attacker to bypass IPMI authentication mechanisms by forcing an early return in the session establishment process. By interrupting the initialization sequence, the system fails to overwrite the default authentication object parameters, specifically the userKey and bmcRandomNum. Consequently, the service proceeds to process RAKP Message 3 using these predictable, hardcoded values to compute the HMAC, effectively authenticating the attacker without valid credentials. The vulnerability impacts multiple downstream vendors, including NVIDIA and H3C, who utilize this IPMI stack. Successful exploitation grants an unauthorized entity full control over the IPMI interface, leading to complete system compromise, including the ability to power cycle the host, modify firmware, or exfiltrate sensitive hardware management data. Given the network-exposed nature of IPMI interfaces, this flaw poses a severe risk to infrastructure security.",
  "technicalDetails": "The vulnerability resides in the state management logic of the RAKP message handling sequence within phosphor-net-ipmid. IPMI 2.0 session establishment relies on a sequence of RAKP messages to facilitate mutual authentication. Under normal operations, the server generates a cryptographically secure, random bmcRandomNum and derives a transient session key based on the user's password.\nThe root cause is a race condition or conditional logic error in the RAKP Message 1 handler. An unauthenticated client can send a crafted request that triggers an early function return before the session object's constructor or initialization logic completes the update of internal security state variables. Specifically, the object retains its default, pre-initialized state.\nThe default authentication parameters are hardcoded with a 20-byte userKey initialized from the ASCII string '0penBmc'. Because the object is not correctly updated with user-specific or session-specific entropy, the 'bmcRandomNum' remains static or predictable. When the attacker sends RAKP Message 3, the service validates the HMAC using these static defaults rather than the correct values derived from the intended session parameters.\nThe attack flow proceeds as follows: 1) The attacker initiates an IPMI session, sending a RAKP Message 1 request designed to force an early exit in the server's handler. 2) The server aborts the initialization of the authentication object, preserving the '0penBmc' userKey and a static 'bmcRandomNum'. 3) The attacker constructs a malicious RAKP Message 3, calculating the HMAC using the known '0penBmc' key. 4) The phosphor-net-ipmid service receives the message and performs an HMAC verification check. Because the service is using the static defaults due to the interrupted constructor, the HMAC verification succeeds despite the attacker lacking the actual user password. 5) The server promotes the attacker's connection to an authenticated session state.\nThis vulnerability requires no prior authentication and can be executed over the network if the IPMI interface is accessible. The impact is absolute, as it provides an attacker with administrative access to the Baseboard Management Controller (BMC), which typically operates at a higher privilege level than the host operating system, allowing for persistent, low-level system subversion."
}