Someone left the master key under the doormat, and the locksmith retired
CVE-2025-47827 is a Secure Boot bypass in the igel-flash-driver Linux kernel module shipped with IGEL OS 10 (all versions before OS 11). The module fails to verify the cryptographic signature of the SquashFS root filesystem it mounts during boot. An attacker with physical access can chain through the Microsoft 3rd Party UEFI CA → IGEL-signed GRUB → IGEL-signed vulnerable kernel, then swap in a completely untrusted root filesystem—or use kexec_load to replace the running kernel entirely. The result is a full Secure Boot chain-of-trust collapse: kernel-level rootkits, credential harvesting from VDI sessions, EFI variable persistence across reboots, and anti-forensic cloaking. A public PoC from researcher Zack Didcott demonstrates the complete chain from ISO extraction to bootable malicious image.
The vendor scored this CVSS 4.6 MEDIUM with a vector of AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. That impact triad is plainly wrong: a Secure Boot bypass that enables arbitrary kernel loading and rootkit persistence is not 'no confidentiality impact, no integrity impact.' A corrected vector with C:H/I:H/A:H and AV:P yields 6.8. More importantly, IGEL OS 10 is end-of-life with no patch available—the only remediation is migration to OS 11 or OS 12. CISA added this to KEV on 2025-10-14, confirming active exploitation in the wild despite the physical-access requirement. The vendor severity understates the real risk for any organization still running IGEL OS 10 thin clients in semi-public environments like hospital nursing stations, retail kiosks, or call center floors.
5 steps from start to impact.
Obtain IGEL OS 10 boot artifacts
udc10.06.220.iso) and extracts the EFI binaries: bootx64.efi (Microsoft-signed shim), igelx64.efi (IGEL-signed GRUB), and bzImage (IGEL-signed vulnerable kernel with embedded initramfs). These are all legitimately signed and will pass Secure Boot verification on any device trusting the Microsoft 3rd Party UEFI CA.- Public availability of IGEL OS 10 ISO
- Knowledge of Secure Boot chain structure
- ISO is freely downloadable—no barrier
Craft malicious SquashFS root filesystem
igel-flash-driver module does not verify the cryptographic signature of the SquashFS image, any content can be substituted. The PoC by Zack Didcott (GitHub: Zedeldi/CVE-2025-47827) demonstrates this end-to-end.- Ability to create/modify SquashFS images (standard Linux tooling)
- Requires Linux knowledge and familiarity with SquashFS tools—low barrier for a motivated attacker
Gain physical access to target thin client
- Physical access to the target IGEL thin client
- Device trusts Microsoft 3rd Party UEFI CA (default on virtually all x86 hardware)
- Requires in-person presence at the device
- Locked BIOS/boot-order settings may slow (but not prevent) exploitation
- Some deployments use cable locks or kiosk enclosures
Boot through signed chain into unverified root filesystem
igel-flash-driver module, which mounts the attacker's crafted SquashFS image without verifying its signature. The attacker now has full control of the running OS. Optionally, the attacker uses the kexec_load syscall to hot-swap the kernel with a completely untrusted one.- Successful boot from crafted media
- igel-flash-driver signature check is not enforced (the vuln)
- None once physical access is achieved—the bypass is deterministic
Establish persistence and harvest credentials
/proc/cmdline to hide modified boot parameters, disables security modules via kernel parameter hijacking, and installs credential-harvesting hooks targeting VDI sessions (Citrix, VMware Horizon, AVD). Memory-resident encryption keys can be extracted. The compromised thin client now silently exfiltrates session credentials to a C2 channel over the existing network connection.- Successful Secure Boot bypass (step 4)
- Network connectivity from the thin client (standard in all deployments)
- Credential harvesting from VDI sessions requires knowledge of the specific VDI protocol in use
- Exfiltration traffic may be detected by NDR/SIEM if the thin client's network is monitored
The supporting signals.
| In-the-Wild Exploitation | Confirmed. CISA added CVE-2025-47827 to the KEV catalog on 2025-10-14 (CISA alert). Exploitation characterized as 'evil-maid' style physical attacks targeting thin clients in shared environments. Also included in Microsoft's October 2025 Patch Tuesday as a zero-day. |
|---|---|
| Proof-of-Concept | Public. Full PoC and writeup by Zack Didcott at github.com/Zedeldi/CVE-2025-47827. Demonstrates ISO extraction, SquashFS modification, bootable image creation, and kexec_load kernel replacement. |
| EPSS Score | 0.04927 (≈4.9% probability of exploitation in 30 days). This is elevated for a physical-access vector and reflects the KEV listing and public PoC availability. |
| KEV Status | Listed 2025-10-14. BOD 22-01 remediation deadline: 2025-11-03 for federal agencies. |
| CVSS Vector | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H → 4.6 MEDIUM (vendor). noisgate assessment: impact triad should be C:H/I:H/A:H given rootkit + credential theft capability, yielding 6.8 HIGH with AV:P. |
| Affected Versions | IGEL OS 10 (all versions, including final release 10.06.220). IGEL OS 11 and OS 12 are not affected. |
| Fixed Version | No patch exists. IGEL OS 10 is end-of-life. Remediation requires migration to IGEL OS 11+ or IGEL OS 12. Microsoft released a signed DBX revocation (2025-10-20) revoking the vulnerable IGEL shim signatures (DBX version 20250902+). |
| Scanning / Exposure | IGEL thin clients are LAN-attached endpoints, not internet-facing services—Shodan/Censys/GreyNoise exposure data is not applicable. Tenable plugin 282474 covers detection. Asset inventory via IGEL UMS console is the primary enumeration method. |
| Disclosure Timeline | 2024-12-06: Reported to IGEL. 2025-03-31: Reported to Microsoft. 2025-05-29: Public disclosure. 2025-06-02: IGEL ISN-2025-22 published. 2025-10-14: CISA KEV. 2025-10-20: Microsoft DBX revocation released. |
| Researcher | Zack Didcott (Zedeldi). Responsible disclosure with coordinated vendor and Microsoft engagement. |
Why this verdict
- Understated vendor impact triad: The vendor CVSS assigns
C:N/I:N/A:H—claiming zero confidentiality and zero integrity impact for a vulnerability that enables arbitrary kernel replacement, rootkit installation, and credential theft from VDI sessions. Correcting toC:H/I:H/A:HwithAV:Pyields 6.8, which accurately reflects the per-device devastation. - KEV-confirmed active exploitation: CISA added this to KEV on 2025-10-14 despite the physical-access vector, indicating real-world 'evil-maid' campaigns targeting thin clients in shared-access environments like healthcare facilities and call centers. This is not theoretical.
- No patch, EOL product: IGEL OS 10 is end-of-life with no security updates. The only remediation is full OS migration. This creates an indefinite exposure window for any organization that hasn't migrated—every day without action is another day the vuln is live.
- Physical access is less restrictive for this product class: IGEL thin clients are deployed in semi-public locations by design—nursing stations, kiosks, retail counters, shared desks. Physical access requirements that would be highly restrictive for a racked server are substantially less so for a thin client sitting on a reception desk.
- Role multiplier: IGEL thin clients occupy a *typical-role* position—they are VDI endpoints, not identity infrastructure, hypervisors, or domain controllers. Compromising one device yields host-level and session-level impact (VDI credential theft, local rootkit), not fleet-scale or domain-scale compromise. In healthcare deployments accessing EHR/PHI systems, the blast radius extends to *tenant-level* data exposure for that user's sessions, but does not reach domain takeover. This keeps the verdict at HIGH rather than CRITICAL—no high-value-role floor applies because thin clients are not canonically high-value infrastructure (they are <1% of the identity/hypervisor/CI-CD installed base).
Why not higher?
CRITICAL would require either a remotely exploitable vector or a high-value-role floor. IGEL thin clients are endpoints, not identity providers, domain controllers, or hypervisors. The blast radius of a single compromised device is bounded to that host's VDI sessions and local credentials—not fleet-scale or domain-scale. Physical access remains a genuine friction point even in semi-public deployments: it requires presence, limits scalability, and cannot be automated remotely.
Why not lower?
The KEV listing with confirmed exploitation, the complete absence of any patch (EOL product), and the public PoC that makes this trivially reproducible all prevent downgrading below HIGH. The vendor's MEDIUM rating is built on a demonstrably incorrect impact assessment that ignores the confidentiality and integrity consequences of a full Secure Boot bypass. Thin client deployment environments provide less physical security than the AV:P vector typically implies.
What to do — in priority order.
- Apply Microsoft DBX revocation immediately — Install the UEFI Secure Boot DBX update version 20250902 or later (released 2025-10-20) on all devices that have ever booted IGEL OS 10. This revokes the vulnerable IGEL shim signatures, preventing the boot chain from loading even if the crafted media is present. Deploy within 3 days per the noisgate mitigation SLA for KEV-listed vulnerabilities—treat as immediate due to active exploitation.
- Migrate all IGEL OS 10 devices to OS 11 or OS 12 — IGEL OS 10 is end-of-life with zero security support. The only remediation is OS migration. Prioritize devices in physically accessible locations (healthcare, retail, shared workspaces). Target completion within 30 days per the noisgate remediation SLA for HIGH severity. Use IGEL UMS to inventory and schedule firmware pushes.
- Add vulnerable kernel and shim hashes to DBX/MOKX deny lists — If the Microsoft DBX update cannot be applied uniformly (e.g., devices not managed via WSUS/Intune), manually add the SHA-256 hashes of the vulnerable
bootx64.efi,igelx64.efi, andbzImagebinaries to local DBX or MOKX deny lists. Hashes are published in the PoC repository. - Enforce BIOS boot-order locks and USB boot disablement — Configure BIOS/UEFI settings to disable USB boot and lock boot order with a supervisor password. This does not fix the vulnerability (an attacker with physical access and time can reset CMOS or write to internal storage), but it raises the bar for opportunistic exploitation. Deploy within 3 days on all IGEL OS 10 endpoints.
- Segment thin client VLANs with NDR monitoring — Place thin clients on dedicated VLANs with network detection and response (NDR) monitoring for anomalous outbound traffic. A rootkited thin client must exfiltrate credentials over the network—NDR can catch the C2 channel even when endpoint detection is blinded. Verify VLAN segmentation and NDR coverage within 3 days.
- Implement TPM-based remote attestation where hardware supports it — For devices with TPM 2.0, configure measured boot with remote attestation to detect tampered boot chains. This is a detection control, not prevention, but it provides visibility that Secure Boot alone no longer offers on compromised IGEL OS 10 devices.
- Endpoint Detection and Response (EDR) on the thin client itself — once the attacker controls the kernel via Secure Boot bypass, any userspace EDR agent is trivially subverted. The rootkit loads before EDR and controls what EDR can see. EDR on the thin client is *defense-in-depth noise*, not a compensating control for this specific vuln.
- Patching IGEL OS 10 — no patch exists or will ever exist. IGEL has declared OS 10 end-of-life. Waiting for a patch is waiting forever.
- Disabling the Microsoft 3rd Party UEFI CA — while this would prevent the vulnerable shim from loading, IGEL's own advisory warns this may have 'unintended consequences' by breaking other legitimate third-party bootloaders and Linux distributions on the same hardware. This is a scorched-earth option, not a practical enterprise control.
- Standard antivirus scanning — a kernel-level rootkit that controls
/proc,sysfs, and memory mappings will hide itself from any userspace scanning tool. AV is blind here.
Crowdsourced verification payload.
Run this script on each IGEL thin client endpoint (or push via IGEL UMS custom command). Requires root. Example: sudo bash check_cve_2025_47827.sh. It checks for IGEL OS 10 and the presence of the vulnerable igel-flash-driver module.
#!/usr/bin/env bash
# check_cve_2025_47827.sh
# Checks whether this IGEL endpoint is vulnerable to CVE-2025-47827
# (Secure Boot bypass via igel-flash-driver signature verification flaw)
# Run as root on the IGEL thin client.
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN
set -euo pipefail
VULNERABLE=0
PATCHED=1
UNKNOWN=2
# Check if this is an IGEL system
if [ ! -f /etc/igel/os-release ] && [ ! -f /etc/os-release ]; then
echo "UNKNOWN - Cannot determine OS. Not an IGEL device or os-release missing."
exit $UNKNOWN
fi
# Try IGEL-specific release file first, fall back to standard
RELEASE_FILE="/etc/igel/os-release"
if [ ! -f "$RELEASE_FILE" ]; then
RELEASE_FILE="/etc/os-release"
fi
# Check for IGEL OS identification
if ! grep -qi 'igel' "$RELEASE_FILE" 2>/dev/null; then
echo "UNKNOWN - This does not appear to be an IGEL OS device."
exit $UNKNOWN
fi
# Extract version - try multiple patterns
VERSION=""
if grep -qE 'VERSION_ID|FIRMWARE_VERSION' "$RELEASE_FILE" 2>/dev/null; then
VERSION=$(grep -E 'VERSION_ID|FIRMWARE_VERSION' "$RELEASE_FILE" | head -1 | grep -oE '[0-9]+\.[0-9]+' | head -1)
fi
# Also check /config/os-runlevel or /etc/igel/version if available
if [ -z "$VERSION" ] && [ -f /etc/igel/version ]; then
VERSION=$(cat /etc/igel/version | grep -oE '[0-9]+\.[0-9]+' | head -1)
fi
if [ -z "$VERSION" ]; then
# Check if igel-flash-driver module is loaded as a fallback indicator
if lsmod 2>/dev/null | grep -q 'igel_flash'; then
echo "VULNERABLE - igel-flash-driver module is loaded (likely IGEL OS 10)."
exit $VULNERABLE
fi
echo "UNKNOWN - Could not determine IGEL OS version."
exit $UNKNOWN
fi
MAJOR=$(echo "$VERSION" | cut -d'.' -f1)
if [ "$MAJOR" -lt 11 ] 2>/dev/null; then
echo "VULNERABLE - IGEL OS version $VERSION detected (< 11). CVE-2025-47827 applies."
echo " Action: Migrate to IGEL OS 11+ or OS 12. No patch exists for OS 10."
exit $VULNERABLE
elif [ "$MAJOR" -ge 11 ] 2>/dev/null; then
echo "PATCHED - IGEL OS version $VERSION detected (>= 11). Not affected by CVE-2025-47827."
exit $PATCHED
else
echo "UNKNOWN - Could not parse IGEL OS major version from '$VERSION'."
exit $UNKNOWN
fiWhat defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.