AISLE Discovers CVE-2026-42511: a 21-Year-Old FreeBSD Remote Command Execution Vulnerability

About FreeBSD

FreeBSD is often described as one of the most secure operating systems in the world, with its reputation arising from its high-quality networking stack, deliberate engineering, and a philosophy of security through simplicity. FreeBSD's history and usage are remarkable: it powers Netflix's Open Connect infrastructure, Sony's Playstation OS, part of Nintendo's Switch OS, Yahoo's backend services, NetApp's storage systems, Citrix's Netscaler, has long helped form the software base of major networking platforms (Cisco, Juniper, and so on), WhatsApp's backend services (historically), and is now the focus of a substantial Foundation effort to make it work better on modern laptops, and, for full disclosure, remains the author's personal operating system of choice.

CVE-2026-42511: Command Injection to Root RCE

AISLE discovered a remote command execution vulnerability in FreeBSD's dhclient, that is trivially weaponizable and wormable by any system on the same local network as the FreeBSD system. The vulnerability first entered FreeBSD in the 2005 release of FreeBSD-6.0 when OpenBSD's dhclient was imported, and lay dormant until discovered by AISLE. The vulnerability also affected OpenBSD until 2012, when that operating system deprecated dhclient-script completely, effectively fixing the vulnerability.

The initial flaw was identified by AISLE's AI-based source code analysis pipeline and then investigated by our triage agents. Joshua Rogers of AISLE's Offensive Security Research Team traced the relevant code paths, established the full security impact, and developed a proof of concept demonstrating a complete local-network-to-root exploit chain.

Recently budgeting $750,000 for key improvements to laptop support including greater Wi-Fi support, the attack surface here becomes even more relevant to everyday systems. A malicious wireless access point, or in some cases another attacker on the same Wi-Fi network able to spoof DHCP, can target the exact DHCP path that almost every wireless FreeBSD system will rely on. Imagine you're the author of this post, who runs FreeBSD on their laptop: you're at a coffee shop, airport, or hotel, and as soon as you connect your FreeBSD-equipped laptop to the Wi-Fi, your whole system is hijacked in secret. Imagine you have a PlayStation whose OS is locked down from any unofficial access, only to be jailbroken hijacked by connecting to a network. In other words, this vulnerability not only affects servers, but any FreeBSD machine that connects to a network using DHCP.

The vulnerability was a logic flaw that allowed attacker-controlled protocol data to be persisted into a trusted configuration-like format without proper sanitization, then later reinterpreted in a privileged execution path. That is exactly the kind of bug AISLE's autonomous security platform is built to find. Like our recent findings in OpenSSL, Firefox, libpng, and Amazon's Crypto Stack, this result came from disciplined engineering and end-to-end analysis, not model mythology.

This advisory was one of several FreeBSD security advisories resulting from vulnerabilities discovered by AISLE. AISLE also discovered the issues addressed in FreeBSD-SA-26:15.dhclient and FreeBSD-SA-26:16.libnv.

For a broader overview of AISLE's FreeBSD findings, including the other vulnerabilities disclosed in this coordinated release, see our companion post: AISLE Discovers 3 Critical Vulnerabilities in FreeBSD. While these are just the first of our published discoveries in FreeBSD, we are continuing to report more, working towards a more secure Operating System ecosystem.

We continue to report additional vulnerabilities to the FreeBSD project, several of which are still moving through the coordinated disclosure and remediation process.

In the sections that follow, we explain how the vulnerability works and how it can be exploited from the local network to gain root on a target system.

The Vulnerability

DHCP is the protocol most systems use to get an IP address and basic network settings automatically. dhclient is FreeBSD's DHCP client: it talks to the DHCP server, stores the lease it gets back in /var/db/dhclient.leases.<if>, and runs /sbin/dhclient-script to apply that configuration. Because leases are renewed periodically, dhclient runs as root not only at boot, but again during normal network operation.

The vulnerability leading to RCE starts in sbin/dhclient/dhclient.c, in the write_client_lease() function. dhclient writes data from the DHCP reply into the on-disk lease file at /var/db/dhclient.leases.<if>, using fairly simple logic, which builds the formatted file:

C
1    fprintf(leaseFile, "lease {\n");
2    if (lease->is_bootp)
3        fprintf(leaseFile, "  bootp;\n");
4    fprintf(leaseFile, "  interface \"%s\";\n", ip->name);
5    fprintf(leaseFile, "  fixed-address %s;\n", piaddr(lease->address));
6    if (lease->nextserver.len == sizeof(inaddr_any) &&
7        0 != memcmp(lease->nextserver.iabuf, &inaddr_any,
8        sizeof(inaddr_any)))
9        fprintf(leaseFile, "  next-server %s;\n",
10            piaddr(lease->nextserver));
11    if (lease->filename)
12        fprintf(leaseFile, "  filename \"%s\";\n", lease->filename);
13    if (lease->server_name)
14        fprintf(leaseFile, "  server-name \"%s\";\n",
15            lease->server_name);
16    if (lease->medium)
17        fprintf(leaseFile, "  medium \"%s\";\n", lease->medium->string);
18    for (i = 0; i < 256; i++)
19        if (lease->options[i].len)
20            fprintf(leaseFile, "  option %s %s;\n",
21                dhcp_options[i].name,
22                pretty_print_option(i, lease->options[i].data,
23                lease->options[i].len, 1, 1));
Copy

In the code above, dhclient writes lease data into /var/db/dhclient.leases.<if>. Several of the serialized fields are not remotely controllable. ip->name is the local interface name, and the address fields are first passed through piaddr(), which emits only valid IP-address text.

Likewise, lease->medium->string is generally not attacker-controlled through a DHCP reply; it is typically set locally by the system administrator. Lower in the snippet, DHCP options are also written into the lease file, but their contents are first passed through pretty_print_option(), which sanitizes the data. As a result, malicious DHCP option values do not directly provide the same injection primitive.

The problem is that lease->filename and lease->server_name are populated directly from fields supplied in the DHCP reply, yet are serialized verbatim with no sanitization. That gives an attacker the ability to write dangerous characters into the lease file, including " characters, newlines, and ; characters. In turn, this makes it possible to break out of the intended string field and inject new lease directives into the file.

From packet to poisoned lease file

Where do lease->filename and lease->server_name come from? These fields are part of the Bootstrap Protocol (BOOTP), and are standard fields used for the boot file name and the server name. A malicious server can simply send a DHCP reply with the BOOTP field file (corresponding to lease->filename) like this:

JavaScript
1file: ";\n medium ";id>/tmp/pwned
Copy

dhclient then writes that to /var/db/dhclient.leases.em1 in a form that looks like this:

JavaScript
1# cat /var/db/dhclient.leases.em1
2lease {
3 interface "em1";
4 fixed-address 192.168.100.50;
5 next-server 192.168.100.2;
6 filename "";
7 medium ";id>/tmp/pwned";
8[..]
9}
Copy

After the malicious DHCP reply is processed, the resulting lease file remains syntactically valid: the filename field becomes empty, and an injected medium directive is added with the value ;id>/tmp/pwned.

From poisoned lease to root code execution

The second part of the chain is in /sbin/dhclient-script. FreeBSD's dhclient-script is invoked by dhclient to configure the interface when leases are acquired and, importantly, when they are renewed. Along several normal DHCP lifecycle paths, including the ones linked here and here, dhclient invokes dhclient-script, which executes the following:

Bash
1eval "$IFCONFIG  $interface  $medium"
Copy

So once an attacker has injected a hostile medium value into the saved lease file, they have reached an eval sink inside a root-executed script. In practice, the flow becomes:

Bash
1eval "/sbin/ifconfig -n em1 ;id>/tmp/pwned"
Copy

id>/tmp/pwned then gets executed as root.

This is not just a one-shot boot-time issue. dhclient continues running and revisiting lease state over time, and dhclient-script is invoked repeatedly during the normal lifecycle of a DHCP-configured system. A malicious server does not need to win every renewal forever: it is enough to poison the lease file once and let ordinary restarts, renewals, rebinding, or other DHCP lifecycle events carry the payload back into a privileged path later.

The attack surface

Any attacker able to operate a malicious DHCP server on the same broadcast domain, or spoof one (DHCP is unauthenticated), can feed hostile lease data to the client. On wired networks, that may mean a rogue device on the local segment. On wireless networks, it may mean a malicious access point or, in some environments, another attacker on the same Wi-Fi network able to inject or spoof DHCP traffic. Because DHCP is the default way most systems obtain network configuration, this issue is relevant to a significant portion of FreeBSD deployments.

Summary of exploit

The exploit can be summarized as follows:

1. A malicious DHCP server, or another attacker on the same network able to spoof DHCP responses, replies to the client with a BOOTP file field containing embedded quotes and a crafted medium directive.
2. dhclient writes that value into the lease database using fprintf(... "filename \"%s\"; ...") without escaping embedded quotes.
3. The poisoned lease is later reparsed, and the injected medium directive becomes trusted lease state.
4. During later DHCP processing, including lease reload and startup-related paths, dhclient reparses the poisoned lease, stores the injected medium directive in lease state, passes that value through its script-setup path, and then invokes /sbin/dhclient-script with $reason and $medium set.
5. In the MEDIUM case, /sbin/dhclient-script executes eval "$IFCONFIG $interface $medium".
6. The attacker's shell metacharacters execute as root.

Conclusion

This FreeBSD dhclient issue is a critical local-network-to-root vulnerability built from two individually understandable mistakes: unescaped serialization of attacker-controlled DHCP data, and shell eval of a value later recovered from that stored state. Neither mistake depends on fancy exploitation, or requires a language-specific vulnerability, but together yield a clean root takeover path for any attacker able to answer DHCP requests on a local network.

At AISLE, we've built an autonomous security platform to discover real vulnerabilities in the software that underpins the world. Our platform handles the full vulnerability discovery phase that was used to find the vulnerability detailed in this post, as well as a remediation pipeline handling triage, patch generation, and verification. Developers and security teams get actionable fixes and solutions, rather than just a list of problems. If your organization depends on software you need to trust, reach out to us.

To read more about the discoveries we've made using our autonomous analyzer, check out these resources:

• AISLE Discovers 20 OpenSSL Zero-Days in 6 Months
• Using AISLE to Find Vulnerabilities in Amazon's Crypto Stack
• AISLE's CVE Wall of Fame

Our appreciation goes to the FreeBSD team for everything they do, and their work on fixing this issue. This vulnerability was discovered by Joshua Rogers using AISLE's autonomous analyzer.