--- id: "CVE-2026-113783" kind: "vulnerability" aliases: ["CVE-2026-113783"] title: "ESP-IDF: DNS cache stack overflow when CONFIG_LWIP_DNS_MAX_HOST_IP is above 1 can reboot devices" severity: "high" cvss: 7.4 epss: null exploited: false status: "open" category: "vendor" products: [{"name": "esp-idf", "fixed": ["5.5.6", "6.0.3"], "affected": ">= 5.2.3, <= 5.2.8; >= 5.3.2, < 5.3.7; >= 5.4, < 5.4.5; >= 5.5, < 5.5.6; >= 6.0, < 6.0.3", "ecosystem": "vendor"}] ecosystems: [] tags: ["embedded", "esp-idf", "esp32", "iot", "lwip", "vendor"] not_affected_if: ["default-config", "esp-idf-5.1-or-earlier", "no-dns-multi-record", "patched-version"] published_at: "2026-11-04T19:17:18+00:00" first_seen_at: "2026-11-04T19:28:48+00:00" updated_at: "2026-11-04T19:31:03+00:00" sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113783", "first_seen_at": "2026-11-04T19:28:48+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-04T19:31:03+00:00"}] --- # ESP-IDF: DNS cache stack overflow when CONFIG_LWIP_DNS_MAX_HOST_IP is above 1 can reboot devices 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. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - vendor:esp-idf affected >= 5.2.3, <= 5.2.8; >= 5.3.2, < 5.3.7; >= 5.4, < 5.4.5; >= 5.5, < 5.5.6; >= 6.0, < 6.0.3 fixed 5.5.6, 6.0.3 ## How to check In your project run 'idf.py menuconfig' or grep sdkconfig for CONFIG_LWIP_DNS_MAX_HOST_IP: if it is 1 (the default) you are not exposed. If it is 2 or higher and 'idf.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.g. NTP pools via the SNTP client). The protocols/dns_over_https example ships with a value of 4. Workarounds (vendor): keep the option at 1; or enable CONFIG_COMPILER_STACK_CHECK_MODE_NORMAL/STRONG/ALL (default NONE), which turns silent corruption into a deterministic abort and reboot. ## Fix Upgrade ESP-IDF to 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 affected. Fixes also in master and release/v6.1. ## Timeline - 2026-11-04T19:28:48+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-113783 - 2026-11-04T19:31:03+00:00 analyst — Read vendor GHSA-ch63-jxm5-vmvf: advisory gives no dates for 5.3.7/5.4.5 ('yet to be released'); 5.2 is EOL with no fix, workaround is keep DNS_MAX_HOST_IP=1 or migrate. Default config (1) is not vulnerable; devices can crash without any attacker since NTP pools return multiple records. No exploitation or PoC seen; X not checked. ## Documents - [advisory] Vendor advisory: github.com https://github.com/espressif/esp-idf/security/advisories/GHSA-ch63-jxm5-vmvf - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/7ab85eb4dc7d7695960d940badcd62592c365056 - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/882843dbf838b0c02e09d46bb6283bda73496b8c - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/75f2ff7e0c2d19e113293ec122b701c83d2f6665 - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/af7543d00a4d7b489e010a70b59fd3d8022a40f4 - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/defaa2f559470acfee5e2e5ea80a79b73424d483 - [fix] Patch: github.com https://github.com/espressif/esp-idf/commit/98e6e7a08fca391563651a1e751cc45a3b27d18b ## From the sources 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. --- _Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_