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.
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.
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.
The month ahead #
This OpenBMC release is the first disclosure day in a sequence of five sets of technical details. Over the next few weeks, we plan to disclose technical details for issues affecting several other vendors, all of whom have been contacted. We expect to have everything out by the end of October.
I plan to update this post as those disclosures happen, with 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.
