CVE-2026-10652: Zephyr DNS Resolver Out-of-Bounds Read (MEDIUM)

Technical summary

CVE-2026-10652 is an out-of-bounds read vulnerability in subsys/net/lib/dns. The vulnerability exists in dns_unpack_answer(), which parses DNS resource record (RR) headers but does not validate whether the declared rdlength (resource data length) actually fits within the received datagram. Downstream consumers in dns_validate_record() (resolve.c) then use memcpy to read up to rdlength bytes (clamped only to per-record-type limits like DNS_MAX_TEXT_SIZE ≈ 64 bytes for TXT, not to packet boundaries) into application-facing buffers. A crafted DNS response with an rdlength extending past the end of dns_msg->msg_size causes the parser to read past the packet boundary into the receive buffer pool. The read is bounded by the per-record-type maximum and does not write, so code execution is not possible. However, the out-of-bounds read can expose stale DNS packet data or uninitialized memory to the application callback, and may occasionally cross allocation boundaries, triggering a fault and denial of service. The fix validates rdlength against msg_size at the chokepoint in dns_unpack_answer() before any downstream read occurs.

Business impact

Organizations deploying Zephyr 4.3.0 or 4.4.0 in networked IoT, embedded, or real-time systems risk information disclosure and potential service disruption. If a Zephyr device relies on DNS for core functionality (e.g., mDNS service discovery on a local network, DHCP, or remote configuration), an attacker can leak sensitive data from device memory—such as credentials, cryptographic keys, or application secrets that happened to be in adjacent memory pools—or crash the resolver by crossing allocation boundaries. The impact is heightened in zero-trust or air-gapped deployments where a single compromised device or rogue DHCP server can reach all Zephyr nodes. In supply-chain or industrial IoT scenarios, systematic exploitation could affect firmware update verification or interdevice communication.

Affected systems

The vulnerability affects Zephyr versions 4.3.0 and 4.4.0. Any application or device using the standard DNS resolver subsystem (subsys/net/lib/dns) with TXT or SRV record handling is vulnerable. This includes systems with standard DNS, multicast DNS (mDNS), or LLMNR enabled. Devices not explicitly using DNS or with custom DNS implementations may be unaffected; however, most networked Zephyr deployments include DNS support. Verify your Zephyr version and confirm whether your firmware includes the dns subsystem and processes TXT or SRV records.

Exploitability

Exploitability is moderate. An attacker must be able to send or intercept DNS responses to the target device. In a typical scenario, an on-path attacker (compromised router, rogue DHCP server, or network eavesdropper) can forge UDP DNS replies. If mDNS or LLMNR is enabled, any device on the same LAN can craft and transmit a malicious response without prior network compromise. Triggering the leak requires crafting a DNS response packet with a valid header but an rdlength value that exceeds the actual packet size, which is straightforward. No user interaction or special device configuration is required. The vulnerability is deterministic—each malformed response triggers a read—making it reliable to exploit. However, the leaked data is small (~64 bytes) and not directly attacker-controlled; the attacker cannot read arbitrary memory, only what exists in the adjacent pool or allocation. A crash (denial of service) is possible but not guaranteed, since it depends on buffer pool layout.

Remediation

Update Zephyr to a patched version beyond 4.4.0. Verify the patch in the vendor's official release notes or Git repository, ensuring that dns_unpack_answer() now validates rdlength against the received datagram size before allowing downstream consumers to read. If an immediate update is not feasible, mitigate by disabling DNS or mDNS/LLMNR if your application does not require them, or by restricting network access to trusted DNS servers (e.g., via firewall rules, network segmentation, or DNSSEC validation where available). However, these are temporary workarounds; patching is the authoritative fix.

Patch guidance

Apply the latest Zephyr release that addresses CVE-2026-10652. Refer to the official Zephyr Project security advisory and release notes (typically available on zephyrproject.org or the Zephyr GitHub repository) to confirm the patched version number and any required configuration changes. Test patches in a staging environment before production rollout, especially if your firmware includes custom DNS extensions or depends on specific DNS behavior. Note that this vulnerability does not require a recompile of applications; updating the Zephyr OS/SDK is sufficient.

Detection guidance

Detection is challenging without protocol-level inspection. Network-based detection could monitor for DNS responses with rdlength fields significantly larger than the rest of the packet, or responses that are truncated abnormally; however, this generates high false-positive rates. Endpoint-level detection: enable Zephyr debug logging for the DNS subsystem (CONFIG_DNS_LOG_LEVEL_DBG or similar) and monitor for unexpected reads from the buffer pool (e.g., via fuzzing or code inspection tools). Application-level detection: if the resolve callback receives unusually large or malformed TXT/SRV data, log and reject it. Post-breach forensics: examine device memory dumps or logs for unexpected data in DNS response handlers or correlated with DNS queries that do not match known responses. No public exploit code or signatures are widely available, so detection will be reactive (based on observed crashes or memory leaks) rather than proactive.

Why prioritize this

This vulnerability merits patching in the near term but is not an emergency. The CVSS 4.8 MEDIUM score reflects the limited scope (read-only, bounded, no code execution), combined with the requirement for network attacker positioning. However, prioritize patching if your organization: (1) operates mDNS/LLMNR on Zephyr devices in untrusted networks (e.g., public WiFi, multi-tenant cloud); (2) uses Zephyr for security-sensitive devices (edge gateways, medical devices, industrial controllers) where memory disclosure could expose secrets; (3) has extended support lifecycle requirements and cannot afford downtime. For isolated or air-gapped deployments with strong network segmentation, patch during a normal maintenance window. For Internet-facing or supply-chain-critical devices, prioritize within 30–60 days.

Risk score, explained

CVE-2026-10652 scores CVSS 4.8 (MEDIUM) due to: Network attack vector (AV:N) reflecting the ability to reach devices via DNS; High attack complexity (AC:H) because the attacker must forge or intercept DNS responses, which is harder than unauthenticated network access; No privileges required (PR:N) and no user interaction (UI:N), indicating the attack is autonomous; Unchanged scope (S:U); Low confidentiality impact (C:L) from stale memory disclosure (~64 bytes, not attacker-controlled); No integrity impact (I:N, read-only); Low availability impact (A:L) from occasional crashes (not guaranteed). The score does not account for context-specific amplification (e.g., if the device stores credentials in adjacent memory) or ecosystem factors (prevalence of mDNS in Zephyr deployments), which security teams should assess locally.

Frequently asked questions