By leveraging Microsoft Security Copilot to expedite the vulnerability discovery process, Microsoft Threat Intelligence uncovered several vulnerabilities in multiple open-source bootloaders, impacting all operating systems relying on Unified Extensible Firmware Interface (UEFI) Secure Boot as well as IoT devices. The vulnerabilities found in the GRUB2 bootloader (commonly used as a Linux bootloader) and U-boot and Barebox bootloaders (commonly used for embedded systems), could allow threat actors to gain and execute arbitrary code.
Using Security Copilot, we were able to identify potential security issues in bootloader functionalities, focusing on filesystems due to their high vulnerability potential. This approach saved our team approximately a week’s worth of time that would have otherwise been spent manually reviewing the content. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability. Copilot also assisted in finding similar patterns in other files, ensuring comprehensive coverage and validation of our findings. This efficient process allowed us to confirm several additional vulnerabilities and extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2. We’re sharing this research as an example of the increased efficiency, streamlined workflows, and improved capabilities that AI solutions like Security Copilot can deliver for defenders, security researchers, and SOC analysts. As AI continues to emerge as a key tool in the cybersecurity community, Microsoft emphasizes the importance of vendors and researchers maintaining their focus on information sharing. This approach ensures that AI’s advantages in rapid vulnerability discovery, remediation, and accelerated security operations can effectively counter malicious actors’ attempts to use AI to scale common attack tactics, techniques, and procedures (TTPs).
While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot and install stealthy bootkits or potentially bypass other security mechanisms, such as BitLocker. The implications of installing such bootkits are significant, as this can grant threat actors complete control over the device, allowing them to control the boot process and operating system, compromise additional devices on the network, and pursue other malicious activities. Furthermore, it could result in persistent malware that remains intact even after an operating system reinstallation or a hard drive replacement.
We disclosed these vulnerabilities with the GRUB2, U-boot, and Barebox maintainers and worked with the GRUB2 maintainers to contribute fixes for the discovered vulnerabilities. To address the issues, the GRUB2 maintainers released security updates on February 18, 2025, and both the U-boot and Barebox maintainers released updates on February 19, 2025. We thank the GRUB2, U-boot, and Barebox maintainers as well as the open-source community for their quick response and collaborative efforts in addressing these issues, and we advise users to ensure their instances are up to date. We would also like to thank the RedHat support team for their assistance in disclosing these issues to manufacturers. The respective vulnerabilities are summarized in the following table:
In this blog, we detail how Secure Boot and GRUB2 function, explain how the GRUB2 vulnerabilities could have been exploited, and provide information on the vulnerabilities found in other open-source bootloaders to highlight the risks associated with unknowingly sharing vulnerable code among different open-source projects. As the boot process involves multiple components spanning different manufacturers and vendors, updates and fixes to the Secure Boot process can be particularly complex and run the risk of rendering a device unusable. As such, we are also sharing these findings with the security community to emphasize the importance of responsible disclosure and collaboration in the effort to enhance protection technologies and security across different devices and platforms.
Secure Boot and GRUB2
Before 2006, Intel-based computers booted into startup firmware code commonly known as the BIOS (Basic Input/Output System), which was responsible for hardware initialization and setup of common services to later be used by a bootloader. Ultimately, the BIOS would transfer control to a bootloader coded in real mode, which would commonly load an operating system (OS).
With time, attackers realized there is no root-of-trust verification of bootloaders by the firmware, thus began the era of bootkits, which are bootloader-based rootkits. To standardize the boot process, a unified firmware schema to replace BIOS was introduced in 2006, which is currently known as the Unified Extensible Firmware Interface (UEFI).
UEFI also helped combat bootkits, as it offers services that validate bootloaders and its own extensible modules by means of digital signatures. That protocol is known as Secure Boot and is essential to establishing a root of trust for the boot process, in which the firmware verifies UEFI drivers and OS modules with a platform key or a Key Exchange Key, and bootloaders verify the loaded operating system.
Trust is then achieved with the help of equipment manufacturers, which can sign code trusted by Secure Boot, by means of Certificate Authorities (CA). Essentially, manufacturers sign code with their private key, and their public key is signed with a root CA, commonly Microsoft’s UEFI CA. This is also essential to supporting non-Windows bootloaders such as GRUB2 (which commonly boots Linux) and allowing third party operating systems to benefit from Secure Boot. Since GRUB2 is fully open-sourced, vendors install a small program called a shim, which is signed by Microsoft’s UEFI CA and is responsible for validating the integrity of GRUB2. The shim can further consult a mechanism called Secure Boot Advanced Targeting (SBAT) for further revocation and management options as SBAT is used by the shim to provide a way to track and revoke individual software components based on metadata rather than cryptographic signatures alone.
The dangers of a GRUB2
Since bootloaders run before operating systems run, they mostly have UEFI-provided services as APIs to rely on. Therefore, bootloaders do not benefit from modern operating system security features, such as:
- No-Execute (NX): Known in Windows as Data Execution Prevention (DEP), and enforces memory page execute protections. Before the introduction of NX, attackers could override return addresses (which are maintained in-memory) and jump to arbitrary code (commonly a shellcode) that could be placed using the provided input.
- Address Space Layout Randomization (ASLR): This feature randomizes the base address of modules, which makes return address overrides and function pointer overrides highly unreliable since attackers do not know where usable code might be found.
- Safe dynamic allocators: Dynamic allocations are a favorite target for attackers, and modern operating systems harden their heap allocators with various techniques, including Safe Unlinking, type-safety, Pointer Authentication, and others.
- Stack cookies / Canaries: These are randomly generated values pushed between the return address and local variables on the stack, with the intent of detecting changes in their values before using the return address (commonly in a RET instruction).
Additionally, GRUB2 offers complex logic to implement various features, including:
- Image file parsers (PNG, TGA, and JPEG)
- Font parsing and support (PF2 file format)
- Network support (HTTP, FTP, DNS, ICMP, etc.)
- Various filesystem supportability (FAT, NTFS, EXT, JFS, HFS, ReiserFS, etc.)
- Bash-like command-line utility
- Extensible dynamic module loading capabilities
Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation. Considering the implication of defeating Secure Boot and strategically assessing the project (such as with Google’s Rule of 2), it is evident why GRUB2 may be of interest to vulnerability researchers.
Several memory corruption vulnerabilities have been uncovered in the past and are evident of the risks that we have mentioned. Noteworthy examples include:
| Vulnerability | Subsystem(s) | Description |
| CVE-2020-10713 | Configuration file | The vulnerability was published under the name “Boot Hole”, consisted of a buffer overflow in the parsing of the GRUB2 configuration file (grub.cfg). |
| CVE-2021-3695 CVE-2021-3696 CVE-2021-3697 |
Image parsing | Several buffer overflow vulnerabilities were discovered when parsing images. |
| CVE-2022-28733 CVE-2022-28734 |
Network | Various buffer overflow vulnerabilities when parsing IP or HTTP packets. |
| CVE-2022-28735 | Shim | It was discovered that non-kernel files could be loaded and execute arbitrary code. |
| CVE-2023-4692 | NTFS (filesystem) | A heap out-of-bounds was discovered in the NTFS filesystem implementation for GRUB2. |
Findings
Through a combination of static code analysis tools (such as CodeQL), fuzzing the GRUB2 emulator (grub-emu) with AFL++, manual code analysis, and using Microsoft Security Copilot, we have uncovered several vulnerabilities.
Using Security Copilot, we initially explored which functionalities in a bootloader have the most potential for vulnerabilities, with Copilot identifying network, filesystems, and cryptographic signatures as key areas of interest. Given our ongoing analysis of network vulnerabilities and the fact that cryptography is largely handled by UEFI, we decided to focus on filesystems.
Using the JFFS2 filesystem code as an example, we prompted Copilot to find all potential security issues, including exploitability analysis. Copilot identified multiple security issues, which we refined further by requesting Copilot to identify and provide the five most pressing of these issues. In our manual review of the five identified issues, we found three were false positives, one was not exploitable, and the remaining issue, which warranted our attention and further investigation, was an integer overflow vulnerability.
We used Security Copilot to successfully identify similar patterns in other GRUB2 files. Assuming the possibility of false negatives, we performed thorough validation and review of GRUB2 to avoid overlooking any issues, allowing us to confirm several additional vulnerabilities were present relating to the integer overflow.
Through this research, we have disclosed the following vulnerabilities:
| Module | Vulnerability | CVE |
| UFS (filesystem) | Buffer overflow in symbolic link handling due to an integer overflow in allocation. | CVE-2025-0677 |
| Squash4 (filesystem) | Buffer overflow in file reads due to an integer overflow in allocation. | CVE-2025-0678 |
| ReiserFS (filesystem) | Buffer overflow in symbolic link handling due to an integer overflow in allocation. | CVE-2025-0684 |
| JFS (filesystem) | Buffer overflow in symbolic link handling due to an integer overflow in allocation. | CVE-2025-0685 |
| RomFS (filesystem) | Buffer overflow in symbolic link handling due to an integer overflow in allocation. | CVE-2025-0686 |
| UDF (filesystem) | Buffer overflow in block reads of UDF due to an out-of-bounds operation. | CVE-2025-0689 |
| HFS (filesystem) | Buffer overflow in filesystem mounting due to wild strcpy function on a non-NUL-terminated string. | CVE-2024-56737 |
| HFS (filesystem) compression | Buffer overflow in file opens due to an integer overflow in allocation. | CVE-2025-1125 |
| Crypto (cryptography) | Cryptographic side-channel attack due to non-constant time memory comparison. | CVE-2024-56738 |
| Read (commands) | The read command is intended to read a line from the keyboard and assign its text to a variable and is susceptible to a signed integer overflow and an out-of-bounds write. | CVE-2025-0690 |
| Dump (commands) | While the memory reading commands (such as read_byte) are disabled in production, the dump command was left enabled and can be used to read arbitrary memory addresses. | CVE-2025-1118 |
Most of those vulnerabilities are simple memory corruption vulnerabilities. As an example, let us examine the JFS symbolic link resolution function:
The vulnerability is an overflow of the size variable:
- The size variable is declared as grub_size_t, which is ultimately defined as a 64-bit unsigned integer (uint64_t).
- The function grub_le_to_cpu64 converts a Little-Endian 64-bit value to the CPU’s native Endianess. Since x86-64 is already Little-Endian, it does nothing (on Big-Endian systems it reverses the byte-order of the 64-bit input value).
- Note the input data and its inode are fully attacker-controlled, since they supply the filesystem image. Therefore, size can get an arbitrary value, including the very large value 0xFFFFFFFFFFFFFFFF (which is the maximum value an unsigned 64-bit integer can get).
- The linknest checks are irrelevant for the vulnerability, but they assure the number of nested symbolic links to not exceed a limit (defined as 8).
- The size+1 calculation is an integer overflow—if size is 0xFFFFFFFFFFFFFFFF then size+1 is now 0. Note grub_malloc happily allocates a 0-byte chunk and returns it to the variable symlink.
- At this point, symlink is being written to by the function grub_jfs_read_file. The contents are arbitrarily set by the attacker, and while this function will never be able to read 0xFFFFFFFFFFFFFFFF bytes, an attacker would still be able to override important data beyond the limit of the symlink variable with an arbitrary payload.
It seems GRUB2 maintainers were aware of other types of integer overflow issues in the past and therefore introduced functions such as grub_add and grub_mul to handle addition and multiplication overflows safely. However, it seems there are quite a few places where those functions have not been considered.
The other vulnerabilities we’ve reported had similar out-of-bounds or integer overflow issues. In addition, we have reported a cryptographic side-channel attack issue, in which the function grub_crypto_memcmp does not perform its memory comparison in constant-time. The vulnerability is quite similar to one we disclosed on Netgear routers in the past.
Variant analysis and extensions to other bootloaders
After the discovery of the GRUB2 filesystem vulnerabilities and validating their exploitability, we concluded it is very likely other bootloaders might be affected by similar vulnerabilities, potentially as a result of the practice of copy-pasting filesystem parsing code between different open-source projects.
To test this hypothesis, we asked Security Copilot to find similar code in GitHub based on GRUB2’s filesystem implementations. This approach initially found many GRUB2 forks, so we continued to refine the search and manually review the results. Within those results, the U-boot and Barebox bootloaders, which are both commonly used for embedded systems, were identified as having shared code with GRUB2. Further investigation led us to identify similar vulnerabilities in both bootloaders, as detailed in the table below.
To exploit those in an embedded system context, attackers would most likely require physical access to those devices.
Enhancing security beyond Microsoft with research and threat intelligence sharing
As our research demonstrates, the discovered vulnerabilities can impact a wide range of systems and devices with varying impact. The vulnerabilities in GRUB2 can be exploited to bypass Secure Boot and allow threat actors to gain arbitrary code execution in the context of GRUB2, install stealthy bootkits and persistent malware, and compromise additional devices on the network. Additionally, there are further consequences to bypassing Secure Boot as it undermines the security mechanism designed to protect the boot process. Secure Boot bypasses can lead to threat actors loading untrusted software and malicious code during the boot process, evading detection by security solutions, and gaining full control of the system for potential widespread impact across operating systems relying on UEFI Secure Boot. While the vulnerabilities impacting U-boot and Barebox may be more difficult to exploit for threat actors by requiring physical device access, the issues still underscore the dangers of sharing susceptible code across multiple open-source projects.
This research also demonstrates the necessity of responsible vulnerability disclosure, threat intelligence sharing, and partner collaboration in addressing these issues to safeguard users against current and future threats. Given the complexity of the boot process, which involves multiple components from different manufacturers, coupled with the fact that updates to Secure Boot can run the risk of rendering a device unusable, responsible disclosure of these vulnerabilities is necessary to prevent threat actor exploitation and give teams time to effectively coordinate and collaborate on mitigation measures.
To address the discovered issues, the GRUB2 maintainers updated the vulnerable versions in SBAT while working with manufacturers to update DBX database entries as well as their shims to improve Secure Boot revocation management, particularly for bootloaders like shim that act as an intermediary between firmware Secure Boot verification and Linux distributions boot processes. In addition to deploying patches to address the vulnerabilities, the GRUB2 maintainers disabled some of the OS modules when Secure Boot is enabled to help ensure only trusted and verified code executes during the boot process, further reducing the attack surface. We would like to again thank the GRUB2 team and open-source community for their efforts in addressing these issues, as well as the U-boot and Barebox maintainers for quickly releasing fixes.
Leveraging AI like Security Copilot was invaluable in our research, saving us approximately a week’s worth of time by efficiently identifying and refining security issues in bootloader functionalities, ultimately allowing us to uncover several vulnerabilities. Identifying, disclosing, and contributing fixes for vulnerabilities, such as those mentioned in this blog post, is part of our ongoing commitment to enhance security at Microsoft and beyond. Microsoft is dedicated to improving security through research-driven protections and collaboration with customers, partners, and industry experts. Microsoft security researchers discover vulnerabilities and threats, translating this knowledge into enhanced solutions that protect users daily, and by expanding our research, we also contribute to the security of devices worldwide across all platforms.
Jonathan Bar Or
Microsoft 365 Defender Research Team
References
Learn more
Security Copilot customers can use the standalone experience to create their own prompts or run pre-built promptbooks to automate incident response or investigation tasks related to this threat.
For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.
To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.