OpenBMC IPMI Privilege Escalation via Retargeted RAKP 1

Executive summary #

OpenBMC's IPMI implementation is vulnerable to a logic flaw where the authorization context of an existing session can be replaced with a target account while still maintaining the original integrity and encryption keys. This effectively allows for privilege escalation without reauthentication.

Technical details #

RAKP12() retrieves a session solely by the BMC session ID. It does not require the session to be in setupInProgress, and it does not bind the request to the peer that opened the session. A second RAKP1 on an established session can target an enabled administrator account, gaining access to that account's username, user ID, requested maximum privilege, privilege fields, channel number, random values, and authentication key.

Critically, the active session's installed integrity and confidentiality objects, packet keys, and sequence state are not cleared. Protected packets made with the low-privilege account's original K1/K2 keys continue to pass packet validation. Set Session Privilege Level evaluates the newly written administrator fields and permits the transition to Administrator. Because the session state never leaves active, provider commands are also forwarded with the relabeled identity and privilege.

The attack steps include:

1. Establish an ordinary active session with a valid low-privilege account (Open Session, RAKP Message 1, RAKP Message 3 with that account's password).
2. On the same session send an additional RAKP Message 1 that targets an enabled administrator account (root).
3. Reissue Set Session Privilege Level to the new privilege level (0x04).
4. Access the IPMI service as the target account.

PoC:

openbmc_rakp_state_poc.py \
  --host bmc --port 623 --timeout 5 --retries 4 \
  --admin-user root --low-user audituser \
  --low-pass 'LabPassphrase1!' --scenario b

B.open_session bmc_sid=0x0a1263b3 low_user='audituser' rakp2=0x00
B.rakp3 low_user status=0x00
B.before_relabel_set_priv_admin protected cc=0x81 data=00
B.relabel_rakp1 target_admin='root' status=0x00 hmac_len=32
B.after_relabel_set_priv_admin_old_keys protected cc=0x00 data=04
B.after_relabel_forwarded_get_device_id protected cc=0x00 data=00808300028d0000000000000000
B.after_relabel_forwarded_get_user_access_slot2 protected cc=0x00 data=0f420032
B.result PASS
B.close_session protected cc=0x00 data=

Before the relabel, Set Session Privilege Level to Administrator is denied (cc=0x81). After a single sessionless RAKP Message 1 naming root on the same session, Set Session Privilege Level raises the session to Administrator (cc=0x00 data=04) using the original packet keys, and the provider-forwarded Get Device ID and Get User Access both succeed (cc=0x00), confirming the active-session forwarding gate stayed open.

Attacker value #

This issue may allow an authenticated low-privilege user to gain administrative access to the IPMI service. The attacker needs a valid IPMI account and the username of an enabled administrator account, but does not need the administrative account's password.

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-16140 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