Preface: Zephyr (backed by the Linux Foundation) frequently trades places with FreeRTOS as the most widely adopted open-source RTOS in embedded industry surveys.
Background: While Zephyr introduced a completely revamped, native IP stack in version v1.7.0 (migrating away from its original heavily modified uIP foundation), it initially lacked standardized support for string-to-numeric IP address translation within its native tools and DNS resolver interfaces. Applications handling raw string literals had to rely on manual, custom string splitting or external parsing logic.
In traditional networking, parsing an IP address string requires guessing the IP version first or making separate, verbose calls to POSIX functions like inet_pton(). Zephyr’s native utility is specifically optimized for resource-constrained IoT environments where code space and RAM are heavily restricted.
The net_ipaddr_parse() utility was introduced to simplify and unify string-to-binary conversion for dual-stack (IPv4 and IPv6) address processing into a single, light footprint function. The parser was first introduced (v1.9.0), confirming it does not exist in older codebases.
Ref: This specific utility (net_ipaddr_parse()) became widely documented due to a security flaw identified in CVE-2026-10666. Security audits explicitly track this stack-based buffer overflow vulnerability back to the very commit where the parser was first introduced (v1.9.0), confirming it does not exist in older codebases.
Vulnerability details: CVE-2026-10666 was introduced when an address parser was added way back in Zephyr version 1.9.0, and it has quietly shipped in all subsequent releases up through version 4.4.0.
An attacker triggers this weakness during the network address resolution phase. If an application attempts to resolve a network-influenced address string—such as through a custom DNS configuration or the zsock_getaddrinfo API—the attacker can supply a specially crafted address containing an oversized port suffix. For example, feeding a literal IP followed by hundreds of bytes of an attacker-controlled payload.”
The root cause lies in how copy_len is derived. The function calculates the length using the logic str_len - end - 1. Because the total incoming string length is completely unbounded, an attacker can manipulate this math to force an arbitrarily large copy_len.
When the program executes memcpy to copy the port string into the fixed 17-byte ipaddr stack buffer, it triggers an out-of-bounds stack write. This immediately results in memory corruption, a total Denial of Service, or potentially control-flow hijacking.”
Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-10666