Baseboard management controllers (BMCs) are a parallel attack surface for traditional rack-mounted servers, with separate processors, separate firmware, separate networks, and often a surprising amount of authority over the machine they manage. They have been studied as a security topic since at least 2013, and in August of 2026, HD Moore started talking publicly about runZero's own BMC and out-of-band (OOB) research. Today marks the start of our various OOB device disclosures we've been planning since we first informed the vendors and providers of OOB technologies of these findings.
This all started as a project that began with a couple hundred candidates identified by off-the-shelf AI tooling and some clever prompting. We whittled those down to the 40-ish issues we're confident are real, but that confidence took a lot more traditional research work: testing exposure through trial and error, getting firmware virtualization working properly, and so many slow reboots of real hardware while testing. That is the hard part of hacking that the movies tend to compress into a sweet montage.
Special thanks to Gadi Evron, Dan Farmer, Fabien Perigaud, Sn0rkY, Solar Designer, and the teams at NetRise, Dragos Threat Intelligence, and runZero who all helped with advice, testing, and review. Hacking is truly a team sport.
If you've been following along and just want the latest, the links below can help navigate.
- September 15, 2026 update: two OpenBMC issues
- September 23, 2026 update: one Lenovo N-day
- October 13, 2026 update: HPE (6), Huawei (3), and H3C (1)
- October 26, 2026 update: Avocent (1), Dell (12), Supermicro (8), plus findings
September 15, 2026 update: two OpenBMC issues #
The two issues disclosed today affect the IPMI implementation in OpenBMC's phosphor-net-ipmid component. They were observed in the OpenBMC reference image and in downstream products that ship equivalent code, including the NVIDIA BlueField-3 DPU BMC and H3C HDM3. This is worth emphasizing because OpenBMC is very often whitelabelled: outside a comprehensive SBOM, you're unlikely to be informed that OpenBMC is running the server in your server, regardless of what the logos on the boards and chassis say.
The first issue, CVE-2026-16141, is an authentication bypass in the RMCP+ session setup path. An attacker who can reach IPMI may be able to establish an authenticated session without knowing the account password by taking advantage of a default key and stale challenge state. The practical result is that this flaw can provide access to the BMC's IPMI interface, and it can be chained with the next issue to reach administrator-level operations.
CVE-2026-16140, which can be chained with the above, is a privilege escalation for an authenticated low-privilege IPMI user. By relabeling an already active session to an enabled administrator account, an attacker can reach administrator privilege without the administrator's password.
In combination, and with a little luck, these two flaws can turn network access to an exposed IPMI service into administrative control of the BMC, but several conditions outside the attacker's control have to line up. As for the lucky bit: the target must first be running the affected phosphor-net-ipmid code, have IPMI reachable, and expose an enabled account whose name the attacker knows (or can guess). For CVE-2026-16141, the stale challenge value also has to be predictable on that particular build (heap layout and allocator reuse affect this, and repeated session creation and timeouts may be needed). The privilege-escalation step additionally requires an administrator account to already be enabled. If those conditions align, an attacker may be able to change management settings, access hardware controls, or access OOB console and storage functions.
September 23, 2026 update: one Lenovo N-day #
On September 23, we released a finding that further documents CVE-2024-38508 affecting older Lenovo XCC2 versions. This issue has already been fixed by the vendor.
October 13, 2026 update: HPE (6), Huawei (3), and H3C (1) #
This release covers ten issues across HPE iLO, Huawei openUBMC, and H3C HDM. The most serious findings show how much authority these management interfaces can expose: IPMI access can become a vector for administrator access, while SNMP credentials or trust settings can reach device-wide operations. The practical takeaway is unchanged: keep management services off general-purpose networks, and track firmware and configuration on the BMCs themselves.
On HPE iLO 2, 3, and 4, one IPMI flaw allows an attacker who can reach the service and identify an enabled account to establish an administrator session without its password (CVE-2026-65206). A second flaw lets an on-path attacker inject commands into an observed active IPMI session, with the victim's privileges (CVE-2026-65205). Separately, an unauthenticated SSH packet overflow affects iLO 4, 5, and 6; control-flow redirection was demonstrated on iLO 4, while exploitability on iLO 5 and 6 has not been assessed (CVE-2026-65204).
Three more HPE issues affect management service availability. A truncated JSON escape can wedge multiple management services and require a power-cycle; deeply nested Redfish JSON stalls HTTPS, though iLO 4 can be recovered through IPMI (CVE-2026-65207, CVE-2026-65209). On iLO 5, a separate JSON dispatcher deadlock can deny service when enough requests overlap (CVE-2026-65208). These are availability flaws rather than routes to administrator access, but an attacker who can reach the management web interface may still disrupt administrators' ability to manage the server.
HPE released their own advisory, here, and customers are urged to review the vendor's material for update guidance.
Two Huawei openUBMC SNMP issues compound each other. Some product and community builds ship a shared SNMPv3 key that remains unchanged when the Administrator password is reset; while that key remains in use, a remote party can authenticate as the SNMP Administrator and read protected traffic (CVE-2026-65198). Separately, openUBMC assigns full backend privileges to SNMP caller identities, allowing even a low-privilege SNMP user to invoke operations such as BMC reboot, firmware upgrade, and account changes (CVE-2026-65199). Rotating the shipped key addresses the first exposure, but not the excessive privileges granted to other SNMP users.
The third Huawei issue requires a different kind of access: a malicious device on the internal MCTP bus can send short PLDM or NCSI responses that trigger out-of-bounds heap reads (CVE-2026-65200). A crash or denial of service is likely; disclosure of BMC memory has not been demonstrated. This is not a remote network entry point, but it makes the trust placed in internal management-bus peripherals relevant to BMC security.
Finally, the H3C finding affects HDM Family-A's firmware update trust chain. An authenticated user with firmware-update privileges can replace the public key used to verify firmware, then install a persistent image signed with the matching private key (CVE-2026-65197). This is a post-access persistence risk, not an unauthenticated entry point, and the behavior has not yet been confirmed on a live device.
October 26, 2026 update: Avocent (1), Dell (12), Supermicro (8), plus findings #
This release covers 21 issues across an Avocent serial device, Dell iDRAC-series BMCs, and Supermicro BMCs.
The Avocent ACS8000 and ACS800 serial console servers running firmware 2.32.4 are affected by CVE-2026-65184, a critical unauthenticated command-injection vulnerability in the wsserver terminal-bridge service (CVSS 9.8). The network-accessible WebSocket endpoint accepts client-supplied fields that are incorporated into shell commands without adequate validation, allowing an attacker to execute commands as root without valid credentials.
Successful exploitation could give an attacker full control of the console server, including access to the serial consoles and managed devices it fronts. The finding is based on firmware analysis and a virtualized target; it has not yet been confirmed on a live device.
A dozen issues were identified in the iDRAC line of BMCs from Dell, and they're sorted here between the low and medium findings. There were no high or critical-rated findings.
Low: CVE-2026-65185 is a PLDM firmware-update parser heap overflow reachable through malformed package data or responses from a malicious on-bus device; CVE-2026-65192 causes reduced-PII telemetry exports to include SMTP credentials and personal, network, and location data; CVE-2026-65193 groups transport and update-integrity weaknesses in the BMC-served maser pre-boot runtime; CVE-2026-65194 is a private provisioning TLS client key shared across multiple iDRAC generations; and CVE-2026-65196 leaves IPMI over LAN reachable over IPv6 even when disabled.
Medium: CVE-2026-65186 and CVE-2026-65189 allow low-privilege Redfish users to inject SQL and read data beyond their authorization; CVE-2026-65187 is an xRC4 session-decryption length underflow that causes a large out-of-bounds copy; CVE-2026-65188 is an IPMI OEM response-buffer overflow that can disclose uninitialized memory; CVE-2026-65190 allows unauthenticated requests to grow a tmpfs file until BMC memory is exhausted; CVE-2026-65191 lets an administrator use redirected Redfish event deliveries to make requests from the BMC; and CVE-2026-65195 can produce predictable local-account passwords through a time-seeded weak random generator.
The Dell iDRAC10 issue CVE-2026-65196 is especially notable because an operator may believe disabling IPMI over LAN closes that attack surface, while IPv6 reachability still exposes it. This does not bypass IPMI authentication, but it preserves a network path to the IPMI/RMCP+ services and may provide reachability relevant to other IPMI weaknesses in this group.
These findings were identified through firmware analysis and virtualized-device testing, not independently validated on physical hardware. Dell has not disputed them to date, so we are treating them as valid vulnerabilities while noting that limitation.
The confirmed Supermicro findings range from low-severity session theft to high-impact unauthenticated IPMI command access, and several combine into practical attack chains. The fixed-key RAKP issue, CVE-2026-18449, can let a remote attacker authenticate as an enabled IPMI user when the optional SMCRAKP mode is enabled. On affected ATEN systems, CVE-2026-18450 compounds that weakness: commands in an existing IPMI session are accepted without the negotiated integrity and encryption. CVE-2026-18450 is assessed High (8.1), with the CVSS vector of AC:H reflecting the need to identify a live session ID before injecting commands. A session ID may be visible to an on-path observer; predictable session IDs have also been suggested as an off-path route, but that behavior has not been firmly established. Separately, a time-seeded KVM launch token can expose a live host console to an attacker who can estimate when it was opened (CVE-2026-18451, Low, 3.1).
Two more IPMI flaws affect session setup. CVE-2026-65219 accepts a key-exchange message out of order, allowing passwordless access to a restricted IPMI session and the managed host's serial console on observed X11 and H13 systems (High, 7.4). CVE-2026-65220 lets a user with a low-privilege account raise their session to Administrator on observed X10 and X11 systems (High, 8.8). On compatible firmware, that administrator access can in turn reach CVE-2026-65210, an arbitrary BMC file read (Medium, 4.9), or CVE-2026-65211, arbitrary physical-memory read and write (High, 7.2). The file-read path can disclose account material; the memory-write path can give persistent BMC control.
Finally, CVE-2026-65213 affects Supermicro X14: an authenticated IPMI Administrator can trigger root command execution through a Supermicro OEM file-apply handler in its OpenBMC-based firmware. This is assessed Medium (6.6), reflecting the required Administrator access, despite the root-level impact.
Additional Supermicro findings: intended functionality #
One observation was an IPMI command that can read and write physical memory. On affected ATEN firmware, it is NetFn 0x30, command 0x70: sub-function 0xC0 reads from a caller-selected physical address, while 0xC1 writes there. The behavior was observed on X10 FW 4.00, X11 01.74.19, and X13 2401MS 01.07.01; the write path on X13 is subject to System Lockdown.
A second observation was raw SCSI passthrough to drives attached through a BMC-visible controller. On X13 2401MS 01.07.01 and H13SSF E401MS 01.09.16, this is NetFn 0x30, command 0xae, sub-function 0x35; it forwards a supplied SCSI command block to an enumerated drive. A read-only SCSI INQUIRY can confirm the path without changing media. The request format is 30 ae 35 <controller> <target> <direction> <timeout-lo> <timeout-hi> 06 12 00 00 00 60 00 (the six-byte INQUIRY CDB is 12 00 00 00 60 00; controller, target, and data-in direction depend on the system). This reaches host storage outside its operating system, so write or format commands carry an obvious data-loss risk.
A third observation was an ATEN configuration-restore path (FileTransactions, NetFn 0x30, command 0xA0) that accepts configuration archives without a signature or message authentication code.
These operations are available through existing administrator-level management functions, and Supermicro's position was that they represent intended functionality rather than product flaws. System Lockdown does constrain some operations: it blocks the 0x30/0x70 memory-write sub-function on X13 2401MS 01.07.01 and configuration-restore uploads on H13 and X12-and-newer ATEN firmware. However, CVE-2026-65211 documents a demonstrated vulnerability in a separate 0x30/0xae/0x22 memory-access command that succeeds on X13 even with System Lockdown enabled. Their security implications therefore still depend on what an IPMI Administrator is expected to be able to do: physical-memory access can affect the BMC itself, drive passthrough can reach host storage outside the operating system, and an unsigned restore raises questions about the integrity expected of configuration backups. Researchers with matching hardware may find these boundaries worth examining.
Unreproducable Supermicro findings #
Some firmware analysis suggested that request data might reach shell commands through Redfish FileOperation Import/Export (AuthToken, TransferProtocol, and ImageURI), the SmcDump.Download URI path, or ATEN alert-delivery settings. The crash-dump path requires /tmp/CDump.txt to exist; the alert paths include SNMPv3 trap credentials and SMTP settings and are invoked when an alert is sent. LLM-assisted tests in virtualized environments appeared to produce command-execution effects, including marker-like results, but vendor testing did not reproduce them on matching equipment. These observations do not establish that command execution occurs on real devices; they are merely leads for researchers to revisit on the relevant hardware.
A separate observation on ATEN firmware was that IPMI session identifiers advanced in a predictable sequence, commonly by 0x10 per session allocation. Researchers can check this behavior by opening and closing sessions on test equipment and recording the returned IDs, but that alone does not demonstrate that another client's session can be identified or hijacked. Combined with acceptance of unprotected commands, the sequence might offer a way to target another client's active session, but a cross-client hijack was not demonstrated and the vendor disputed the impact. Confirming whether this behavior can be used that way remains an open research question.
This level of uncertainty is not unique to AI-assisted work. Virtualized BMCs can omit or approximate hardware, timing, storage, and service behavior that determines whether a code path is reachable on a real board. LLM-assisted testing can also misread firmware, generate an invalid test sequence, or mistake a suggestive response for proof of execution. Security researchers familiar with traditional fuzzers will certainly be reminded that even deterministic crashes in a particular build and harness sometimes do not reproduce on production hardware or translate into a practical security impact. These observations are breadcrumbs, not conclusions; independent testing on matching equipment could establish whether they reflect real, exploitable behavior.
Patches for the CVE-identified issues involving Supermicro can be found at Supermicro’s site.
Detecting affected assets #
The exact exposure is not always obvious. A traditional server inventory may identify the vendor and product, but not the many components that make up that product. That's why asset discovery matters. A basic runZero asset query such as (protocol:ipmi OR type:=BMC) can provide a quick snapshot of how many BMCs are listening for IPMI messages in your environment, perhaps unexpectedly. We released a Rapid Response back in August to help teams get a jump on coverage, and a broader, ongoing query for IPMI in general may be worth your time at this point.
With that inventory in hand, the next step is to determine which devices are reachable from where, which ones were meant to be on dedicated management networks, and which ones have wandered out to your more general-purpose networks. If you have some test gear available, you can also use runZero’s open-source oobscan toolchain to test for these vulnerabilities.
Once those assets are identified, runZero's network topology and attack path mapping can help show the routes to them and the systems they can influence. Attack path mapping was first released in runZero version 4.9, and it's particularly useful here for checking if your segmentation plan corresponds to reality. IPMI shouldn't be casually reachable from user networks, production application segments, or certainly the public internet.
Wrapping up #
We started this blog back in middle September, and added to it throughout October as all the impacted vendors studied our findings. All told, there were 33 new CVEs that fell out of this project, and I’m sure we’ll have more to say about those vulnerabilities along with the other interesting findings that didn’t make the cut.
All of the CVE-identified advisories now have links to our advisories page. The goal here is to level the playing field. It's not good enough if only a handful of hackers on both sides of the law know about all this attack surface.We also need to educate and inform vendors, implementors, researchers, defenders, and students on the risks associated with unaccounted-for management interfaces. Out-of-band devices like BMCs and KVM emulators are everywhere. They can accidentally turn up outside dedicated management networks, and they represent an exposure that many IT and security teams do not think about every day.
