HPE iLO 4/5/6 pre-authentication stack overflow in SSH packet processor

Executive summary #

HPE's iLO 4/5/6 SSH server ("mpSSH") contains a stack-based buffer overflow in its transport packet reader that is reachable before authentication. The reader parses the SSH binary packet framing in two branches selected by whether a session cipher is active. The plaintext branch, used for the initial key exchange and every packet up to SSH_MSG_NEWKEYS, validates the attacker-supplied packet length with a signed comparison that a large length value defeats through integer overflow, after which the reader streams that length of bytes into a fixed 2044-byte stack buffer. A remote attacker who can reach the SSH port can therefore write past the buffer and over the saved registers and return address of the reader function without any credential.

This issue is an instance of CWE-121 (Stack-based Buffer Overflow) and has an estimated CVSSv3.1 score of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H (8.2, High), and current SSVC vectors of "Exploitation: PoC" and "Technical Impact: Partial."

Technical details #

The SSH service switches between two code paths depending on the state of the session using the cipher-active flag at word offset 2 of the session structure.

• When a cipher is active (session[2] == 1, after SSH_MSG_NEWKEYS), the 4-byte length is validated with an unsigned comparison, if (0x800 < uVar3) return -4;, followed by if (0x800 < iVar1 /* uVar3 + 4 */) return -4;.
• When no cipher is active (session[2] != 1), which holds for the initial SSH_MSG_KEXINIT and all packets up to SSH_MSG_NEWKEYS, the 4-byte big-endian length uVar3 is validated with only a signed comparison, if (0x800 < (int)(uVar3 + 4)) return -4;, and the reader then copies uVar3 bytes into the stack buffer.

The signed comparison is the defect. For a wire length uVar3 in the range 0x7FFFFFFC to 0x7FFFFFFF, the expression uVar3 + 4 overflows into the negative int range 0x80000000 to 0x80000003, so 0x800 < (int)(uVar3 + 4) evaluates false and the length passes validation. The byte-copy helper rejects only a negative count; a value in that window is a positive int, so it proceeds to read up to approximately 2 GB through a socket-read loop (while (received < len) recv(...)) that appends incoming bytes into a stack variable with no upper bound. This variable is the last local in the frame and ends 0x28 (40) bytes below the saved register and return-address block, so a body longer than 2084 bytes overwrites the saved r4-r11 and LR. On function return, including the return taken when the peer closes the socket, the corrupted LR is loaded into PC.

The plaintext branch is reached directly after the SSH version-string exchange. The key-exchange reader gates its first packet on message type 0x14 (SSH_MSG_KEXINIT) and calls the packet reader with a maximum of 0x800 while the cipher flag is still unset, so the first attacker-supplied packet lands in the vulnerable branch.

Reproduction with the non-destructive length-bypass probe using the open-source oobscan exploration tool:

oobscan scan --checks ssh.hpe.iloSSHOverflow 192.0.2.10

HIGH 192.0.2.10 ssh.hpe.iloSSHOverflow 22/tcp [CVE-2026-65204]
    vendor=hpe product=iLO6 defect=ssh-signed-length-check
    banner=SSH-2.0-mpSSH_0.2.1
    proof="product=iLO6 windowLen=0x7ffffffc windowHeld=true legalLen=0x00000100 legalHeld=true overLen=0x00000fff overHeld=false"

Attacker value #

This issue may allow an unauthenticated attacker to overwrite the SSH reader's saved program counter and stack pointer and thereby redirect the SSH task's control flow. On iLO 4 the Green Hills INTEGRITY operating system does not use address-space layout randomization (ASLR) and provides an executable stack and heap. Exploitation is still somewhat tricky, but reliable execution of the "Set Hostname" CLI command was demonstrated pre-authentication using a single ROP address and a pointer to scratch space in the .data segment. iLO 5 and iLO 6 run a Linux userland rather than the INTEGRITY RTOS; the same out-of-bounds write is present in their packet reader, but whether the different memory model changes its exploitability has not been assessed.

The affected service is enabled by default and is commonly the only always-on iLO network service besides HTTPS. At the time of testing, 4,337 distinct internet-reachable units present the vulnerable reader: 2,431 iLO 4, 976 iLO 5, 634 iLO 6, and 296 whose generation could not be determined from a reachable service.

Credit #

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

Timeline #

• 2026-07-17: Initial findings discovered and documented
• 2026-07-21: CVE-2026-65204 reserved
• 2026-07-24: Vendor notified
• 2026-07-28: Affected version matrix extended to iLO 6
• 2026-07-28: Reliable iLO 4 exploit returns the clear-tex
  
• 2026-07-28: Transferred reserved CVE IDs to HPE for record management
• 2026-10-13: Public disclosure