Flaw in Dracut, a Core Linux Boot Tool: A Rogue Device on Your Network Can Hijack the System at Boot, CVE-2026-6893

A rogue device on the same network can hijack a PC or server the moment it powers on──a flaw like this has been found in Dracut, the tool that handles the "boot entry point" for much of the Linux world. It is CVE-2026-6893, rated CVSS 8.8 (High).

Dracut is a tool for building the tiny boot environment (the initramfs, an initial RAM disk) that runs before Linux brings up the main OS. Many Linux distributions used in enterprise environments — Fedora, RHEL (Red Hat Enterprise Linux) and its clones Rocky Linux and AlmaLinux, and SUSE — adopt it by default. It is developed by Red Hat, and this CVE too was assigned and published by Red Hat.

The problem lies in how settings are received from the network during the earliest stage of boot. When an attacker on the same network impersonates the server that hands out IP addresses (a DHCP server) and returns a crafted response, that content is written into the boot process's scripts without checking, and arbitrary commands run (OS command injection, CWE-78). Because the initramfs runs with the highest privileges (root, administrator), the machine is taken over entirely before any security software has even started. The affected systems are Linux machines configured to "boot over the network." Check Red Hat's security advisory and apply each distribution's update as it ships.

What Dracut Is, and Why Holding the Boot Entry Point Is Dangerous

Between pressing the power button and the usual desktop or services coming up, there is an invisible preparation stage. On Linux, a small temporary boot environment called the "initramfs" first runs in memory, finds and connects the real storage (a disk or network storage), and hands control over to the main OS there. Dracut is the tool that assembles this initramfs. The Fedora documentation describes it as a core boot component.

What matters here is that the earliest stage of boot is a defenseless window where everything runs with the highest privilege (root). At this point, login authentication, the firewall, and intrusion detection are not yet up. A system normally surrounded by many layers of defense is laid bare for those few boot seconds. If an attacker can inject a command from outside during that defenseless window, it is an ideal entry point.

That said, this flaw does not hit everyone. The target is limited to Linux configured to receive settings from the network at boot, where Dracut's "legacy DHCP path" runs. Specifically: PXE boot and diskless terminals that boot over the network, iSCSI/NFS root setups where the real storage sits on the network, and environments that pass ip=dhcp on the kernel command line. A laptop or server that simply boots from a local disk never runs this path, so it is out of scope.

Are You Affected? Tell by Distribution and Usage

"A flaw in Linux" does not mean every Linux is uniformly at risk. Separate it by two points: whether you use Dracut by default, and whether you boot over the network.

Ubuntu and Debian use a different mechanism (initramfs-tools) by default, so unless you installed Dracut yourself, they are not directly in scope. On the other hand, sites that mass-deploy many servers via network boot in bare-metal data center or cloud environments take a direct hit. The same goes for environments that PXE-boot thin clients, diskless terminals, or kiosk machines. First, inventory whether your organization has such configurations.

In the Few Seconds After Power-On, Someone on the Same Wire Slips In

Let's picture the scene where this flaw is triggered, from the attacker's side. The condition is that "the attacker is on the same network as the target." So the threat is not someone in a distant country, but an attacker who has broken into and settled on the corporate LAN, another tenant sharing the same segment in a data center, a disgruntled insider targeting PXE-booted office machines, or anyone in a position to plant a rogue device on shared Wi-Fi or a campus network. All they do is stand up a "rogue DHCP server" that answers faster than the real one. What they want is administrator privilege on the freshly booted machine, the auth keys and business data readable from it, and the neighboring machines they can topple next with the same trick.

Here is how it works. A machine that network-boots calls out "give me an IP address" right after power-on. The rogue DHCP server answers first, and into a field meant to convey the hostname and such (a DHCP option) it plants a string laced with quotes and semicolons. Dracut's legacy path writes that value straight into a temporary shell script, so the planted string is interpreted not as a "setting" but as a "command to run," and the attacker's commands start executing inside the boot process.

What makes it nasty is that this completes during the earliest boot stage, a window that barely registers in logs or alerts. Monitoring that kicks in after the OS is up may already be too late.

The number CVSS 8.8 is just a label for high technical severity. What a team running bare-metal or diskless infrastructure truly fears is having that defenseless instant before the guards come up exploited, so the machine boots as "the attacker's from the very start". Replace the foundation itself, and whatever defenses you stack on top are walked right past.

A Technical Look at CVE-2026-6893: Where and What Happens

CVE-2026-6893 is an OS command injection (CWE-78) that arises because Dracut's legacy DHCP path writes received DHCP options (such as a crafted malicious hostname) into a temporary shell script without escaping them properly. The CVSS vector is AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and the key point is that the attack vector is "adjacent network" (AV:A). It cannot be triggered directly from across the internet; the attacker must stand on the same network segment as the target (the same LAN / broadcast domain).

Conversely, no authentication is required (PR:N), no user interaction is needed (UI:N), and confidentiality, integrity, and availability all suffer severe impact (C:H/I:H/A:H). As long as they can get onto the same network, a party holding no login credentials at all can take over, with administrator privilege, a machine that merely boots. Red Hat has published this via its security advisory and Bugzilla (its bug-tracking system); as of publication, fixed versions for each distribution are being prepared and rolled out.

2026 Is Turning Into the Year of the "Rogue DHCP"

CVE-2026-6893 is not a rare one-off accident. Since the start of 2026, the same kind of flaw — "a rogue DHCP server returns a crafted response and the receiving side runs it as a command" — has surfaced one after another across different products. It is a shared weakness: behind the mundane mechanism of handing out IP addresses, the handling of strings inside the response was sloppy.

For example, CVE-2026-42511 in FreeBSD's DHCP client (dhclient) had lurked for 21 years: a rogue DHCP server merely mixing quotes into a field of its response achieved root-level command execution. Flaws in the DHCP/DNS software underpinning routers and IoT gear were also reported this year. The "traffic that just hands out IP addresses," which we normally never think about, is being re-evaluated as an entry point for attack — that is the trend of 2026. In environments where untrusted devices mix onto the same network, it is time to revisit the very assumption of trusting DHCP responses unconditionally.

Impact and Response Cheat Sheet

As of publication, this CVE is not listed in CISA KEV (the catalog of vulnerabilities confirmed exploited in the wild), and no actual exploitation has been reported. Even so, flaws touching the foundation of boot or authentication tend to leave you playing catch-up once exploitation is confirmed. The more a shared environment easily meets the attack condition (being on the same network), the sooner it needs attention.

What Administrators Should Do Now

In priority order. This is for organizations that use network boot.

1. Apply each distribution's update as it ships. The main fix is Dracut's patch. Fedora, RHEL, Rocky, AlmaLinux, SUSE and others ship a fixed Dracut via their security updates over time. Check your version's status on Red Hat's CVE page.

2. Isolate the network-boot path to a trusted segment. The attack assumes a "rogue DHCP server on the same network." Separate machines that use PXE boot or a network root onto a closed management network where no external or visitor devices mix, and enable switch-side mechanisms (such as DHCP snooping) that detect and block unauthorized DHCP servers.

3. Disable unnecessary network boot. For machines that do not operationally need network boot, remove ip=dhcp and the like from the kernel command line and switch to local-disk boot, so the vulnerable path never runs in the first place.

4. Review your bare-metal deployment procedures. If you mass-deploy many servers via network boot in a data center or cloud, confirm that the deployment network is closed to a trusted range. DHCP settings tend to be overlooked, and a neglected deployment segment makes an easy target.

Timeline

In Summary: The Few Seconds Before the Guards Come Up Were Targeted

What CVE-2026-6893 lays bare is that the "earliest boot stage," before security controls come up, has become a real attack surface. Because the boot environment Dracut assembles runs with the highest privilege, injecting a single command from outside lets everything stacked on top be bypassed. And the only condition for the attack is "being on the same network" — a condition more easily met the more a site does large-scale bare-metal or diskless deployment.

What to do is clear: apply each distribution's update as it ships, isolate the network-boot path to a trusted segment, and disable unnecessary network boot outright. That rogue-DHCP command injection has come in waves in 2026 shows the assumption of unconditionally trusting "traffic that just hands out IP addresses" no longer holds. Before real exploitation appears, harden your own network from the ground up.

References

• ▸NVD - CVE-2026-6893 (Dracut command injection via DHCP options)
• ▸Red Hat Security - CVE-2026-6893
• ▸Red Hat Bugzilla - Bug 2459963
• ▸Dracut - official repository (GitHub)
• ▸Fedora Project Wiki - Dracut
• ▸CWE-78 - OS Command Injection
• ▸securityonline.info - FreeBSD dhclient CVE-2026-42511 (rogue DHCP root command execution)
• ▸CISA KEV Catalog