Actively exploited in the wild
IGEL OS Use of a Key Past its Expiration Date Vulnerability
IGEL - IGEL OS · Listed in the CISA KEV since 2025-10-14. This indicates confirmed attacks in production environments.
Required action: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
CVE-2025-47827
MediumCVSS 4.6KEVSummary
In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.
Risk Assessment
Bypassing Secure Boot allows booting a modified, untrusted operating system, which can lead to full device compromise and takeover of organizational data.
Recommendation
Upgrade IGEL OS to version 11 or later to restore proper signature verification in the igel-flash-driver module.
Other vulnerabilities in IGEL OS
See all- CVE-2026-82018Medium
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.
- CVE-2026-82017High
Vulnerability in IGEL OS 12 before 12.7.6 and IGEL OS 11 before 11.11.150. An attacker with physical access can inject Linux loader parameters by writing to an unencrypted and unsigned configuration area, allowing execution of malicious kernel parameters with boot environment privileges without triggering TPM PCR failures.
Original NVD description (English source)
In IGEL OS before 11, Secure Boot can be bypassed because the igel-flash-driver module improperly verifies a cryptographic signature. Ultimately, a crafted root filesystem can be mounted from an unverified SquashFS image.