By Anton Ivanov
In a previous blog post, we detailed three Supermicro BMC firmware vulnerabilities that were originally found by the NVIDIA Offensive Security Research Team and disclosed earlier this year. All these issues were related to the BMC firmware update process and could be exploited by an attacker with administrative access to the BMC operating system who uploaded a specially crafted image.
To recap briefly, two of the vulnerabilities (CVE-2024-10238 and CVE-2024-10239) were caused by insufficient checks during the parsing process of the uploaded firmware image, resulting in stack-based buffer overflows that could be used by an attacker to execute arbitrary code in the BMC context (see our exploitation PoC for another Supermicro BMC buffer overflow vulnerability). The last vulnerability (CVE-2024-10237), was a logical flaw in the validation process of the uploaded firmware, which could ultimately result in the BMC SPI chip being reflashed with a malicious image. This security issue could allow potential attackers to gain complete and persistent control of both the BMC system and the main server OS.
In this follow-up, we will delve into the vendor's insufficient fix for CVE-2024-10237 and explain how we were able to bypass it, which resulted in the new CVE-2025-7937 assigned by the Supermicro PSIRT.
Additionally, we are excited to disclose the full details of CVE-2025-6198, a new vulnerability discovered by the Binarly REsearch team while analyzing other firmware validation implementations used on different Supermicro devices. While this vulnerability shares similarities with CVE-2024-10237, it also employs a distinct exploitation technique.
We investigated how image validation is performed during the firmware update process for various Supermicro products. We found that, in general, it consists of three main steps, although the specific details of particular implementations may vary.
The first step is to retrieve the public key from the BMC SPI flash chip, which forms part of the currently running BMC firmware. Conversely, the cryptographic signature value of the new firmware is extracted from the uploaded image blob. As a rule, RSA-4096 is used for signature verification.
The second step consists of processing the table embedded in the uploaded image, which represents the different regions of the firmware. At a minimum, this table contains the offsets and sizes of each region. If the fwmap table is used, it also stores the attributes of each region, indicating whether it is signed or not. In another variant (sig_table), all regions defined here are considered signed. Then, the cryptographic hash digest is calculated (usually SHA-512) of all signed firmware regions as they were concatenated one after the other.
In the final step, the public key is used to verify the signature value against a calculated hash digest. If the result is positive, the validation process succeeds and BMC firmware update is allowed.
As outlined in our previous article, CVE-2024-10237 is a design flaw in the Supermicro BMC firmware validation logic that enables potential attackers to perform the malicious firmware updates. This vulnerability demonstrated that the validation process could be manipulated by adding custom entries to the fwmap table and relocating the original signed content of the image to unreserved firmware space, which ensures that the calculated digest still matches the signed value.
For the X12STW-F firmware version 01.06.17, the following regions are defined in the original fwmap table:
offset: 0x0000000, size: 0x00a6280, is_signed: true – bootloader
offset: 0x0100000, size: 0x0001000, is_signed: true – sig_table
offset: 0x0110000, size: 0x0010000, is_signed: true – pdb_seca
offset: 0x0130000, size: 0x031f900, is_signed: true – kernel
offset: 0x0530000, size: 0x275c080, is_signed: true – rootFS
offset: 0x2dc0000, size: 0x0010000, is_signed: false – pdb_isecSimilar to technique we presented in the previous blog post, our original proof of concept for CVE-2024-10237 exploitation for this firmware image would look this way:
The provided fix included the addition of two functions: fwmap_offset_check and fwmap_attr_check. These blocked the possibility of adding entries to the fwmap table at custom offsets and also strictly defined the list of signed regions. For our PoC, this means that we can no longer move the original pdb_seca and rootFS regions at offsets 0x120000 and 0x573000, as they are not whitelisted.
However, since the fwmap table (contained in the pdb_seca region) is still searched for in memory by its signature (fwmap), a potential attacker can still introduce the custom table before the original one (we used offset 0xe0000 in our updated PoC), that will contain the single element:
offset: 0x100000, size: 0x2b32c00, is_signed: true – bootloaderThis single element will contain all the signed regions of the image, one after the other. To make our exploit useful, we can now replace the area reserved for the original bootloader code with custom content:
These modifications align with all the checks performed: our custom fwmap entry has an allowed name (bootloader), is located at an allowed offset (0x100000) and it is signed. Therefore, nothing will prevent the BMC system from being updated with such an image, resulting in persistent arbitrary code execution during the BMC boot process:
The Supermicro PSIRT team confirmed this vulnerability and assigned it the identifier CVE-2025-7937. During the investigation process, the vendor requested the PoC image as evidence of the successful exploitation, and we decided to release it in our GitHub repository.
As always, our unique Vulhunt engine provides powerful code-level detection with a nearly zero false positives rate and comprehensive annotations for CVE-2025-7937:
We decided to conduct an in-depth investigation into how the firmware validation logic is implemented for the X13SEM-F motherboard. This promised to be an interesting target, as the vendor documentation states that it provides a BMC firmware RoT (Root of Trust) security feature.
We established that the image validation code is executed in the OP-TEE environment (a separate kernel image), and that the flawed logic is contained within the auth_bmc_sig function. First, it parses the sig_table section of the uploaded firmware (alternative to fwmap), which is located at offset 0x100000 and contains information about signed regions of the image:
The highlighted 48 bytes represent six different regions of the firmware (8 bytes each). The first four bytes store the offset to the region and the rest contain the region size value transformed in a custom way. The regions are defined as follows:
offset: 0x0000000, size: 0x0100000 – bootloader
offset: 0x0100000, size: 0x0001000 – sig_table
offset: 0x0110000, size: 0x0010000 – pdb_seca
offset: 0x0130000, size: 0x03e9e00 – kernel
offset: 0x0630000, size: 0x2000000 – rootFS (1st part)
offset: 0x2630000, size: 0x064a080 – rootFS (2nd part)Once again, as all the regions used for the digest calculation are defined in the uploaded image itself (in the sig_table), it is possible to modify it, along with some other parts of the image — for example, the kernel – and move the original data to unused space in the firmware. This means that the signed data digest will still match the original value:
In our PoC, we modified 0x200 bytes of the kernel region at offset 0x1c5600 and then updated sig_table with the following entries:
offset: 0x0000000, size: 0x0100000 – bootloader
offset: 0x0101000, size: 0x0001000 – sig_table (original)
offset: 0x0110000, size: 0x0010000 – pdb_seca
offset: 0x0130000, size: 0x0095600 – kernel (before custom content)
offset: 0x0102000, size: 0x0000200 – kernel (original data that was replaced with custom content)
offset: 0x01c5800, size: 0x0354600 – kernel (after custom content)
offset: 0x0630000, size: 0x2000000 – rootFS (1st part)
offset: 0x2630000, size: 0x064a080 – rootFS (2nd part)
By connecting to the UART debugging pins, we were able to check that this exploit works by confirming that our modified image had been validated and flashed successfully, and that our customized kernel had been executed:
Several observations are important to highlight here:
The Supermicro PSIRT team confirmed this vulnerability and assigned it the identifier CVE-2025-6198. During the investigation process, the vendor requested the PoC image as evidence of the successful exploitation, and we decided to release it in our Github repository.
To provide maximum flexibility, the Binarly Transparency Platform offers a range of detection technologies. We recently integrated the widely used Yara engine into our product, and the following demo shows how it can be used to detect the CVE-2025-6198 vulnerability:
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.
