BootHole (CVE-2020-10713) is a GRUB2 bootloader vulnerability that can let a crafted boot configuration trigger code execution before the operating system starts and undermine UEFI Secure Boot. It is serious for boot-chain integrity, but it is not described in the cited advisories as an unauthenticated, internet-based attack—and the claim that it affects “billions of devices” is not established by the primary sources cited here.
What is the BootHole vulnerability?
BootHole is the name commonly used for CVE-2020-10713, a flaw in GRUB2, a bootloader used by many Linux systems. During startup, GRUB2 reads its grub.cfg configuration file. A specially crafted or excessively long input can cause a heap buffer overflow in the parser. If exploited, that can allow code to run in GRUB before the operating system loads and interfere with Secure Boot’s verification process.
This is a boot-chain integrity problem: malicious code at this stage may run before the operating system’s normal protections are active and could support persistent bootkit behavior. The vulnerability does not mean that every affected computer has been compromised.
BootHole is also sometimes used in coverage of a broader set of GRUB2 issues addressed around the same time. CVE-2020-10713 specifically identifies the crafted-grub.cfg parsing flaw. Related identifiers include CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, CVE-2020-15706, and CVE-2020-15707; they describe distinct issues and should not be treated as the same vulnerability. Ubuntu’s BootHole record groups information about the response and affected releases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
Who may be affected—and is it really billions of devices?
GRUB2 is widely used, but the presence of Linux or Secure Boot alone does not determine whether a system is vulnerable. Exposure depends on the bootloader and related boot components installed, the specific distribution and release, Secure Boot configuration, firmware trust state, and whether the relevant updates and revocations have been applied. The reviewed primary advisories do not substantiate the headline claim that billions of devices are affected.
Vendor advisories define scope for particular products, not all Linux-based computers. For example, Red Hat’s advisory lists RHEL 7, RHEL 8, Red Hat Enterprise Atomic Host, and OpenShift Container Platform 4 (RHEL CoreOS) in its affected-product scope. Ubuntu publishes release-specific status: its retrieved record marks Ubuntu 20.04 LTS as fixed and Ubuntu 22.04 LTS and later as not affected, while earlier releases have their own statuses. Older Ubuntu releases may have legacy or extended-maintenance distinctions, so check the status and support coverage for the exact release rather than assuming standard support applies.
Does BootHole affect Windows?
A Windows-only computer is not automatically vulnerable to CVE-2020-10713 just because it has Secure Boot. The issue is in GRUB2, not Windows’ own boot components. A Windows system may still need a trust revocation in a particular firmware configuration: the NSA says Windows endpoints require revocation only if the firmware trusts the specific CA identified in Microsoft’s advisory. On a dual-boot computer, determine whether a vulnerable GRUB/shim path is installed as well as checking the Windows boot path.
How could an attacker exploit it?
The advisories describe exploitation as requiring a foothold or an opportunity to alter the boot configuration or boot path—not merely an ordinary internet connection. The NSA states, “Physical access or administrator privilege is required to exploit the vulnerability and subvert the boot process.” Red Hat likewise says an attacker first needs system access, such as physical access, the ability to alter a PXE boot network, or remote access with root privileges.
Recommended Free Tools
That prerequisite narrows the attack scenario; it does not make the impact trivial. Code execution before the operating system starts can compromise the trust chain and may be difficult to detect using tools that operate only after startup.
How do you fix BootHole?
Remediation has two connected parts: install the updated boot components specified by your operating-system vendor, then follow that vendor’s and your computer manufacturer’s directions for revoking trust in vulnerable signed boot components, usually through UEFI’s DBX or a vendor-specific mechanism. Updating packages alone may leave an older, vulnerable loader trusted and available for rollback.
- Identify the boot path and exact release. Record your Linux distribution and release, installed GRUB2/shim and other relevant boot-package state, whether Secure Boot is enabled, and whether the machine is single-boot or multi-boot. Use the distribution’s current security advisory for that release and check the computer or motherboard manufacturer’s instructions.
- Install the vendor’s boot-component updates. Follow the current distribution instructions for the specific system. Do not use package versions from the original 2020 notices as a universal present-day fix; those versions were release-specific historical fixes.
- Check bootability before applying revocation. Where the vendor recommends it, test the updated boot path on representative systems and confirm that required operating systems and recovery paths start correctly.
- Apply the vendor- and OEM-directed trust revocation. Only after the boot components are updated, follow the supported procedure for DBX or the applicable revocation mechanism. There is no single safe command that applies to every distribution, firmware, and device.
Can a Secure Boot update make a computer unbootable?
It can, if revocation is applied before compatible boot components are installed or if another operating system still depends on a revoked loader. The NSA warns that failing to follow the update-then-revoke sequence can leave an endpoint unable to boot with Secure Boot enabled.
Dual-boot and multi-boot users need particular care because the UEFI trust database is shared by operating systems on the device. Ubuntu warns users to update every operating system before making DBX changes; otherwise, revocation may prevent an unrelated operating system from starting. Red Hat also notes that RHEL 8 Secure Boot users may need additional steps to boot older kernels whose hashes are no longer allow-listed. Follow the current instructions for each installed system, not just the one used most often.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Quick Recap
Best Value
What to check on your device
- Distribution and release: consult the vendor’s status for the exact release, including any legacy or extended-maintenance qualification.
- Boot components: confirm that GRUB2, shim, and other components in the active boot path match the vendor’s remediation guidance.
- Firmware trust state: determine whether Secure Boot is enabled and whether the relevant DBX or vendor revocation has been applied.
- Other boot paths: account for dual-boot systems, PXE boot, older kernels, and recovery media that may rely on components affected by revocation.
- Current instructions: use the distribution advisory and OEM documentation for the specific computer. A vendor’s 2020 notice may not reflect the current package state or the safest procedure for that machine.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
