CVE-2025-47827
BaseFortify
Publication date: 2025-06-05
Last updated on: 2025-11-05
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| igel | igel_os | to 11.01.100 (exc) |
| microsoft | windows_10_1507 | to 10.0.10240.21161 (exc) |
| microsoft | windows_10_1507 | to 10.0.10240.21161 (exc) |
| microsoft | windows_10_1607 | to 10.0.14393.8519 (exc) |
| microsoft | windows_10_1607 | to 10.0.14393.8519 (exc) |
| microsoft | windows_10_1809 | to 10.0.17763.7919 (exc) |
| microsoft | windows_10_1809 | to 10.0.17763.7919 (exc) |
| microsoft | windows_10_21h2 | to 10.0.19044.6456 (exc) |
| microsoft | windows_10_22h2 | to 10.0.19045.6456 (exc) |
| microsoft | windows_11_22h2 | to 10.0.22621.6060 (exc) |
| microsoft | windows_11_23h2 | to 10.0.22631.6060 (exc) |
| microsoft | windows_11_24h2 | to 10.0.26100.6899 (exc) |
| microsoft | windows_11_25h2 | to 10.0.26200.6899 (exc) |
| microsoft | windows_server_2012 | * |
| microsoft | windows_server_2012 | r2 |
| microsoft | windows_server_2016 | to 10.0.14393.8519 (exc) |
| microsoft | windows_server_2019 | to 10.0.17763.7919 (exc) |
| microsoft | windows_server_2022 | to 10.0.20348.4294 (exc) |
| microsoft | windows_server_2022_23h2 | to 10.0.25398.1913 (exc) |
| microsoft | windows_server_2025 | to 10.0.26100.6899 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-347 | The product does not verify, or incorrectly verifies, the cryptographic signature for data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-47827 is a vulnerability in IGEL OS versions before 11 where Secure Boot can be bypassed because the igel-flash-driver module improperly verifies cryptographic signatures. This flaw allows an attacker to mount a crafted root filesystem from an unverified SquashFS image. The attack involves booting the Microsoft 3rd Party UEFI CA-signed Shim, which loads GRUB and a vulnerable kernel signed by IGEL. Once the vulnerable kernel and initramfs are loaded, the attacker can use the kexec_load syscall to replace the running kernel with an untrusted one, breaking the Secure Boot chain of trust and allowing arbitrary code execution at boot. [1]
How can this vulnerability impact me? :
This vulnerability can have severe impacts including bypassing Secure Boot protections, enabling kernel-level rootkits or bootkits that execute arbitrary code, escalate privileges, cause denial of service, or leak sensitive information. Attackers can fully replace the kernel, gain unrestricted access to system resources, dump memory including encryption keys, evade malware detection, modify kernel parameters to disable security modules, and maintain persistence by manipulating EFI boot order and Secure Boot databases. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection is challenging due to potential rootkit stealth but can involve verifying the presence and integrity of EFI binaries and kernel files, behavioral analysis, and monitoring for unexpected processes or filesystem changes. The provided proof-of-concept repository includes a shell script that downloads the IGEL OS installation ISO, extracts EFI binaries, and creates a bootable disk image with a modified SquashFS root filesystem, which can be used to analyze the vulnerability. Specific commands are not explicitly listed, but verifying EFI binaries' hashes and monitoring for unexpected kernel replacements or mounts of unverified SquashFS images are recommended approaches. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include revoking or distrusting the certificate used to sign the vulnerable GRUB/kernel images or adding their SHA-256 hashes to the Secure Boot Forbidden Signature Database (DBX) or Machine Owner Key (MOKX) deny lists. Distrusting the Microsoft 3rd Party UEFI CA certificate can prevent the initial Shim from executing but may disrupt legitimate applications. Using secured-core PCs that default to distrusting this certificate reduces the attack surface. Additionally, adopting a unified kernel image approach signed with user-generated keys is recommended to minimize trust in vendor/OEM keys. [1]