By Anton Ivanov
This is the third (and, we hope, final) part of a series of blog posts related to vulnerabilities identified in the Supermicro BMC firmware image authentication design. To gain more context, we highly recommend checking out the other posts in this series:
For your convenience, here is a quick summary:
In this blog post, we will outline the techniques we used to bypass the fixes provided for CVE-2025-7937 and CVE-2025-6198. We will also provide the analysis of the patches introduced in the most recent versions of the Supermicro BMC firmware and determine whether these issues can finally be considered resolved, after over a year of disclosure activity.
Before delving in, it is crucial to understand the high-level logic of the Supermicro BMC firmware validation process. In short, the Supermicro BMC management interface enables BMC system administrators to upgrade the BMC OS by uploading a firmware image file. Before the provided image is flashed to the BMC SPI chip, multiple checks are performed. The most important of these is verification of the digital signature of the uploaded firmware content, which is intended to prevent potentially malicious updates. Upon inspecting a variety of Supermicro BMC firmware images, we discovered that Supermicro products employ two variants of this logic, depending on whether the `fwmap` or `sig_table` content is parsed. For a more detailed description of this process, please refer to the relevant section of our previous blog post.
The next sections will reveal the details of CVE-2025-12006 and CVE-2025-12007. To ensure smooth reading, we will provide a quick recap of the related firmware validation mechanisms and issues previously found in them before discussing each of the vulnerabilities. For CVE-2025-12006, validation is based on processing the content of the `fwmap` table, whereas for CVE-2025-12007, it is based on parsing the `sig_table`.
This method is used by a wide range of Supermicro products, and we selected the X12STW-F firmware for research purposes. In this case, the validation logic is located in the libipmi.so library.
For `fwmap` based validation, it is expected that the uploaded firmware will contain the `pdb_seca` region. This region by itself is a data structure named “PDB” by Supermicro developers, and it is located in the firmware content by searching for the `PDBA` magic. In reality, the firmware contains multiple “PDB” structures, so the first one containing the `fwmap` “PDB file” entry is selected for the validation process. The following example illustrates the `pdb_seca` region, located at offset `0x110000`, that contains five “PDB file” entries, including one named `fwmap`:
The purpose of the `fwmap` table is to list all the firmware regions, including their offset, size and attributes, such as whether the region is signed or not. This information is used to determine which firmware regions should be included in the image cryptographic signature verification process.
`fwmap` based validation mechanism is known to be affected by the following issues:
The firmware version 01.05.15 did not contain any required validation steps to prevent potential malicious updates, making the exploitation trivial. It was sufficient to replace the original parts of the firmware with custom content, and to move the genuine firmware content to some space of the image that was not reserved by any region. Finally, we introduced a custom `pdb_seca` region, containing a modified `fwmap` table that reflected all the relocations we made. Crucially, our modified `fwmap` table was used during the validation process because it was located before the original one.
In our exploitation POC, we introduced the custom `rootFS` region, which was successfully flashed to the BMC SPI and executed during the BMC boot process:
The fix for the CVE-2024-10237 was added in the version 01.06.17 as two additional checks implemented in the `fwmap_parser` function. The first one blocked the possibility of defining regions in the `fwmap` table that had non-allowlisted offsets, which is what we did for the original `pdb_seca` and `rootFS` regions to exploit this issue. The second check validated that only allowed regions of the `fwmap` table could have a flag indicating that they are signed and therefore should be used during the image cryptographic signature verification process.
However, these constraints did not prevent us from replacing the firmware bootloader with a custom one, and moving all the genuine signed image content to one of the allowed offsets – `0x100000`. We also used a whitelisted region name `bootloader` to define it in the modified `fwmap` table, that we again located before the the original one, as part of the `pdb_seca` region:
The fix for the CVE-2025-7937 was released in X12STW-F motherboard firmware version 01.07.09.
The first added check was responsible for validating that the offset of the `pdb_seca` region, which contains the `fwmap` table used during the validation process (we will refer to this as the "used pdb_seca offset”), was equal to the hardcoded constant `0x110000`. The second ensured that the `fwmap` table contained a region with a start offset equal to or less than the "used pdb_seca offset”, and end offset greater than the "used pdb_seca offset”. We believe that the addition of these two checks was an attempt to prevent the inclusion of the modified `pdb_seca` region at a custom location, as we did in our PoC to exploit CVE-2025-7937.
It is important to note that the checks previously implemented to address CVE-2024-10237 have been removed in this firmware version. This means that custom entries could again be defined in the `fwmap` table. Also, it was possible to set a flag for any entry to indicate that it was signed.
Considering all the constraints, we designed the following `fwmap` table:
offset: 0x2c5c080, size: 0x00a6280, is_signed: true - bootloader
offset: 0x0100000, size: 0x0001000, is_signed: true - sig_table
offset: 0x0120000, size: 0x0010000, is_signed: true - pdb_seca
offset: 0x0130000, size: 0x031f880, is_signed: true - kernel
offset: 0x0530000, size: 0x272c080, is_signed: true - rootFS
offset: 0x2dc0000, size: 0x0010000, is_signed: false - pdb_isec
offset: 0x2dd0000, size: 0x0000000, is_signed: false - nvram1
offset: 0x2e80000, size: 0x0000000, is_signed: false - uboot_env
offset: 0x0110000, size: 0x0000001, is_signed: false - nvramFirst, we placed the original contents of the `bootloader` and `pdb_seca` regions to the unreserved firmware space at offsets `0x2c5c080` and `0x120000` respectively. We also placed `pdb_seca` region containing our custom `fwmap` table to the offset `0x110000` to avoid triggering the first validation check (remember that the "used pdb_seca offset” is located by searching for the first “PDB” instance containing the `fwmap` entry in the uploaded firmware content). To comply with the second validation check, we changed the offset of the `nvram` region to `0x110000` and its size to `0x1`. As its `is_signed` flag is `false`, the content of this region did not affect the image cryptographic signature verification process.
Then nothing prevented us from replacing the firmware bootloader with custom content:
As a result, we once again achieved persistent arbitrary code execution at one of the lowest levels of the BMC firmware boot process:
The Supermicro PSIRT team confirmed this vulnerability and assigned it the identifier CVE-2025-12006. During the vulnerability reporting process, we provided the vendor with the PoC image as evidence of the successful exploitation, and we decided to release it in our GitHub repository.
As a research target, we selected the X13SEM-F motherboard firmware that uses this mechanism. In this case, the main processing logic is executed in the context of the OP-TEE environment (a separate kernel image). Similar to the `fwmap` method, this validation implementation processes the entries defined in the `sig_table` firmware region, in order to determine which firmware regions should be included in the image cryptographic signature verification process. The difference is that `sig_table` is located at the fixed offset `0x100000`, and lists only the signed regions.
We identified that the firmware version 01.03.47 contains the flaw in the BMC firmware validation logic similar to the CVE-2024-10237. Again, no required validation checks existed, and we were able to freely modify the entries of the `sig_table`, as well as customize the region containing Linux kernel. To pass the image signature verification, we moved the original replaced content to the unused firmware image space:
This issue was assigned the identifier CVE-2025-6198.
The fix for the CVE-2025-6198 was released in X13SEM-F motherboard firmware version 01.05.02. It introduced two additional checks in the `smci_parse_sigtbl` function. The first validated that the offset of the `sig_table` region, which contained the table used during the validation process, is indeed equal to the hardcoded constant `0x100000`. The second checked that the table contained a region with a start offset equal or less than the `sig_table` offset, and an end offset greater than the `sig_table` offset. While the first change was not an issue, as we already placed the customised `sig_table` at the required offset `0x100000`, the second one required a slight adjustment.
After a quick brainstorming, we modified the original `sig_table` in the following way:
offset: 0x0000000, size: 0x0100000 - bootloader
offset: 0x0100000, size: 0x0000001 - sig_table (1st part)
offset: 0x0101001, size: 0x0000fff - sig_table (2nd part)
offset: 0x0110000, size: 0x0010000 - pdb_seca
offset: 0x0130000, size: 0x0098e00 - kernel (before custom content)
offset: 0x0102000, size: 0x0000200 - kernel (original data that was replaced with custom content)
offset: 0x01c9000, size: 0x034dc00 - kernel (after custom content)
offset: 0x0630000, size: 0x2000000 - rootFS (1st part)
offset: 0x2630000, size: 0x07b8080 - rootFS (2nd part)
As you can see, we divided the `sig_table` region into two parts. The first one consists of just one byte and now both added checks are satisfied: the offset of this region is equal to the required value of `0x100000`, and its size is not null. The second part starts at offset `0x101001`, which is unused firmware space where the rest of the original `sig_table` content was placed. We also modified `0x200` bytes of the Linux kernel at offset `0x1c8e00` and transferred the original data to unused space at `0x102000`. Then we placed the modified `sig_table` at the required offset `0x100000`:
This allowed us to bypass the firmware validation logic once more. Regardless of whether the RoT feature was enabled, our custom Linux kernel code was successfully executed:
The Supermicro PSIRT team confirmed this vulnerability and assigned it the identifier CVE-2025-12007. During the vulnerability reporting process, we provided the vendor with the PoC image as evidence of the successful exploitation, and we decided to release it in our GitHub repository.
In January, 2026, the vendor released patches for both CVE-2025-12006 and CVE-2025-12007. Most likely, the main question that all the readers, especially those using Supermicro products, have right now is whether the issues described above have finally been resolved. To answer this, we conducted a thorough review of the updated code.
In the case of the `fwmap` based validation, the crucial change is that it is now checked that the `pdb_seca` region that was parsed and whose content was used during the image signature verification are the same. So, in the case of the X12STW-F motherboard, the updated logic of `fwmap_parser` function has these validation checks:
pdb_seca offset” should be equal to `0x110000``pdb_seca` region defined in the `fwmap` table should be equal to `0x110000``pdb_seca` region, defined in the `fwmap` table, should be equal to `0x10000`. It should also have the `is_signed` flag`fwmap` table should also be located at only allowed offsets. Additionally, for some regions, their size and attributes are checkedThis means that we can no longer place our customised `pdb_seca` region at an offset other than `0x110000` (check 1). But doing so would result in a different digest value calculated for the signed image content (checks 2, 3). This effectively blocks all existing and any other potential attacks based on the image regions manipulation:
We also investigated whether it would be possible to downgrade the BMC OS firmware using the vulnerable versions of the legitimate images. Our attempts were blocked by check 4 because previous versions of the firmware used regions defined in the `fwmap` table that contained non-whitelisted offsets. For example, the kernel region for X12STW-F firmware versions prior to 01.08.08 was located at offset `0x130000`, but this was disallowed by the updated logic. In the latest firmware version, the kernel region is located at whitelisted offset `0x120000`.
The fixed version for the X12STW-F motherboard firmware is 01.08.08.
As for logic that is based on the `sig_table` processing, additional validation was added in the context of the libipmi.so library code, specifically in the `verify_sigtbl` function, which is executed before the transferring context to the OP-TEE kernel. Upon examining the X13SEM-F motherboard's firmware version 01.06.10, we observed that now only two offsets are permitted for `sig_table` entries: `0x0` and `0x3FB0000` (the latter is the location of the region containing the image cryptographic signature). Given that the total size of the image is limited to 64 MB (0x4000000 bytes), we cannot modify any of the significant firmware regions (`bootloader`, `kernel`, `rootFS`), nor can we alter the entries in the `sig_table`, which is always read from offset 0x100000, without changing the calculated image digest value:
These changes in the validation logic also blocks any firmware downgrade attempts, as the previous versions of the X13SEM-F firmware contain regions defined in the `sig_table`, that are located at non-whitelisted offsets, such as `kernel`, located at `0x130000`, or `rootFS`, located at `0x630000`.
We are pleased to confirm that issues in the validation mechanisms of Supermicro BMC firmware update process have now been fixed. However, we would like to highlight the following:
`libipmi.so` library, which is executed within the BMC OS context. This means that an attacker with root privileges to the BMC system could potentially bypass all the introduced validation checks. The reason why the fixed code is not part of the OP-TEE kernel is unclear.The Binarly Transparency Platform can identify all of the issues outlined in this article with the help of its powerful code-level VulHunt detection engine, as well as using industry well-known Yara rules:
This story illustrates how complicated the vulnerability patching process can be. In this case, to fix the single issue, the vendor required more than a year and three iterations of the full release cycle, which consisted of triaging the reported issues, updating the code, and providing the patches for all the affected products. This highlights how crucial mature security processes are: proper planning and rigorous testing help prevent small fixes from turning into prolonged, multi-release efforts.
Given the persistent nature of these vulnerabilities, it is crucial for administrators to adopt robust mitigation strategies:
The Binarly Transparency Platform is designed to automate and enhance the protection against a wide range of low-level attacks. Our deep code inspection engine proactively identifies vulnerabilities like those detailed in this post. Furthermore, our proactive malicious object detection analysis flags suspicious images before an update is ever attempted, effectively blocking these attack vectors.
