CVE-2020-15705: GNU GRUB2 Auth Bypass Vulnerability

CVE-2020-15705 Overview

CVE-2020-15705 is a Secure Boot Bypass vulnerability in the GNU GRUB2 bootloader. GRUB2 fails to validate the kernel image signature when it is booted directly without using shim as an intermediary. The flaw allows an attacker who can replace the kernel on disk to load an unsigned or untrusted kernel even when UEFI Secure Boot is enabled. The issue affects GRUB2 version 2.04 and earlier. It is part of a broader class of boot chain integrity issues disclosed alongside the BootHole research.

Critical Impact

An attacker with sufficient local privileges can defeat UEFI Secure Boot, load an arbitrary kernel, and persist below the operating system on affected Linux and Windows hosts.

Affected Products

• GNU GRUB2 versions 2.04 and prior
• Red Hat Enterprise Linux 7 and 8, Red Hat Enterprise Linux Atomic Host, OpenShift Container Platform 4.0
• Canonical Ubuntu 14.04 ESM, 16.04 LTS, 18.04 LTS, 20.04 LTS; Debian 10; openSUSE Leap 15.1 and 15.2; SUSE Linux Enterprise Server 11, 12, 15
• Microsoft Windows 8.1, Windows RT 8.1, Windows 10, Windows Server 2012/2012 R2, Windows Server 2016, and Windows Server 2019 (per Microsoft advisory ADV200011)

Discovery Timeline

• 2020-07-29 - CVE-2020-15705 published to NVD alongside coordinated vendor advisories
• 2020-07-29 - Eclypsium publishes the related "There's a Hole in the Boot" analysis
• 2020-07-29 - Microsoft issues advisory ADV200011 and Ubuntu releases USN-4432-1
• 2024-11-21 - Last updated in the NVD database

Technical Details for CVE-2020-15705

Vulnerability Analysis

The vulnerability is an Improper Verification of Cryptographic Signature flaw [CWE-347] in the GRUB2 boot chain. On a typical UEFI Secure Boot Linux system, firmware verifies shim, shim verifies GRUB2, and GRUB2 is expected to verify the Linux kernel it loads. When the GRUB2 image is signed directly by a certificate enrolled in the platform's Secure Boot database (db) and booted without shim, GRUB2 does not invoke the signature verification path before transferring execution to the kernel.

The gap breaks the chain of trust at the GRUB2-to-kernel transition. An attacker who can write to the EFI System Partition or replace the kernel image on disk can substitute an unsigned or maliciously modified kernel. Because the substitution occurs before any operating system defenses load, kernel-level rootkits and bootkits can persist across reboots and reinstalls of the operating system. The affected scope is narrower than BootHole (CVE-2020-10713), because it requires that the kernel signing certificate be imported directly into the Secure Boot db and that GRUB2 be launched without shim.

Root Cause

GRUB2 relied on shim's verification protocol to enforce signature checks on the kernel. When GRUB2 is loaded directly from firmware, the shim_lock verifier is absent, and GRUB2 proceeds to execute the kernel without an internal fallback signature check. The trust boundary assumes a component that may not be present in the boot path.

Attack Vector

Exploitation requires high local privileges to modify boot artifacts on the EFI System Partition or /boot. The attacker replaces the kernel image, then triggers a reboot. On the next boot, firmware launches the signed GRUB2 binary, which loads the attacker-supplied kernel without verification. The result is pre-OS code execution that bypasses Secure Boot guarantees and enables persistent firmware-adjacent implants.

No public proof-of-concept exploit code is referenced for this CVE, and it is not listed in the CISA Known Exploited Vulnerabilities catalog. Detailed technical context is available in the Red Hat GRUB2 bootloader vulnerability writeup and the Ubuntu Secure Boot Bypass knowledge base article.

Detection Methods for CVE-2020-15705

Indicators of Compromise

• Unsigned or unexpected kernel images in /boot or on the EFI System Partition (/boot/efi) that do not match vendor-supplied package contents.
• GRUB2 binaries with versions at or below 2.04 still installed on systems where vendor updates should have applied.
• Modifications to grub.cfg, grubx64.efi, or kernel files outside of dpkg, rpm, or zypper package management transactions.
• UEFI db entries containing kernel signing certificates that bypass the distribution shim.

Detection Strategies

• Validate the installed GRUB2 package version against patched releases listed in USN-4432-1, Gentoo GLSA 202104-05, and the SUSE knowledge base article.
• Verify Secure Boot state and the contents of the UEFI db and dbx using mokutil --list-enrolled and efi-readvar to confirm revoked GRUB2 hashes are present.
• Use file integrity monitoring on /boot and the EFI System Partition to alert on changes to bootloader and kernel files outside maintenance windows.

Monitoring Recommendations

• Centralize boot-time and package manager logs to detect unauthorized kernel replacement or unexpected grub2-install invocations.
• Track UEFI variable changes, mokutil activity, and Secure Boot policy modifications across the fleet.
• Correlate endpoint telemetry with reboot events to identify hosts that reboot into unsigned kernels. SentinelOne Singularity Endpoint provides behavioral AI telemetry and Storyline reconstruction that can be used to investigate suspicious privileged file modifications in /boot preceding a reboot.

How to Mitigate CVE-2020-15705

Immediate Actions Required

• Apply distribution-supplied GRUB2, kernel, shim, and dbx updates from Red Hat, Canonical, Debian, SUSE, openSUSE, and Microsoft as soon as feasible.
• Restrict local administrative and physical access to systems where Secure Boot is the primary integrity control.
• Audit all systems for direct enrollment of kernel signing certificates in the UEFI db and remove them where the shim-based chain of trust is the intended design.

Patch Information

Fixed GRUB2 packages are available from each affected vendor. Reference advisories include the Red Hat GRUB2 bootloader vulnerability page, Ubuntu USN-4432-1, the Debian GRUB UEFI Secure Boot notice, the SUSE Secure Boot writeup, Gentoo GLSA 202104-05, and the NetApp advisory NTAP-20200731-0008. Microsoft addressed Windows boot chain implications in advisory ADV200011. Vendors coordinate dbx revocation list updates to block vulnerable GRUB2 binaries from loading on patched firmware.

Workarounds

• Boot GRUB2 only through the distribution-provided shim binary so that the shim_lock verifier enforces kernel signature validation.
• Avoid enrolling kernel signing certificates directly into the UEFI Secure Boot db; rely on Microsoft and distribution CAs validated by shim instead.
• Enable full-disk encryption with TPM-bound keys to limit the value of an offline kernel replacement attack.
• Stage dbx updates carefully and validate boot success on representative hardware before broad rollout.

# Verify GRUB2 version and Secure Boot status on affected Linux hosts
rpm -q grub2 || dpkg -l | grep -E '^ii\s+grub'
mokutil --sb-state
mokutil --list-enrolled
efi-readvar -v dbx | head