CVE-2026-113783: ESP-IDF: Stack-based memory corruption in lwIP DNS/SNTP handling for multi-IP DNS responses
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 dnslookup() in dns.c copies every cached address into a caller-provided single ipaddrt output buffer without a length parameter or bounds check. When CONFIGLWIPDNSMAXHOSTIP is greater than 1 and a cached hostname has multiple A or AAAA records, a subsequent lookup through dnsgethostbyname() or dnsgethostbynameaddrtype() 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ESP-IDFto a version that resolves this vulnerability.Fixed in 5.3.7 - Upgrade
Upgrade
ESP-IDFto a version that resolves this vulnerability.Fixed in 5.4.5 - Upgrade
Upgrade
ESP-IDFto a version that resolves this vulnerability.Fixed in 5.5.6 - Upgrade
Upgrade
ESP-IDFto a version that resolves this vulnerability.Fixed in 6.0.3
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using affected ESP-IDF releases are exposed when CONFIG_LWIP_DNS_MAX_HOST_IP is greater than 1 and the DNS resolver caches a hostname with multiple A or AAAA records. The vulnerable lookup path is reached through dns_gethostbyname() or dns_gethostbyname_addrtype().
What does an attacker need to exploit it?
An attacker needs network position sufficient to influence DNS responses. They must cause a hostname with multiple A or AAAA records to be cached and then trigger a subsequent affected DNS lookup.
What happens if the device has stack-canary protection enabled?
Stack-canary corruption can cause the device to reboot. Without stack protection, attacker-controlled address bytes can overwrite adjacent stack variables and may potentially redirect control flow.
What can be done if an immediate upgrade is not possible?
The provided information identifies CONFIG_LWIP_DNS_MAX_HOST_IP greater than 1 as a condition for the vulnerable behavior. Reducing this setting so it is not greater than 1 avoids the described multi-address cached-lookup condition.
Which release lines have fixes available?
Fixed releases are available in 5.5.6 and 6.0.3. Fixes are scheduled for 5.3.7 and 5.4.5, while no fixed release is available for the end-of-life 5.2 line.