Zephyr DNS Resolver EUVD-2026-109144

Requires a Zephyr build using the DNS stub resolver (CONFIG_DNS_RESOLVER) and an attacker with UDP reachability to the device's resolver socket (same LAN/Wi-Fi/mesh segment or a globally routable device address). The attacker must identify the static source port (trivially from any observed query, or by probing for the single ephemeral UDP port that stays silent instead of returning ICMP port-unreachable) and then, during an active query window, correctly match the 16-bit transaction identifier plus the CRC-16 of the queried name while winning the race against the legitimate server's reply. Limiting factors: exploitation needs a query actually in flight for a predictable name, success is probabilistic (race must be won), and applications that validate TLS certificates for the resolved endpoint are largely protected; persistence of the forged record requires CONFIG_DNS_RESOLVER_CACHE to be enabled. Multicast DNS and LLMNR are out of scope because their ports are protocol-fixed. Affected versions are >= 1.8.0 through <= 4.4.2.

This is a CWE-330 insufficient-randomness weakness (static UDP source port in the Zephyr DNS stub resolver) that lowers off-path DNS answer-spoofing cost from ~31 bits to ~16 bits. The input CVSS is 6.5 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N): network-reachable and unauthenticated (PR:N), but AC:H because the attacker must win a race against the legitimate server during a live query window while flooding the 16-bit transaction-identifier space, and I:H reflects that a win makes the application resolve an attacker-chosen address (cache-poisoned for an attacker-chosen TTL when CONFIG_DNS_RESOLVER_CACHE is on). No EPSS score, no SSVC decision vector, and no KEV entry are provided, so there is no public active-exploitation signal; exploitation status is 'no public exploit identified at time of analysis' (the only references are the vendor patch commit and the GHSA advisory, not a PoC). The vuln.today priority is 'this_month', not act_now/emergency, which is consistent with a medium-severity hardening fix rather than an under-attack flaw. Real-world risk is moderate and conditional: it is a genuine defense-in-depth gap on IoT/embedded devices with UDP reachability, but AC:H plus the advisory's own note that TLS-certificate-validating applications are largely protected pulls realistic impact below the raw network-vector reading. Treat as a planned-patch item, not a fire drill, unless a device relies on unauthenticated DNS results for security decisions.

An off-path attacker with UDP reachability to a Zephyr device (same LAN/Wi-Fi/mesh segment, or a globally routable device address) learns the resolver's fixed source port - from any single observed query, or by scanning the ephemeral range for the one UDP port that does not answer with ICMP port-unreachable. During a window in which the device issues a predictable query name, the attacker floods forged answers across the 16-bit transaction-identifier space (the reply's source address is never checked), racing the real server to make the application resolve an attacker-chosen address. No public exploit code is identified; the attack requires winning the race, and endpoints that validate TLS certificates are largely protected.