SURIQ
In June, Red Hat shipped a fix for a dracut flaw that let a rogue DHCP server run commands as root while a Linux machine booted over the network. That fix, for CVE-2026-6893, closed one door. It did not close the other. On August 7 Red Hat published CVE-2026-15816, a second root code-execution path in the same boot tool, scored CVSS 7.5 and rated Important, that the first patch never touched.
The exposure is narrow, and worth stating plainly up front. This only reaches systems that boot over the network and take their root filesystem from a DHCP-supplied path. A server that boots off its local disk is not affected. But for the fleets this does touch, the diskless clusters, the PXE-provisioned racks, the thin-client estates, the payoff for an attacker is the highest one there is: code running as root before the operating system has finished coming up.
What the second dracut bug actually does
Dracut builds the initramfs, the small temporary root filesystem the kernel uses to find and mount the real one. When something goes wrong that early in boot, dracut calls its die() function to print an error and drop to an emergency shell. The flaw is in how die() records that error. It writes the message into a script under the initramfs emergency-hook directory without shell-quoting it, per Red Hat's advisory and the Red Hat bug report.
That is harmless until the message carries attacker-controlled text. On a network boot, dracut derives the $netroot value from the DHCP ROOT_PATH option. When the root handler fails to resolve, netroot.sh hands that value to die(). A command-substitution sequence such as $(...) tucked inside ROOT_PATH survives into the generated hook script unquoted, and executes as root the next time dracut sources those hooks during its ordinary boot-failure handling. An attacker running a rogue DHCP server on the same network segment controls that value.
The two dracut CVEs are cousins, not duplicates. CVE-2026-6893, fixed in dracut-107-7.el10_2 through RHSA-2026:26532 on June 17, sanitized DHCP values inside dhclient-script.sh. It left die() in dracut-lib.sh alone. CVE-2026-15816 is that untouched path, and Red Hat's advisory is explicit that it is a different code path than the one the earlier CVE addressed.
Who is actually exposed
Read the CVSS vector before you page anyone. It is AV:A/AC:H: adjacent network, high attack complexity. The attacker needs a foothold on the same layer-2 segment as the target, needs the target to be network-booting with a DHCP-supplied root path, and needs a boot failure to reach the emergency-hook code. There is no report of exploitation in the wild, no CISA Known Exploited Vulnerabilities (KEV) listing, and no public exploit as of writing. This is a hardening job, not a fire drill.
That said, the population that network-boots is exactly the population where one rogue DHCP answer scales. Provisioning networks, high-performance-computing and render farms, diskless workstation pools, and bare-metal cloud imaging all hand the boot path to whatever answers DHCP first. If your imaging network is flat and anyone on it can stand up a DHCP server, the precondition is already met.
The real lesson is the half-finished patch
We keep seeing the same shape. A vendor fixes the instance a researcher reported, stops at the reported file, and does not audit every place the same untrusted input can flow. We wrote about this recently with N-able N-central's incomplete auth-bypass patch, and it is the story here too. DHCP-derived data reaches root context through more than one function in dracut, and only one of them got quoted the first time. When you triage CVE-2026-15816, do not assume the second path is the last one. Treat any code that writes DHCP-sourced strings into a sourced script as suspect until it is proven quoted.
Patch dracut, then control who answers DHCP
Two tracks, and the second matters more than admins expect.
- Apply the dracut update. Red Hat has published the CVE and rates it Important. Install the dracut security update for your distribution as the errata land, then regenerate your initramfs so the fixed
die()is what actually ships in your boot image. The upstream fix replaces the unsafe quoting withprintf '%q', so a stale initramfs built before the patch stays vulnerable even after the package is updated. - Lock down the DHCP path on boot networks. Turn on DHCP snooping on the switches serving your provisioning and netboot VLANs, so only authorized servers can hand out leases. Put network booting on a dedicated, segmented VLAN rather than a flat management network. This is the control that holds even against the next dracut bug in this family.
Detection is thin here by design, and worth being honest about. Code that runs inside the initramfs leaves almost nothing in your normal host logs, because it executes before the logging stack is up. The signal you can actually collect is on the network: an unexpected DHCP server offering leases on a boot segment, or hosts unexpectedly dropping to emergency boot. That maps to the adversary-in-the-middle and pre-OS-boot techniques (ATT&CK T1557.003 and T1542), and it is where a managed detection setup earns its keep. Suriq watches for that kind of anomalous behavior on the segments it monitors and maps it to MITRE ATT&CK, but the durable fix is still the patched initramfs plus a DHCP path only your own servers can answer.
CVE-2026-15816 is not the bug that takes down the internet this week. It is a reminder that a security fix is only as complete as the audit behind it, and that the boot path, the code that runs before anything is watching, is exactly where a half-finished patch hurts most. Patch dracut, rebuild your images, and stop trusting whatever answers DHCP on the network you boot from.
| CVE-2026-6893 | CVE-2026-15816 | |
|---|---|---|
| Where the bug lives | dhclient-script.sh, DHCP option parsing | die() in dracut-lib.sh, the error handler |
| How it triggers | Crafted DHCP options during network boot | A crafted ROOT_PATH value reaches die() and is written unquoted into an emergency-hook script |
| Fix status | Patched: dracut-107-7.el10_2, RHSA-2026:26532, June 17 2026 | Separate dracut update; the CVE-2026-6893 patch did not touch die() |
| Shared traits | Adjacent-network rogue DHCP server, root code execution during boot, Red Hat severity Important, CVSS 7.5 | |