ESP-IDF · CVE-2026-113783 · Vendor
FIX → 5.5.6 · 6.0.3 ✓ verified
ESP-IDF, Espressif's framework for ESP32 IoT chips, has a stack buffer overflow in its lwIP DNS resolver when cached hostnames return multiple addresses. A network attacker who can influence DNS responses can reboot the device or, without stack protection, overwrite stack data and potentially redirect control flow.
first public Oct 30, 2026 · 2 sources
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Only devices built with ESP-IDF in the affected version ranges that enable lwIP DNS with CONFIG_LWIP_DNS_MAX_HOST_IP greater than 1 and resolve hostnames with multiple A or AAAA records. The attacker must be positioned to influence DNS responses on the network the device uses. Firmware built on a patched version, or devices that do not use multi-address DNS caching, can skip it.
Not affected if default-config, esp-idf-5.1-or-earlier, no-dns-multi-record, patched-version
Who cares embedded, esp-idf, esp32, iot, lwip
idf.py menuconfig or grep sdkconfig for CONFIG_LWIP_DNS_MAX_HOST_IP: if it is 1 (the default) you are not exposedidf.py --version is 5.2.3-5.2.8, 5.3.2-5.3.6, 5.4-5.4.4, 5.5-5.5.5 or 6.0-6.0.2, you are affected when the device resolves a multi-record hostname (e.gUpgrade to 5.5.6 · 6.0.3
5.5.6 (5.5.x) or 6.0.3 (6.0.x). 5.4.5 and 5.3.7 are marked yet to be released in the advisory (no dates given; 5.4.x and 5.3.x users should keep CONFIG_LWIP_DNS_MAX_HOST_IP=1 until then). 5.2.x is end-of-life with no fix: migrate to a supported line. 5.1 and earlier are not affectedESP-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.
This page as .md · .json · in your agent: get_signal("CVE-2026-113783") · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.