FreeBSD DHCP client flaw can let rogue servers run code as root

FreeBSD administrators should update their systems after the project patched a DHCP client vulnerability that can allow a rogue DHCP server to execute code as root.

The flaw is tracked as CVE-2026-42511 and affects all supported versions of FreeBSD. It sits in dhclient, the default IPv4 DHCP client used by FreeBSD to request network configuration from DHCP servers.

The attack requires local network access. An attacker must operate on the same broadcast domain as the target and respond to DHCP requests with malicious data.

What FreeBSD fixed

FreeBSD published the security advisory on April 29, 2026, under FreeBSD-SA-26:12.dhclient. The project credited Joshua Rogers of the AISLE Research Team for reporting the issue.

The vulnerable code writes the BOOTP file field to a DHCP lease file without correctly escaping embedded double quotes. That mistake can let an attacker inject arbitrary dhclient.conf directives.

The injected content becomes dangerous when dhclient later re-parses the lease file, such as after a restart. At that point, attacker-controlled data can reach dhclient-script, which evaluates it with root privileges.

At a glance

Item	Details
CVE	CVE-2026-42511
Advisory	FreeBSD-SA-26:12.dhclient
Affected component	dhclient, the default IPv4 DHCP client on FreeBSD
Affected systems	All supported FreeBSD versions
Attack requirement	Attacker must be on the same broadcast domain
Main impact	Possible arbitrary code execution as root
Workaround	No direct software workaround for systems that run dhclient

Why the DHCP flaw is serious

DHCP runs early in the network setup process, and many systems trust DHCP responses to configure addresses, routes, and related network options.

In this case, a rogue DHCP server can send a crafted BOOTP file field. FreeBSD then stores that field in the lease file in a way that can change how dhclient behaves when it reads the file again.

If exploitation succeeds, the attacker may run commands as root. That gives them the highest privilege level on the affected system.

Who is at risk

The most exposed systems are FreeBSD machines that use DHCP on networks where an attacker can introduce or spoof a DHCP server.

This includes untrusted LANs, shared office networks, student networks, lab environments, hosting networks, and any poorly segmented environment where rogue DHCP replies can reach clients.

The issue also deserves attention because FreeBSD often powers firewalls, routers, network appliances, and embedded systems. Those devices may sit in places where DHCP spoofing can cause more damage than it would on a regular workstation.

Affected branches and corrected releases

Branch or release line	Corrected version or branch state
15.0-STABLE	Corrected after April 29, 2026, 14:47:47 UTC
15.0-RELEASE	15.0-RELEASE-p7
14.4-STABLE	Corrected after April 29, 2026, 14:48:50 UTC
14.4-RELEASE	14.4-RELEASE-p3
14.3-RELEASE	14.3-RELEASE-p12
13.5-STABLE	Corrected after April 29, 2026, 14:50:06 UTC
13.5-RELEASE	13.5-RELEASE-p13

How administrators should patch

FreeBSD says administrators should upgrade vulnerable systems to a supported FreeBSD stable branch or release security branch dated after the correction time.

Systems installed from FreeBSD base system packages on amd64 or arm64 with FreeBSD 15.0-RELEASE can use pkg to update the base system packages.

Other supported release systems installed from binary distribution sets can use freebsd-update. Administrators who manage source-based systems can apply the official source patch and rebuild the operating system.

Update commands

# pkg upgrade -r FreeBSD-base

# freebsd-update fetch
# freebsd-update install

After applying the fix, administrators should restart the affected daemons or reboot the system. Rebooting may provide the cleanest path for systems that rely on dhclient during startup.

Mitigation options

FreeBSD says no workaround exists for systems that must run dhclient. Systems that do not run dhclient are not affected.

Network teams can reduce the risk by blocking rogue DHCP servers. The FreeBSD advisory specifically points to DHCP snooping on managed switches as a defensive control.

DHCP snooping helps separate trusted DHCP server ports from untrusted client ports. That can prevent a malicious host on the same network from handing out crafted DHCP responses.

Recommended response checklist

• Identify FreeBSD systems that use dhclient for IPv4 configuration.
• Prioritize laptops, appliances, routers, firewalls, and systems on shared networks.
• Update supported systems to corrected release or stable branch versions.
• Reboot systems or restart affected services after patching.
• Enable DHCP snooping on enterprise switches where available.
• Limit DHCP traffic to trusted network segments.
• Investigate unexpected DHCP servers or sudden lease changes.
• Replace unsupported FreeBSD installations with supported versions.

Why local network bugs still matter

The attacker does not need internet-level access to exploit this flaw. However, local network access is not a small requirement in many real environments.

Employees, guests, contractors, compromised devices, exposed lab machines, and infected laptops can all create local network risk. A rogue DHCP server attack can also happen quickly if switching controls are weak.

That makes this vulnerability important for organizations that run FreeBSD systems in mixed or semi-trusted environments. Patching should come first, and network controls should reduce the chance of repeat exposure.

FAQ