CVE-2026-6893

What it actually does

The vulnerability is a command injection flaw in dracut's legacy DHCP handling during early boot. A system booting with dracut-generated initramfs and using the affected legacy network/DHCP path may accept attacker-controlled DHCP options from an adjacent network. Values such as hostname are written into temporary shell scripts without sufficient escaping, allowing shell metacharacters to be interpreted as commands. Successful exploitation results in arbitrary command execution as root inside the initramfs environment, before the full operating system is mounted and normal host defenses may be active.

Why it matters to the business

An attacker with access to the same local network segment as a vulnerable booting system could compromise that system at startup, potentially altering boot behavior, intercepting or changing network configuration, tampering with disks or mounted filesystems, and establishing persistence before normal monitoring starts. The risk is highest for systems that use network boot, early-boot networking, automated provisioning, or recovery workflows where DHCP is trusted. Although the CVSS score is high, exploitation requires adjacent-network access and a specific legacy DHCP path; the current EPSS is low and the issue is not listed in CISA KEV, so remediation should be prioritized for exposed boot/provisioning networks and critical Linux infrastructure.

How an attack unfolds

An attacker first gains the ability to influence DHCP traffic on the victim's local Layer 2 network, either by operating a rogue DHCP server, winning a DHCP race, or compromising legitimate DHCP infrastructure. When a vulnerable system boots and dracut initializes early networking through the legacy DHCP path, it requests DHCP configuration. The attacker responds with crafted DHCP options, for example a hostname containing shell syntax. dracut improperly writes that value into a temporary shell script used during initramfs network setup. When the script is sourced or executed, the injected shell fragment runs as root in the initramfs context. From there, the attacker may modify boot-time network configuration, tamper with mounted storage if available, drop files for later execution, alter initramfs behavior, or pivot into the fully booted system depending on how the host is configured.

How to fix it

Upgrade dracut to a vendor-fixed release as soon as packages are available for the affected distribution. No exact fixed package versions were provided in the input, so use the distribution vendor advisory as the source of truth and rebuild/regenerate affected initramfs images after updating dracut. Where immediate patching is not possible, reduce exposure by disabling dracut legacy DHCP paths where not required, avoiding untrusted DHCP on boot/provisioning networks, using DHCP snooping or equivalent switch controls, restricting who can operate DHCP servers, isolating PXE/provisioning networks, and preferring authenticated or tightly controlled boot-time network configuration. After patching, regenerate initramfs images for installed kernels and reboot systems that rely on early-boot networking so the corrected scripts are actually used.

How to confirm the fix worked

Confirm the installed dracut package version matches the fixed version listed by the operating system vendor. Verify that initramfs images were regenerated after the package update, not merely that the package was installed. Review boot configuration for kernel command-line options and dracut modules that enable early networking or legacy DHCP behavior. In a controlled lab only, test that DHCP option values containing shell metacharacters are safely escaped and do not execute during initramfs network setup. On production networks, validate that DHCP snooping, rogue-DHCP detection, and provisioning-network segmentation prevent unauthorized DHCP responses. Exposure exists primarily where systems use dracut early-boot networking with DHCP on networks where an attacker could send DHCP replies.

Typical attack path

1. Obtain access to the same broadcast domain or provisioning network as systems that boot using dracut early networking.
2. Run or compromise a DHCP service capable of answering victim DHCP requests.
3. Craft DHCP options, such as hostname, containing shell metacharacters or command substitution payloads.
4. Wait for or trigger a vulnerable system to boot and request DHCP configuration through dracut's legacy DHCP path.
5. Deliver the malicious DHCP response before or instead of the legitimate DHCP server.
6. Cause dracut to write the malicious option value into a temporary shell script without proper escaping.
7. Achieve root command execution inside the initramfs environment when the generated script is evaluated.
8. Use early-boot access to alter network behavior, tamper with mounted filesystems, implant persistence, or continue execution into the normal operating system.

How to detect it

Look for evidence of rogue DHCP activity and suspicious DHCP option values around system boot times. Useful sources include DHCP server logs, switch DHCP-snooping logs, network access control logs, packet captures from provisioning networks, PXE or bare-metal management logs, console logs, journald from the prior boot where available, and forensic images of boot partitions and regenerated initramfs content. Focus on DHCP hostname or other option values containing shell metacharacters such as semicolons, pipes, backticks, command substitution, redirection, or encoded shell commands. Because code execution occurs inside initramfs, normal endpoint telemetry may not capture the initial payload; absence of EDR alerts does not rule out exploitation. Investigate unexpected DHCP servers, duplicate DHCP offers, abnormal boot-time hostnames, early-boot outbound connections, unexplained changes to initramfs images, bootloader configuration, init scripts, network configuration, SSH keys, cron/systemd persistence, and files modified during boot windows. If suspected, acquire disk images and compare initramfs, bootloader, and early userspace artifacts against known-good builds.

• DHCP hostname containing ';'
• DHCP hostname containing '$('
• DHCP hostname containing '`'
• DHCP hostname containing '|'
• DHCP hostname containing '&&'
• DHCP hostname containing '||'
• DHCP hostname containing '>'
• DHCP hostname containing '<'
• DHCP option value containing '/bin/sh'
• DHCP option value containing '/bin/bash'
• DHCP option value containing 'curl '
• DHCP option value containing 'wget '
• DHCP option value containing 'nc '
• DHCP option value containing 'ncat '
• DHCP option value containing 'mkfifo'
• DHCP option value containing 'chmod +x'
• log string: rogue DHCP server
• log string: DHCP snooping violation
• log string: DHCPACK
• log string: DHCPOFFER
• log string: dracut-initqueue
• log string: dracut:
• file path: /boot/initramfs-
• file path: /run/initramfs/
• file path: /etc/dracut.conf
• file path: /etc/dracut.conf.d/

What your security team should do

• Inventory Linux systems that use dracut-generated initramfs images with early-boot networking, network boot, PXE, iSCSI root, NFS root, automated provisioning, or recovery boot workflows.
• Prioritize patching for systems on shared, workstation-adjacent, data-center provisioning, bare-metal, or recovery networks where rogue DHCP responses are plausible.
• Track vendor advisories for exact fixed dracut package versions and regenerate initramfs images after updating.
• Harden network infrastructure with DHCP snooping, trusted DHCP ports, dynamic ARP inspection where applicable, and alerts for rogue DHCP servers.
• Restrict provisioning and boot networks to trusted infrastructure only; do not allow general user devices or unmanaged systems on those segments.
• Review DHCP server logs, switch telemetry, and early-boot logs for suspicious hostname or DHCP option values containing shell metacharacters.
• If exploitation is suspected, treat affected hosts as potentially compromised from pre-OS boot, preserve disks and boot artifacts, and perform offline forensic review rather than relying only on in-OS telemetry.
• Because the issue is not currently in KEV and EPSS is low, use risk-based prioritization, but do not defer remediation on critical boot infrastructure or environments with weak Layer 2 controls.