← Back to Feed CACHED · 2026-09-23 14:48:51 · CACHE_KEY CVE-2025-47827
CVE-2025-47827 · CWE-347 · Disclosed 2025-06-05

In IGEL OS before 11

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"KEV-listed Secure Boot bypass on EOL thin clients demands immediate migration, not patching."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain IGEL OS 10 boot artifacts

The attacker downloads the publicly available IGEL OS 10 UDC installation ISO (e.g., 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.
Conditions required:
  • Public availability of IGEL OS 10 ISO
  • Knowledge of Secure Boot chain structure
Where this breaks in practice:
  • ISO is freely downloadable—no barrier
STEP 02

Craft malicious SquashFS root filesystem

The attacker modifies the SquashFS root filesystem image to include a rootkit, credential-harvesting tools, or a replacement kernel payload. Because the 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.
Conditions required:
  • Ability to create/modify SquashFS images (standard Linux tooling)
Where this breaks in practice:
  • Requires Linux knowledge and familiarity with SquashFS tools—low barrier for a motivated attacker
STEP 03

Gain physical access to target thin client

The attacker physically accesses the IGEL OS 10 thin client. In typical deployments—healthcare nursing stations, retail POS terminals, call center desks, hotel business centers—these devices sit in semi-public or shared spaces with minimal physical security. The attacker boots from a USB drive containing the crafted image or writes the modified SquashFS directly to the device's internal storage.
Conditions required:
  • Physical access to the target IGEL thin client
  • Device trusts Microsoft 3rd Party UEFI CA (default on virtually all x86 hardware)
Where this breaks in practice:
  • 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
Detection/coverage: Physical security cameras, badge-access logs. No network-based detection possible at this stage.
STEP 04

Boot through signed chain into unverified root filesystem

The device boots the Microsoft-signed shim → IGEL-signed GRUB → IGEL-signed vulnerable kernel. The kernel's embedded initramfs loads the 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.
Conditions required:
  • Successful boot from crafted media
  • igel-flash-driver signature check is not enforced (the vuln)
Where this breaks in practice:
  • None once physical access is achieved—the bypass is deterministic
Detection/coverage: Measured Boot with TPM attestation would detect the mismatch, but IGEL OS 10 does not enforce TPM-based attestation by default. No runtime detection is reliable once a rootkit kernel is loaded.
STEP 05

Establish persistence and harvest credentials

The rootkit kernel manipulates EFI variables to ensure the malicious boot chain persists across reboots. The attacker bind-mounts a fake /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.
Conditions required:
  • Successful Secure Boot bypass (step 4)
  • Network connectivity from the thin client (standard in all deployments)
Where this breaks in practice:
  • 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
Detection/coverage: NDR solutions monitoring thin client VLANs for anomalous outbound connections. Endpoint detection is unreliable—the rootkit controls the kernel. TPM remote attestation (if configured separately) would flag the tampered boot chain.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed. 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-ConceptPublic. 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 Score0.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 StatusListed 2025-10-14. BOD 22-01 remediation deadline: 2025-11-03 for federal agencies.
CVSS VectorCVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H4.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 VersionsIGEL OS 10 (all versions, including final release 10.06.220). IGEL OS 11 and OS 12 are not affected.
Fixed VersionNo 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 / ExposureIGEL 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 Timeline2024-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.
ResearcherZack Didcott (Zedeldi). Responsible disclosure with coordinated vendor and Microsoft engagement.
04 · The Call

Final Verdict
UPGRADED to HIGH (6.8/10)

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 to C:H/I:H/A:H with AV:P yields 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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, and bzImage binaries to local DBX or MOKX deny lists. Hashes are published in the PoC repository.
  4. 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.
  5. 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.
  6. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.