Supermicro ATEN Privilege Escalation

Executive summary #

The Supermicro ATEN RMCP+ key-exchange handler UtilRAKPMessage1CMD dispatches on the upper nibble of the RAKP message 1 "Requested Maximum Privilege Level" byte and implements only the two values the IPMI 2.0 specification defines, with no default arm. A reserved upper nibble, anywhere from 0x2x through 0xFx, takes the session slot's existing current-privilege byte in place of the requesting account's channel privilege limit and writes that value into the session's maximum-privilege byte, so the per-user privilege clamp never executes. Because RAKP message 1 requires no credential, a user holding any low-privilege IPMI account can seed the slot with Administrator privilege and then complete a normal, correctly signed session that operates at that privilege. This vulnerability has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8, High), and is an instance of CWE-269 (Improper Privilege Management) and CWE-478 (Missing Default Case in Multiple Condition Expression).

Technical details #

On X10DSC+ and X11DPT-PS, the escalated session is Administrator. It can invoke Set User Password, Set User Access, Set Channel Access, Set LAN Configuration Parameters, Cold Reset, chassis power and boot control, Set SOL Configuration Parameters, and the Administrator-gated OEM 0x30 command set. The user-management commands let the attacker promote their own account permanently, so the escalation can survive the session that produced it. The privilege is bounded by the channel's configured cipher-suite privilege limit; on the observed X11 and H13 units, the negotiated suite's limit is Administrator (privilege nibble 4), so it did not bound the result.

The X10DSC+ and X11DPT-PS results are bounded by privilege controls: an Operator-privilege account is refused Get Device SDR Info (0x04/0x20), while the escalated session and a genuine Administrator are granted it. On H13 (F401MS) 01.03, the escalation is above the account's USER limit, but its exact level is not observable remotely. No read-only command on that firmware separates Operator from Administrator: each candidate is either granted to an Operator or refused to a genuine Administrator. Get Device SDR Info is refused with completion code 0xd4 even to an Administrator on H13; Get User Access (0x06/0x44) is granted to an Operator and therefore establishes only that the escalated session is above USER.

The RAKP message 1 role byte carries the requested privilege in bits [3:0], the name-only lookup flag in bit [4], and reserved bits in [7:5]. UtilRAKPMessage1CMD branches on the whole upper nibble and supplies no else, so any reserved nibble from 0x2x through 0xFx falls past both privilege assignments. Within the session slot (stride 0xe4), offset +1 is the session maximum privilege, +2 the current privilege, and +3 the bound user id:

if (((role & 0xf) < 6) && ((chanaccess & 0xf) != 0xf)) {
    if ((role & 0xf0) == 0) {                                 <i>// privilege + name lookup</i>
        if (((chanaccess ^ role) & 0xf) != 0) { ... CC 9; UtilRMCPplusSessRelease(); return; }
        sess[+2] = role & 0xf;
    }
    else if ((role & 0xf0) == 0x10) {                          <i>// name-only lookup</i>
        if ((role & 0xf) < (chanaccess & 0xf)) sess[+2] = role & 0xf;
        else                                   sess[+2] = chanaccess & 0xf;   <i>// the clamp</i>
    }
    <i>/* no else arm: (role & 0xf0) >= 0x20 falls through with the stale slot value */</i>
    if (sess[+1] < sess[+2]) sess[+2] = sess[+1];
    else                     sess[+1] = sess[+2];
    ...
    sess[+3] = userid;
}

On the fall-through path the value later written to sess[+1] is read back from sess[+2], the privilege the slot already holds, and the account's channel privilege limit chanaccess is never compared against anything. Because the inherited value is whatever the slot already carries, the Administrator-naming Message 1 is only needed to place that value: on a slot an administrator has already used, the residue is already 4 and the seeding step is redundant, so the attack reduces to a single reserved-role Message 1 followed by a correctly signed Message 3. The only checks that still apply are that the requested nibble is below 6, that the named user record is enabled, and that the channel privilege nibble is not 0xf, none of which bound the resulting privilege.

Both RAKP message 1 exchanges in the sequence below are credential-free: RAKP message 2 returns status 0x00 for any username that exists on the unit, and the account's key is not exercised until the message-3 authentication code is verified. The first message 1 therefore seeds sess[+1] and sess[+2] with 4 by naming an Administrator account, and the second, sent to the same session with a reserved role byte, rewrites sess[+3] to the attacker's own user id while inheriting the seeded 4 into sess[+1]. Message 3 is then signed with the attacker's real key over a transcript that includes the reserved role byte, so authentication succeeds against the attacker's own account.

The sequence, observed on X11DPT-PS FW 01.74 with a User-privilege account LOWPRIV at user id 3, against example.lan on udp/623:

1. Open Session Request  (payload type 0x10), requested maximum privilege 4, cipher suite 3
2. RAKP Message 1        (payload type 0x12), role byte 0x14, username "ADMIN"
3. RAKP Message 1        (payload type 0x12), same SIDm, role byte 0x24, username "LOWPRIV"
4. RAKP Message 3        (payload type 0x14),
     authentication code = HMAC-SHA1(K_LOWPRIV, Rc || SIDc || 0x24 || 0x07 || "LOWPRIV")
5. Get Session Info      (App 0x06 / cmd 0x3d)
6. Get User Access       (App 0x06 / cmd 0x44)
7. Get Device SDR Info

Open Session Response                      status 0x00, granted maximum privilege 4, SIDm 0x00000192
RAKP Message 2  (ADMIN,   role 0x14)       status 0x00
RAKP Message 2  (LOWPRIV, role 0x24)       status 0x00
RAKP Message 4                             status 0x00   (session active)
Get Session Info                           CC 0x00, session privilege ADMINISTRATOR
Get User Access                            CC 0x00
Get Device SDR Info                        CC 0x00

The same account logging in normally is refused both Get User Access and Get Device SDR Info with completion code 0xd4 (insufficient privilege). Two controls separate the defect from the sequence itself, and both hold on the units where the escalation was observed. Omitting step 2, so that no Administrator-named message 1 seeds the slot, leaves both commands at 0xd4. Replacing the reserved role byte in step 3 with the specification-conformant name-only lookup value 0x12 also leaves both commands at 0xd4, because the clamp in the 0x10 arm then applies the account's channel privilege limit correctly.

Attacker value #

An authenticated low-privilege IPMI user can raise their own session to Administrator on the observed X10DSC+ and X11DPT-PS systems. This gives the attacker access to administrator-level BMC management, including user administration, power and boot control, and OEM commands; they can also promote their own account to make the access persistent. On the observed H13 F401MS system, the session exceeds the account's USER limit, but the exact resulting privilege level could not be confirmed.

Exploitation requires credentials for an enabled low-privilege account whose LAN channel access permits IPMI messaging, an enabled Administrator account (named ADMIN on the observed units), and a channel cipher-suite privilege limit at least as high as the privilege sought. The Administrator password, a concurrent victim session, and an on-path position are not required.

On compatible firmware, this privilege escalation can provide the Administrator session required by CVE-2026-65210 to read arbitrary BMC files, including stored account credentials, or by CVE-2026-65211 to read and write physical memory and execute code on the BMC. The X13 2401MS firmware is listed as affected by all three issues, although the CVE-2026-65220 escalation has not been confirmed on live X13 hardware.

Credit #

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

Timeline #

• 2026-07-29 (Wed): Initial findings discovered and documented
• 2026-07-21 (Tue): CVE-2026-65220 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