CVE-2026-45160: ESP-IDF DHCP Server Out-of-Bounds Read (CWE-125)

Technical summary

The vulnerability is an out-of-bounds read (CWE-125) in the parse_options() function within components/lwip/apps/dhcpserver/dhcpserver.c. The DHCP option parser iterates through the BOOTP/DHCP options field without bounds-checking each option's length field against the received packet size. An attacker can craft a DHCP request with a length value that exceeds the remaining buffer, causing the parser to read adjacent heap memory. This read-only flaw occurs at layer 2 (adjacent network access required) and does not directly enable code execution, but exposes memory contents and may trigger denial of service through heap corruption detection.

Business impact

Organizations deploying ESP-IDF-based IoT devices in bridged or access-point configurations face potential information leakage if an attacker on the same local network sends crafted DHCP packets. In manufacturing, smart home, or industrial IoT settings where ESP32 devices serve as network coordinators, this could expose sensitive configuration data, credentials, or firmware information stored in adjacent heap regions. Device crashes triggered by memory safety violations also reduce availability. The risk is primarily confined to local-network attack scenarios but may be chained with other vulnerabilities in products relying on ESP-IDF.

Affected systems

Vulnerable versions are ESP-IDF 5.2.7, 5.3.5, 5.4.4, 5.5.4, and 6.0.1. Any embedded system or IoT device built with these versions that uses the ESP-IDF DHCP server component—including Espressif's own reference designs and third-party products using ESP32, ESP32-S2, ESP32-C3, and other supported chips—is potentially affected. The risk is highest when devices are configured as DHCP servers (e.g., SoftAP mode), a common pattern in smart home hubs, mesh network nodes, and field-deployed industrial gateways.

Exploitability

Exploitation requires adjacent network access (AV:A); an attacker must be on the same Layer 2 network segment as the vulnerable device. No authentication is needed (PR:N), and exploitation is straightforward—sending a crafted DHCP request requires only UDP manipulation, well within the reach of standard penetration testing tools. However, the attack is not remotely exploitable over the Internet. Given the DHCP server use case, devices in corporate networks, guest networks, or IoT clusters are at moderate risk from insider threats or network-adjacent attackers. The lack of a known public exploit or KEV inclusion suggests active exploitation is not yet widespread, but the simplicity of crafting a malformed DHCP packet means weaponization is trivial.

Remediation

Upgrade ESP-IDF to patched versions: 5.2.8, 5.3.6, 5.4.5, 5.5.5, or 6.0.2, depending on your active release line. The patch adds proper bounds validation to the options parser. Organizations should prioritize devices in production that actively serve as DHCP servers (e.g., access points or gateways) before updating client-mode or non-DHCP devices. Interim mitigations include network segmentation to restrict DHCP request traffic to trusted sources or disabling SoftAP/DHCP server functionality if not essential.

Patch guidance

Review your device firmware and identify the currently deployed ESP-IDF version. Consult Espressif's release notes and security advisories to confirm which major version family (5.2.x, 5.3.x, etc.) you use. Plan updates within your product lifecycle; if your firmware is based on ESP-IDF 5.4.4, upgrade to 5.4.5. For new development, use the latest stable version (6.0.2 or later). Test patched builds in a staging environment to verify DHCP server functionality and WiFi stability before production rollout. Prioritize fleet updates for edge devices (gateways, access points) first.

Detection guidance

Detection of exploitation in real time is challenging without firmware instrumentation. Monitor network logs for repeated or malformed DHCP requests from untrusted clients, particularly those with unusually long option fields or non-standard length values. Firmware-level detection via a monitor or modified lwIP could log parse_options() anomalies, but this requires custom instrumentation. For forensic analysis, inspect device logs and memory dumps for evidence of out-of-bounds reads (e.g., heap corruption messages or unexpected crashes correlating with DHCP traffic). Threat hunting should focus on local-network sources (ARP scanning, DHCP monitoring) that might probe DHCP servers.

Why prioritize this

Although CVSS 6.5 (MEDIUM) reflects the limited attack surface (adjacent network only), the combination of ease of exploitation and potential for data leakage justifies prompt remediation. DHCP servers are long-lived processes in IoT deployments, and a single successful probe can exfiltrate heap contents. The vulnerability affects multiple active major versions, creating a broad upgrade burden. Without KEV inclusion, there is currently no government mandate, but organizations should treat this as a targeted remediation candidate for any device in a DHCP server role within the next 30–60 days.

Risk score, explained

CVSS 6.5 reflects availability impact (A:H) and confidentiality risk, balanced against the adjacent-network-only attack vector. The score does not account for business context: a DHCP server in an industrial IoT environment handling sensitive data may warrant a higher internal severity rating. The lack of immediate exploitability in KEV suggests this is a proactive disclosure, giving teams breathing room. However, simplicity of exploitation and multi-version impact argue for treating this as elevated priority relative to the base CVSS score in IoT-centric environments.

Frequently asked questions