Supermicro ATEN RAKP Authentication Bypass

Executive summary #

The ATEN RMCP+ key-exchange handler accepts RAKP Message 3 without requiring the preceding RAKP Message 1, allowing an unauthenticated network attacker to establish a session using the stored key for user record 0. On observed X11DPT-PS and H13 systems, this enables a restricted IPMI session and Serial-over-LAN access to the managed host's serial console, but not the full administrative IPMI command surface. On X10DSC+, record 0 is already enabled and directly authenticable, so the issue provides no additional access. This vulnerability has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N (7.4, High), and is an instance of CWE-841 (Improper Enforcement of Behavioral Workflow); CWE-457 (Use of Uninitialized Variable); and CWE-1391 (Use of Weak Credentials).

Technical details #

The ATEN RMCP+ key-exchange state machine does not enforce the ordering of RAKP messages. A network client can send Open Session followed directly by RAKP Message 3, never sending RAKP Message 1, and the BMC verifies the message-3 authentication code and activates the session. RAKP Message 1 is the only writer of the session slot's bound user id, console random number Rc, requested role byte and username length, so on any slot on which a RAKP Message 1 has never landed, every one of those transcript inputs is still the boot value of zero and the entire authentication transcript is known to the attacker. The condition is not "unallocated since boot": the slot teardown on release writes only three fields and leaves Rc, the role byte and the bound user id intact, so a slot survives repeated allocation and release still carrying its boot values, and only a completed Message 1 spoils it. The only remaining unknown is the HMAC key, which is the stored password of user record 0, the empty-username slot. On the X11DPT-PS units observed that password is a single character.

RAKP Message 1 is also where the username is resolved and the account-enabled bit is tested, so skipping it bypasses both checks and makes the stored credential of a disabled account usable. On the X11DPT-PS units record 0 ships disabled and the username lookup rejects an empty name, so a normal login as that account is refused with RAKP Message 2 status 0x0d even when the correct password is supplied, while the same password succeeds through the out-of-order message 3. On the X10DSC+ the same account ships enabled and the lookup carries no emptiness guard, so it is directly authenticable and the out-of-order path grants nothing beyond what a normal login already provides.

To exploit the issue, an attacker needs reachability to UDP/623, a session slot on which no RAKP Message 1 has ever completed, and record 0's stored password. Because the release path leaves the key-exchange fields intact, a slot keeps its boot values through repeated allocation and release; only a completed Message 1 spoils it. The usable slots are therefore determined by how many distinct slots have carried a real login since boot, not by how recently the BMC restarted. A usable slot can be reused for repeated sessions within one boot.

The record-0 password is a single character on the observed X11DPT-PS units and empty on H13. On a unit with SMCRAKP enabled, the password is replaced by a constant compiled into the firmware, so no password guessing is needed. X10 firmware 4.00 uses admin for record 0, but that account is enabled and normally authenticable.

Guessing is rate-limited rather than budgeted, and the limit does not require a reset to clear. On the H13, X11, X12 and X13 stacks the Message 3 failure arm charges a bad-password record against the slot's bound user id, which on an untouched slot is record 0, and the resulting lock is tested only after the authentication-code comparison, so once record 0 is locked the correct key is answered with the same status as a wrong one. On H13 01.03 the threshold is three rejections and the lock clears in under 32 seconds without a reset. X10 firmware 4.00 makes no lockout call in this path. The lock applies to record 0, which is disabled on the affected products where it carries the short password, rather than to an operator account.

An operator cannot close this by putting a password on the empty-username record over IPMI. Every write path against that record is refused by the firmware while the same commands succeed against ordinary user slots in the same session: Set User Password (both the set and the enable subfunctions) and Set User Access return completion code 0xcc, and Set User Name returns 0xc9. The record is also never populated as a side effect of authentication: its stored bytes are unchanged by a cold reset, by refused empty-username logins over both IPMI 2.0 and IPMI 1.5, and by failed attempts on this path.

The resulting session has a narrow command reach. Record 0's channel-access record has the IPMI-messaging bit clear, so bin/ipmi_lan routes the session into a restricted command lane regardless of the session privilege: Get Device ID, Get Chassis Status, Get SEL Info, Get User Access, Get Channel Access, Get LAN Configuration Parameters and Get Device SDR Info all return completion code 0xd4. Activate Payload succeeds, providing SOL and the host serial console. Get SOL Configuration Parameters, Get System GUID, Get Channel Authentication Capabilities and Get DCMI Capabilities are also reachable. Because RAKP Message 1 is skipped, the per-user privilege clamp that lives in that handler never runs, and Set Session Privilege Level can be raised to Administrator; doing so does not widen the command reach.

The session table is a System V shared-memory segment, key 0x1f, sized Max_Sess_Num * stride, created without an explicit clear on the images where the allocator is reached that way and explicitly cleared on others, so on a cold boot every slot is zero. The per-slot initialiser writes only four fields: the state, the channel byte, the lane marker and the session id seeded to the slot index. UtilRMCPplusSessAlloc adds only the channel, the inbound and outbound sequence counters, the session id, the state and the allocation marker. Neither routine touches the bound user id at slot offset +3, the raw requested-role byte, the console random Rm, or the BMC random Rc. UtilRAKPMessage1CMD is the sole writer of all four.

UtilRAKPMessage3CMD performs no ordering check. It looks the slot up through UtilRMCPplusSessSearch, which accepts any slot whose lane marker is 2 and whose state is non-zero, then calls ConcatenationVerifyData to build the transcript and select the key, RMCPplusGetUserInfo for the key length, and UtilRMCPplusAuthCodeVerify to compare the 20-byte code from the wire. It does not re-validate the account, does not require that RAKP Message 1 was seen, and does not reject a bound user id of zero. On success it calls UtilRMCPplusSessActivate unconditionally, moving the slot to the active state.

The transcript ConcatenationVerifyData builds is Rc(16) || SIDc(4, wire order) || RoleM(1) || ULen(1) || UName(ULen), with Rc, RoleM and the user id read from the slot and the username read from the runtime user table at the bound user id. On any slot that no RAKP Message 1 has completed on, whether or not it has been allocated since boot, Rc is 16 zero bytes, RoleM is zero, the bound user id is 0, and record 0's username is empty, so ULen is zero and the transcript is exactly 22 bytes of which only the console session id is attacker-chosen. SIDc at slot offset +0x44 (stride 0xd0) is rewritten unconditionally by every successful Open Session, so the value to use is the one sent in the immediately preceding request. The key is 20 bytes copied verbatim from userTable + userid * 0x24 + 0x56100, which is record 0's stored password right-padded with NUL. The key length is never inspected by UtilRMCPplusAuthCodeVerify, and HMAC_SHA1 is a stock OpenSSL wrapper, so a short password is zero-padded to the SHA-1 block and there is no guard on a short or empty key.

Three packets are sufficient. A session table still in its boot state is the easiest case, and the Open Session response announces it before anything else is sent, but that state is not required: the same three packets work against any slot that has not carried a RAKP Message 1, including one that has already been allocated and released several times.

target 192.0.2.10 udp/623, X11DPT-PS firmware 01.74

1. Open Session Request: console session id 0xABCD1234, cipher suite 3,
   requested maximum privilege 4
     -> status=0x00  sidm=0x00000010  granted-priv=4  auth-algo=0x01

2. (no RAKP Message 1 sent)

3. RAKP Message 3, payload type 0x14, addressed to sidm=0x00000010,
   authentication code =
     HMAC-SHA1("0", 00 x16 || 34 12 cd ab || 00 || 00)
     -> RAKP Message 4 status=0x00 (session active)

4. Set Session Privilege Level (0x06/0x3b) level=4  -> cc=0x00 (ADMINISTRATOR)

5. Activate Payload (0x06/0x48), payload type 1, instance 1
     -> cc=0x00  data=00 00 00 00 32 00 ff 00 6f 02 ff ff
        inbound 50 / outbound 255 / UDP port 623, serial console active

6. Get Device ID (0x06/0x01)  -> cc=0xd4

The same three packets against X14 (5601MS) 01.06.07 return RAKP Message 4 status 0x0f, invalid integrity check value, for every key. That generation runs a different IPMI implementation and does not share the slot behavior.

Attacker value #

An unauthenticated attacker can obtain an IPMI session without a valid account password and activate Serial-over-LAN (SOL), opening an interactive serial console on the managed host. On typical systems, that can expose BIOS and boot-loader interaction as well as whatever the operating system makes available over serial. The resulting session is restricted and does not provide the full administrative IPMI command surface. On X10DSC+, the same record is normally directly authenticable, so this issue provides no additional access.

Credit #

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

Timeline #

• 2026-07-28 (Tue): Initial findings discovered and documented
• 2026-07-21 (Tue): CVE-2026-65219 reserved
• 2026-07-31 (Fri): Vendor notified
• 2026-10-23 (Fri): Transferred CVE to the vendor for record management
• 2026-10-26 (Mon): This public disclosure