Description

IGEL OS 12 before 12.9.0, 12.8.3 LTS and IGEL OS 11 before 11.11.150 contain a secure boot bypass vulnerability in the GRUB boot stage that allows physically present attackers to gain unauthorized root access by placing an unsigned empty file named igel.conf on a partition. Attackers can exploit GRUB's fail-open signature verification behavior to drop into an interactive GRUB prompt, then boot the device's own kernel with additional command-line arguments to obtain a root shell with the disk unlocked while leaving TPM PCR values unaltered.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-08-28T22:16:55.217Z",
  "pubdate": "2026-08-28T22:16:55.217Z",
  "executiveSummary": "This vulnerability is a secure boot bypass within the GRUB bootloader affecting IGEL OS 12 (versions prior to 12.9.0 and 12.8.3 LTS) and IGEL OS 11 (versions prior to 11.11.150).\nThe flaw allows a physically present attacker to circumvent established boot integrity protections, resulting in unauthorized root-level access to the operating system.\nThe vulnerability stems from insecure signature verification logic within the GRUB boot stage, which exhibits fail-open behavior under specific conditions.\nBy manipulating the environment through the placement of a specifically named file, an attacker can drop the bootloader into an interactive prompt.\nThis permits the manual modification of kernel command-line arguments to gain root privileges while bypassing TPM-backed integrity checks.\nThe impact is significant, as it effectively nullifies secure boot protections, allowing for local privilege escalation and potential data exfiltration or persistence on the affected hardware.\nThe attack requires physical access to the target device, as the exploitation vector involves interaction with the boot sequence.",
  "technicalDetails": "The vulnerability is localized to the GRUB bootloader implementation within IGEL OS. The root cause is an insecure implementation of signature verification logic, which handles missing or malformed configuration files in a fail-open state.\nSpecifically, the system fails to verify the integrity of the boot sequence when a partition contains an unsigned empty file designated as igel.conf. When the bootloader encounters this file, the verification logic erroneously defaults to a state that permits the continuation of the boot process through an interactive GRUB prompt.\nThe attack flow follows a structured exploitation sequence: 1. A physically present attacker creates an empty, unsigned file named igel.conf on a partition accessible during the initial boot phase. 2. Upon reboot, the GRUB bootloader attempts to process this file. Due to the fail-open vulnerability, the signature verification check is bypassed or ignored. 3. The bootloader drops the user into an interactive GRUB command-line interface. 4. From this interface, the attacker can manually define the kernel boot parameters, specifically injecting arguments to override existing security policies or mount the root filesystem with elevated privileges.\nBecause the exploit operates at the bootloader level prior to the full initialization of the OS kernel and security services, it is possible to boot the system's own kernel with modified command-line arguments. This allows the attacker to obtain a root shell with the disk partition unlocked.\nA critical aspect of this exploit is that the manipulation of the boot process occurs in a way that leaves the Trusted Platform Module (TPM) Platform Configuration Register (PCR) values unaltered. Since the GRUB bootloader itself is the component being manipulated or bypassed, the subsequent handoff to the kernel does not trigger typical integrity measurement failures that would normally prevent boot-time unauthorized access.\nAffected software versions include IGEL OS 12 versions before 12.9.0, IGEL OS 12.8.3 LTS, and IGEL OS 11 versions before 11.11.150. Exploitation does not require network access, as it is strictly a local, physical attack vector, nor does it require prior authentication, as it occurs before the operating system's authentication mechanisms are invoked."
}