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 BMC 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 obtaining 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:
offset: 0x0000000, size: 0x00a5400, is_signed: true – bootloaderoffset: 0x0100000, size: 0x0001000, is_signed: true – sig_tableoffset: 0x0110000, size: 0x0010000, is_signed: true – pdb_secaoffset: 0x0130000, size: 0x03e5b00, is_signed: true – kerneloffset: 0x0530000, size: 0x24c3080, is_signed: true – rootFSoffset: 0x2c70000, size: 0x0010000, is_signed: false – pdb_isecoffset: 0x2c80000, size: 0x0000000, is_signed: false – nvram1offset: 0x2e80000, size: 0x0000000, is_signed: false – uboot_envoffset: 0x2ec0000, size: 0x0000000, is_signed: false – nvramIn 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:
offset: 0x0000000, size: 0x00a5400, is_signed: true – bootloaderoffset: 0x0100000, size: 0x0001000, is_signed: true – sig_tableoffset: 0x0120000, size: 0x0010000, is_signed: true – pdb_secaoffset: 0x0130000, size: 0x03e5b00, is_signed: true – kerneloffset: 0x0530000, size: 0x0043000, is_signed: false – rootFSoffset: 0x0573000, size: 0x24c3080, is_signed: true – origFSoffset: 0x2c70000, size: 0x0010000, is_signed: false – pdb_isec …
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:
