OpenBMC IPMI Authentication Bypass via Default userKey and Stale Challenge Value

Executive summary #

OpenBMC's IPMI implementation 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.

Technical details #

Each RAKP authentication object initializes a 20-byte userKey array from the seven-byte string 0penBmc, with the remaining 13 bytes set to zero, and declares bmcRandomNum with no initializer. In RAKP12(), the client-supplied remote-console random is copied into the object and a fresh BMC random is generated into a local buffer. A request that asks for CALLBACK privilege triggers UNAUTH_ROLE_PRIV and returns before the fresh random and the configured account password are copied into the object, so userKey keeps the constant 0penBmc value and bmcRandomNum keeps stale heap contents.

RAKP34() retrieves the same session without checking whether RAKP Message 1 succeeded. It computes the expected RAKP Message 3 HMAC from the stale bmcRandomNum, the request-controlled username, the Open Session remote-console session ID and requested privilege, and the unchanged constant key. A matching HMAC installs the integrity and confidentiality algorithms and moves the setup session to active.

Although the stale bmcRandomNum value is 16-bytes, an attacker can predict it, either by guessing a low-entropy heap base address and offset, or by grooming the heap through session creation and timeouts.

To reproduce this, the attacker establishes an RMCP+ session, then sends a RAKP Message 1 that names an enabled account (for example root) and requests the CALLBACK privilege. The server replies back with status 0x0a (the early exit), and the attacker follows this with a RAKP Message 3 whose HMAC is computed with the constant 20-byte userKey using a predicted bmcRandomNum value. The service then replies with a RAKP Message 4 indicating whether the authentication was successful. Accurately predicting bmcRandomNum leaves the session established with the CALLBACK privilege, which can then be escalted to full privileges through an additional RAKP Message 1 with the same session ID (the relabel attack).

Attacker value #

This issue may allow an unauthenticated attacker to establish an authenticated IPMI session without the account password. The attacker only needs network access to the IPMI service and the name of an enabled account (root). The limited CALLBACK session can be escalated to full administrative privileges through a separate vulnerability that uses a secondary RAKP 1 and Set Session Privilege Level request.

Credit #

This issue was discovered by HD Moore and Gadi Evron, with the help of AI tools. Disclosure was coordinated by Tod Beardsley.

Timeline #

• 2026-07-17 (Fri): Initial findings discovered and documented
• 2026-07-17 (Fri): CVE-2026-16141 reserved
• 2026-07-17 (Fri): Vendor notified
• 2026-07-20 (Mon): Initial disclosure acknowledged by the vendor
• 2026-08-20 (Thu): Vendor confirmed a fix in the works
• 2026-09-15 (Tue): Public disclosure (planned)