Zephyr DNS resolver reuses one source port, easing spoofing
Key facts
- Attack vector
- Network
- Privileges required
- None
- User interaction
- None
- Attack complexity
- High
- Impact type
- —
- Confidentiality · integrity · availability
- Low · High · None
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA.
Summary
Zephyr from 1.8.0 before 4.5.0 uses one constant UDP source port for all DNS stub resolver queries, so an attacker only has to guess the 16-bit transaction identifier. The weakness is classified as CWE-330, Use of Insufficiently Random Values. An unauthenticated remote attacker with UDP reachability to the device can flood forged answers during a query window and win the race against the legitimate server, causing the application to resolve an attacker-chosen address. With the resolver cache enabled, the forged record is kept for its attacker-chosen TTL.
Written with Claude Haiku 5.5 from the sources below · 2026-11-02
Description from the CNA
The DNS stub resolver in subsys/net/lib/dns/resolve.c binds one UDP socket per configured server when the resolver context is initialised (dns_resolve_init_locked() -> register_dispatcher() -> dns_dispatcher_register()), with the local port left at 0 so the stack picks an ephemeral port exactly once. dns_write() then sends every subsequent query from that same socket without re-binding, so the source port is constant for the lifetime of the resolver context while only the 16-bit transaction identifier (ctx->queries[i].id, drawn with sys_rand16_get()) varies per query. RFC 5452 section 9.2 requires both to vary; with a fixed port, an off-path attacker has to guess only the identifier. The stable port is cheap to learn. Any single observed query reveals it permanently, and it can also be found by probing the ephemeral UDP range: subsys/net/ip/connection.c answers unmatched unicast UDP with an ICMP port-unreachable, so the resolver's socket is the one port in that range that stays silent. Acceptance of a reply is decided solely by get_slot_by_id() matching the transaction identifier and a CRC-16 of the queried name — the reply's source address is never checked (dispatcher_cb() does ARG_UNUSED(addr)), so forged answers need not even be spoofed to appear to come from the configured server; they only need to reach the resolver's port. An attacker with UDP reachability to the device (same LAN, Wi-Fi or mesh segment, or a globally routable device address) can therefore flood answers for a predictable query name across the 16-bit identifier space during a query window and race the legitimate server. A win makes the application resolve an attacker-chosen address, and with CONFIG_DNS_RESOLVER_CACHE enabled the forged record is retained for its attacker-chosen TTL. The attack still requires winning that race, and applications that validate TLS certificates for the resolved endpoint are largely protected. The fix draws a fresh local port before each query to a server that has nothing outstanding: dns_randomize_source_port() unregisters the dispatcher, closes and reopens the socket, and re-registers it bound to port 0 so the system selects a new port, raising the per-query guessing space from roughly 16 to roughly 31 bits. Multicast DNS and LLMNR are excluded because their ports are protocol-fixed. The behaviour is controlled by CONFIG_DNS_RESOLVER_RANDOMIZE_SOURCE_PORT (default y).
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| zephyrproject | zephyr | 1.8.0 to before 4.5.0 | 4.5.0 | Patch available | CNA |
- zephyr Vendorzephyrproject Affected 1.8.0 to before 4.5.0 Fixed in 4.5.0 Patch available CNA
CPE names Threatist (inferred) · 1
Inferred from how NVD named this product before; not given by a source.
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:* | — | — | zephyrproject |
- cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:* Versions — — ·zephyrproject
Remediation
Upgrade Zephyr to 4.5.0, which draws a new source port before each query through CONFIG_DNS_RESOLVER_RANDOMIZE_SOURCE_PORT, enabled by default.
Written with Claude Haiku 5.5 from the sources below · 2026-11-02
- Fix · CNA zephyr (zephyrproject) Fixed in 4.5.0
Fixed in the same release
Records fixed by the same vendor advisory or release, as the CNA lists them.
- Release ·
zephyrproject zephyr 4.5.0
4 records Highest priority Priority MEDIUM 1 MEDIUM, 3 LOW
Other records, highest priority first
- TI-2026-79949 WireGuard endpoint hijack via unauthenticated packets in ZephyrPriority MEDIUM 41
- TI-2026-79951 Stale Zephyr arm64 TLB entries expose reused physical framesPriority LOW 35
- TI-2026-79952 Predictable DHCPv4 transaction ID in Zephyr allows spoofed repliesPriority LOW 24
Timeline
- 2026-10-23 Threatist record created from CVE-2026-79981
- 2026-10-24 Priority changed: MEDIUM → LOW
- 2026-11-02 CISA SSVC decision points changed
References
Patch 1
Other 1
More zephyrproject vulnerabilities
- TI-2026-04422 Out-of-bounds read/write in HTTP WebSocket upgrade via non-null-terminated Sec-WebSocket-Key CVSS 3.1CRITICAL 9.8
- TI-2026-01361 dns: memory‑safety issue in the DNS name parser CVSS 3.1CRITICAL 9.8
- TI-2026-09174 Unterminated URI buffer causes out-of-bounds read in LwM2M firmware pull (Package URI) CVSS 3.1CRITICAL 9.1
- TI-2026-09168 Stack buffer overflow in `net_ipaddr_parse()` IPv4 address-with-port parsing in `subsys/net/ip/utils.c` CVSS 3.1CRITICAL 9.8
- TI-2024-09625 net: lib: http_server: Buffer Under-read CVSS 3.1HIGH 8.6
- TI-2021-02863 Usb bluetooth device ACL read cb buffer overflow CVSS 3.1CRITICAL 9.6
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences