CVE-2026-113783 in ESP-IDF
Summary
by MITRE • 11/04/2026
ESP-IDF is the Espressif Internet of Things (IOT) Development Framework. From 5.2.3 until 5.3.7, 5.4.5, 5.5.6, and 6.0.3, the lwIP DNS resolver's cached-lookup path in dns_lookup() in dns.c copies every cached address into a caller-provided single ip_addr_t output buffer without a length parameter or bounds check. When CONFIG_LWIP_DNS_MAX_HOST_IP is greater than 1 and a cached hostname has multiple A or AAAA records, a subsequent lookup through dns_gethostbyname() or dns_gethostbyname_addrtype() writes beyond the single-element buffer into adjacent stack memory. A network-positioned attacker who influences DNS responses can cause a reboot through stack-canary corruption or, without stack protection, overwrite stack variables with attacker-controlled address bytes and potentially redirect control flow. This issue is fixed in versions 5.5.6 and 6.0.3 and is scheduled to be fixed in versions 5.3.7 and 5.4.5. No fixed release is available for the end-of-life 5.2 line.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability resides within the lwIP TCP/IP stack implementation used by Espressif ESP-IDF, specifically affecting the DNS resolver module in versions ranging from 5.2.3 through 6.0.3 with specific patches available for later sub-versions. The core technical flaw is a classic buffer overflow occurring during cached DNS lookups. When the system configuration parameter CONFIG_LWIP_DNS_MAX_HOST_IP is set to a value greater than one, indicating that multiple IP addresses are expected for a single hostname, the dns_lookup function in dns.c fails to perform necessary bounds checking. Instead of allocating or validating space for an array of ip_addr_t structures, the code copies every cached address record into a caller-provided buffer designed as a single-element container. This architectural oversight means that if a DNS response contains multiple A or AAAA records, the write operation proceeds sequentially beyond the allocated memory boundaries, corrupting adjacent stack memory locations.
From an operational impact perspective, this vulnerability allows for severe consequences depending on the compiler and linker configurations of the target device. In environments where stack canaries are enabled, the overflow will likely trigger a detection mechanism that results in an immediate application crash or system reboot, leading to a denial-of-service condition. However, in systems without such protections, which is common in many embedded IoT deployments for performance reasons, the attacker gains significant control over execution flow. By manipulating DNS responses, a network-positioned adversary can overwrite stack variables with controlled address bytes. This capability enables arbitrary code execution by redirecting function return addresses or exploiting other stack-based logic flows, effectively compromising the integrity and confidentiality of the device.
The attack vector is classified as remote, requiring only that the attacker be positioned on the same network segment capable of influencing DNS resolution for the target device. This aligns with ATT&CK techniques related to resource hijacking via compromised infrastructure or malicious domain registration, specifically mapping to T1598 Phishing for Information and potentially T1071 Application Layer Protocol if used in conjunction with other exploitation methods. The vulnerability is fundamentally a CWE-121 stack-based buffer overflow, stemming from insufficient validation of input data length relative to the destination buffer size. This type of flaw is particularly dangerous in IoT contexts where devices often operate continuously without restarts and may handle sensitive operational commands once code execution is achieved.
Mitigation strategies primarily involve upgrading to patched versions of ESP-IDF, specifically 5.5.6 or 6.0.3 for current supported lines, with scheduled fixes for 5.3.7 and 5.4.5. For devices running the end-of-life 5.2 line, no official patch is available, necessitating alternative countermeasures such as network segmentation to isolate IoT devices from untrusted networks or implementing DNS filtering at the gateway level to prevent resolution of maliciously crafted responses containing multiple IP records. Additionally, developers should ensure that stack protection flags are enabled during compilation where performance constraints allow, and review application code to avoid relying on unsafe legacy APIs like dns_gethostbyname without verifying buffer sizes explicitly before invocation.