Baseboard Management Controllers (BMCs) are specialized components that enable out-of-band management, letting administrators remotely monitor, control, and update servers — even when they’re powered off or unresponsive. To perform these tasks, BMCs have deep access to a server’s hardware and software. This makes them highly security-sensitive, because if compromised, they can give attackers persistent, low-level control over the entire system. Recently, the AMI BMC vulnerability (CVE-2024-54085) was highlighted in CISA's Known Exploited Vulnerabilities (KEV) Catalog for the first time. This addition underscores the increasing urgency regarding the security of BMCs.
Given how security-critical BMCs are, we decided to perform a thorough investigation into several issues discovered in the BMC IPMI by the NVIDIA Offensive Security Research Team and disclosed by Supermicro earlier this year. In this blog post, we take a deep dive into these three vulnerabilities, exploring their causes and reviewing the fixes provided by Supermicro.
Previous Binarly REsearch on BMCs:
The Binarly REsearch team's investigation was fruitful, leading to the discovery of multiple vulnerabilities: while reviewing the details of CVE-2024-10237, we discovered that a similar technique to bypass a signature verification could be applied to other Supermicro devices, leading to the same vulnerability and security impact with malformed BMC update persistence on the device. As we’re currently in the responsible disclosure process with Supermicro, we can’t share further details just yet. However, a CVE number has already been assigned for this new issue (CVE-2025-6198), and we encourage you to follow us for updates when the full details are made public!
Gaining persistent, low-level control below the OS over a server is the holy grail for an attacker. Three new vulnerabilities in a server's BMC make this frightening scenario possible. All three exploit a single, high-impact weakness: the firmware update mechanism. In this post, we'll dissect how an attacker with administrative privileges on the host OS or BMC web panel can use a maliciously crafted firmware image to bypass security checks or trigger a buffer overflow. This provides a direct path to executing code on the BMC itself or permanently flashing a malicious image, effectively handing over the keys to the entire server.
The first vulnerability is a textbook stack-based buffer overflow in the `pdb_read` function. As shown in the following screenshot, the `fld->size` field is fully controlled by the attacker and is used as the size parameter for a `memcpy` call without any validation. Since the destination buffer (`out_buf`) is a 0x400-byte stack buffer declared in `fwmap_parser` function, if `fld->size` exceeds 0x400, a stack-based buffer overflow will occur when copying data.
The fix for this vulnerability is straightforward: it introduces a check to ensure that `fd_size` does not exceed the buffer size (`max_fd_size`) before proceeding with the copy operation.
This second vulnerability is similar to the first, caused by a missing validation on an attacker-controlled field. The `pdb_load_fat` function blindly trusts `fat->max_fld` as a loop bound. Inside the loop, this function calls `j_pdb_load_fld`, which performs a `memcpy` into its second parameter (called `fat[i+1]` in the screenshot). Since `fat` is a statically-allocated buffer on the stack, a large `max_fld` value results in a stack-based buffer overflow.
The fix for this vulnerability is also straightforward: it adds a check to ensure that `max_fld` does not exceed the maximum number of entries the `fat` buffer can hold.
The last vulnerability affects the validation logic Supermicro uses to verify that an uploaded firmware image is genuine. This process involves parsing the `fwmap`, a table listing each image region along with its starting offset, size, and a flag indicating whether the region is signed. The validation logic then computes a SHA-512 digest over the concatenation of all signed regions and compares it against an expected value, which is signed with an RSA-4096 key and embedded in the image. These steps are intended to prevent attackers from tampering with the signed portions of the firmware or applying malicious modifications.
While this mechanism appears solid at first glance, it leaves the door open for the following attack: since the location of the `fwmap` region is not fixed, and it is searched in memory by the signature (`fwmap`), an attacker can introduce a custom `fwmap` table before the original one, which will be used during the validation process. This can be used to rearrange signed regions within the firmware — for example, by moving them to unused space in the image — and update the custom `fwmap` accordingly. This preserves the signed SHA-512 digest of the original signed regions while allowing the attacker to insert malicious regions and run the custom code in the context of the BMC system.
The firmware image for the device under test (`MBD-X12DPG-OA6`, version `01.04.16`), defines the following regions in the `fwmap` table:
In our PoC, we placed our custom squashFS with a size `0x43000` at offset `0x530000`, and moved the original rootFS right after it at offset `0x573000`. This is possible, because `0x27cf80` bytes exist between the end of the original `rootFS` and the start of the `pdb_isec` regions that are not used. We also copied the original content of the `pdb_seca` region, which contains the `fwmap` table, to the unused space at offset `0x120000`:
We then modified the contents of our custom `fwmap` region to reflect our changes and satisfy the validation logic checks:
…
By emulating the firmware image in QEMU, we were able to confirm that the firmware update validation logic had been successfully bypassed and that our binary placed in the custom rootFS had been executed during the boot:
Supermicro fixed this vulnerability by introducing two two additional functions in the validation logic: `fwmap_offset_check`, which confirms that all the `fwmap` entries have only allowed hardcoded offsets, and `fwmap_attr_check`, which ensures that only the required `fwmap` entries have the `is_signed` flag. After conducting some experiments we concluded that these updates are not sufficient to prevent all the possible bypass options, but more on this in our future blog posts.
Since our Binarly Transparency Platform can automatically detect these vulnerabilities, we decided to scan our internal dataset of Supermicro firmware images to assess their scope. We identified hundreds of different Supermicro products affected by these CVEs and are releasing the full scan data to help the community detect and mitigate these issues.
Having several Supermicro motherboards that we use for vulnerability research, we decided to investigate how the firmware validation logic is implemented for them. We found that Supermicro uses several different implementations of firmware validation logic across its products. For example, the latest firmware version for the `X12STL-F` device uses hardcoded regions for digest calculation:
While this prevents issues such as CVE-2024-10237, we proved on the device that a potential attacker with physical access can still run untrusted firmware on the BMC by reflashing the SPI flash with a programmer (for anyone who is interested, here is the location of the BMC SPI flash and UART). This indicates that the Root of Trust protection feature was not enabled for this product, despite the fact that the installed Aspeed AST2600 chip supports it:
While testing another device, we identified yet another (the third!) firmware validation implementation. After some tinkering, we successfully built an attack against it. This attack doesn’t require physical access and has similar requirements and impact to CVE-2024-10237. We responsibly disclosed our findings and are currently working with the Supermicro security team on remediation. We will publish all the details once the necessary patches will be released, stay tuned to know more about CVE-2025-6198!
The key takeaway is clear: do not blindly trust firmware updates. As our REsearch demonstrates, even systems with multiple layers of validation can be tricked by a maliciously crafted update image.
Protecting your infrastructure requires vigilance. Adhere to these two non-negotiable rules to defend against low-level attacks on BMCs:
A few moments spent on verification is your last and best line of defense against a persistent, below-the-OS compromise.
While manual checks are essential, the Binarly Transparency Platform automates and deepens this protection. Our unique deep code inspection engine proactively identifies all the vulnerabilities detailed in this post. Furthermore, our proactive malicious object detection analysis goes a step further by flagging suspicious images before an update is ever attempted, effectively blocking the attack vectors we've described.
Binarly Transparency Platform detecting Supermicro BMC vulnerabilities:
