CVE-2026-10666 is a stack based buffer overflow (CWE-121) in the IPv4 address parser of the Zephyr RTOS network stack, scored 8.1 high. A long string after the colon in an address with a port can overflow a small stack buffer. The upstream fix is in linked commits, so check the advisory and update.
What's affected
Zephyr RTOS releases through v4.4.0, per the CVE record. The record says the flaw arrived when the parser was added, which it places at v1.9.0. The GitHub advisory lists the affected range as above 1.10.0, so the exact starting point differs between sources. In practice, treat every release you build from as affected until you have the fix.
The advisory shows patched versions as none at the time of review, and the record says the fix "removes the unbounded copy and validates the port length before copying into a small dedicated buffer." The fix is in two upstream commits that the record links. Check the Zephyr advisory for a tagged release that includes them before you finalize your plan.
The flaw is in parse_ipv4() in subsys/net/ip/utils.c. It is reached through net_ipaddr_parse() for strings shaped like an address followed by a port. The record names three paths that feed it: the socket API when resolving literal addresses, DNS server string configuration, and the Wi-Fi co-processor DNS response path in the eswifi driver.
The record also notes that the equivalent IPv6 path, parse_ipv6(), keeps the same unbounded copy at the fix commit and remains a separate, still reachable instance of the defect. Do not assume the IPv4 fix covers IPv6 input.
How to check if you're exposed
Zephyr is a source tree, so there is no single package to scan. Start from your build.
Check which Zephyr revision your firmware builds from. In a west workspace, run this inside the zephyr directory:
git describe --tags
Then find where your own code passes strings to the parser or to address resolution:
grep -rn "net_ipaddr_parse\|zsock_getaddrinfo" src/ ../modules/
For each hit, ask whether the string can be influenced by something outside the device, such as a server response, a configuration message or user input over the network. Only those call sites are exposed in practice. If the Wi-Fi co-processor DNS path is in your build, include it in the review.
You can also run the free in-browser dependency scan or browse the Gold directory to see where a package or product shows up in your stack.
What to do now
- Identify every product build that includes Zephyr up to v4.4.0 and the network stack with IPv4 enabled.
- Read the Zephyr advisory and pull the upstream fix commits into your tree, or move to a tagged release that includes them once one is named.
- Add a length check in your own code before calling
net_ipaddr_parse()on any network influenced string, as a stopgap. - Review IPv6 call sites separately, since the record says that path still has the same copy at the fix commit.
- Plan an over the air update for devices in the field, and decide which fleets are reachable by untrusted networks first.
- Rebuild with stack protection and address sanitizer in test builds to catch similar copies elsewhere.
Why it matters
The cause is a copy whose length comes from the full input string while the destination is a fixed 17 byte buffer. The code checked a small offset but never compared the copy size with the buffer size. This is CWE-121, a stack buffer overflow, and the record says both the length and the contents of the overflow are controlled by whoever supplies the string.
The record states the effect plainly: memory corruption and at minimum denial of service, with a possible path to hijacking control flow. On a microcontroller with limited memory protection, a stack overflow often has fewer barriers than on a desktop operating system, which is why embedded teams should treat it as serious.
The record does not flag this CVE as exploited in the wild, and it is not marked as a CISA Known Exploited Vulnerability. It does note a long lifetime in the code, and bugs that old tend to show up in many forks and vendor trees. Look at vendor SDKs that embed Zephyr, not just your own tree.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is my device exposed if it never parses addresses with ports?
The record ties the flaw to strings of the form address and port. If no code path passes such strings to the parser and no network input reaches it, exposure is much lower. Confirm by reading your call sites.
Does fixing IPv4 fix IPv6?
No. The record says the IPv6 bracket form keeps the same unbounded copy at the fix commit and is a separate instance. Check the advisory for its status.
Sources
Last reviewed: 19 October 2026.
