PoC and vulnerability report for CVE-2025-47827.
Proof-of-concept and vulnerability report for CVE-2025-47827.
In IGEL OS before v11, 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.
Improper verification of cryptographic signature in the igel-flash-driver
Linux kernel module in IGEL OS 10 allows a malicious actor to bypass
Secure Boot, by booting the shim signed by Microsoft 3rd Party UEFI CA, which
then loads GRUB and the vulnerable kernel, both signed by IGEL Secure Boot
Signing CA. Once the vulnerable kernel and embedded initramfs has loaded, a
malicious root filesystem can be mounted from the unverified SquashFS image on disk.
As the kexec_load syscall is available in the vulnerable kernel, the currently
booted kernel can be replaced with an entirely untrusted one, practically
allowing any operating system to boot, following a complete chain of
trust.
In later versions of IGEL OS, the module correctly verifies a signature of the root filesystem SquashFS image. However, both the vulnerable kernel and patched versions are signed with the same certificate, allowing the same shim to boot both vulnerable and patched versions.
The inital vector string for CVE-2025-47827 was
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
yielding a CVSS score of 8.4 (high).
On 14th October 2025, this was changed to
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
lowering the score to 4.6 (medium).
Additionally, the original weakness was defined as CWE-347: Improper Verification of Cryptographic Signature, but MSRC have assigned it CWE-324: Use of a Key Past its Expiration Date.
Both IGEL and Microsoft were contacted and made aware of this vulnerability, on 6th December 2024 and 31st March 2025 respectively, before details were made public on 29th May 2025.
As IGEL OS 10 is unsupported and the vulnerability does not exist within the shim directly, neither party have suggested a resolution. Microsoft replied with the following:
Upon investigation, we have determined that this submission does not meet the definition of a security vulnerability for servicing since IGEL OS v10 is no longer supported and the issue is in the kernel module and not the shim. Only the shim is signed by the MSFT cert.
IGEL published a security notice for CVE-2025-47827 on 2nd June 2025.
On the 13th June 2025, I reported this to Microsoft again, and received the following response:
Although your report included some good information, it does not meet Microsoft’s requirement as a security vulnerability for servicing. The reported issue is in the kernel module and not the shim, and only the shim is signed by the MSFT certificate. kexec already allows for bypassing secure boot by design (Ref: kexec Command Line in Linux - Linux Expert Better 2025).
This would meet MSRC's servicing criteria if the issue was in a boot driver/component. This is a vulnerability in the Linux distribution's kernel driver. This comes after UEFI "ExitBootServices", which means it is not a Secure Boot bypass. The user only has code execution at the OS level, not boot.
Since the publication of various news articles regarding this vulnerability, the shim maintainers liaised with Microsoft and IGEL to discuss a resolution.
After a resolution was reached, I created another case on MSRC on 20 Oct 2025, asking for the reason behind the delay in revoking these shims, modifications to the CVSS vector string and CWE, and why their update guide stated that the vulnerability had not been publicly disclosed. I received the following response:
The IGEL vulnerability that was fixed is not a Secure Boot bypass. It is a Linux-specific Kernel integrity bypass and does not affect Windows. IGEL shims are old and do not support new SBAT-based revocation. Therefore, Microsoft issued the revocations to protect against potential exploits from other vulnerabilities which have been protected by SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, replied on the PR to explain that, due to the lack of SBAT, the shims had to be revoked by DBX, and IGEL requested additional time to avoid any unintended consequences. They also apologised for not maintaining communication between the researcher and the involved parties, as required by Coordinated Vulnerability Disclosure.
A Secure Boot bypass exploit could lead to the development of an undetected bootkit/kernel-level rootkit, in turn leading to multiple implications, such as:
Without revocation or manual intervention, Secure Boot has been rendered useless on all machines that trust the Microsoft 3rd Party UEFI CA, which is the default for most devices at the time of writing.
If used for kexec, this vulnerability can be exploited to silently and
maliciously modify a legitimate system, without impacting Secure Boot.
The kernel could be replaced entirely, enabling malicious code to run at the kernel-level, granting unrestricted access to all system resources, including memory, CPU, and connected devices.
This would allow encryption keys to be dumped from memory, malicious processes to execute without restriction, and for malware to evade detection.
