Security researcher Alexander Moch of ERNW has uncovered a surprisingly effective method for bypassing Secure Boot protections on modern Linux systems. No, the vulnerability is not in the kernel or GRUB. Actually, it is in the initramfs, and it is hiding in plain sight.
Most hardening guides focus on well-known defenses like full disk encryption, password protected bootloaders, and Secure Boot. But few mention what happens if someone gets their hands on your laptop for just a few minutes. It turns out they can drop into a debug shell from the initramfs, modify it, and inject persistent malware all without ever touching the signed kernel or breaking Secure Boot.
On distributions like Ubuntu 25.04 and Fedora 42, repeatedly failing the password prompt for an encrypted root partition can trigger a debug shell. From there, Moch demonstrates how an attacker could use a USB drive with a few prepared scripts to chroot into the target system and modify the initramfs. A custom script can be inserted into the boot sequence that silently executes each time the system starts up.
The problem stems from the fact that the initramfs is not typically signed. While the kernel and its modules are signed for Secure Boot compliance, the initramfs remains unsigned because it is generated locally and tailored to the host. That makes it easy to modify with no alarms going off.
It’s worth mentioning, this is not a totally new attack. It echoes CVE 2016 4484 and similar techniques like EvilAbigail1 from 2015 and de LUKS2 from 2018, but it is still widely effective today. The attack was tested on modern distributions using default encrypted configurations, including systems with Secure Boot enabled. While some distributions like OpenSuSE Tumbleweed encrypt the boot partition by default and are more resilient, most others including Ubuntu are vulnerable out of the box.
Hardening tools like Lynis and even the CIS Benchmarks for Ubuntu and Red Hat do not mention this risk. NIST STIGs are also silent on the matter.
The fix is shockingly simple.
On Ubuntu, just add panic=0 to your kernel parameters. On Red Hat based systems, use rd.shell=0 rd.emergency=halt. This prevents the system from dropping into a debug shell during boot failures. Beyond that, users can require a bootloader password for every boot, not just when editing entries. Encrypting the boot partition with LUKS or enabling the SSD’s built in encryption are other solid steps.
Longer term solutions include using Unified Kernel Images which bundle and sign the kernel and initramfs together, or relying on TPMs to measure boot components. But those are not fully rolled out yet across the Linux ecosystem.
Moch’s full writeup includes proof of concept scripts and step by step instructions for modifying the initramfs once access to the debug shell is gained. While his demo uses a harmless timestamp writing script as an example, the same method could be used for far more serious attacks.
As Linux continues to grow on desktops and laptops, especially among developers and security conscious users, this kind of overlooked weakness matters. Physical access is a high bar, but not impossible. Hotel rooms, conference halls, and public workspaces make evil maid attacks more than theoretical.
This is not a reason to panic, folks. However, it is a good time to check your kernel parameters and review how your system handles boot failures. Secure Boot and full disk encryption are great tools, but only when the rest of the stack is not giving away the keys.
