CVE-2026-93009 in dnsmasq
Summary
by MITRE • 10/29/2026
A flaw was found in dnsmasq. The DHCPv6 client hostname parser can read one byte past the end of a crafted FQDN option because it checks the next label length before confirming the pointer is still inside the option. An attacker on the local network can trigger this with a single DHCPv6 packet. The extra byte is not returned to the client or logged, and no crash has been demonstrated.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in dnsmasq represents a classic out-of-bounds read condition within its Dynamic Host Configuration Protocol version six (DHCPv6) implementation. Specifically, the flaw resides in the hostname parser responsible for processing Fully Qualified Domain Name (FQDN) options received from clients during the DHCPv6 exchange process. The underlying technical defect stems from an incorrect order of operations in boundary checking logic. When parsing a label within the FQDN option, the software attempts to read the length byte of the subsequent label before verifying that the current pointer position remains strictly within the allocated buffer boundaries defined by the option's total length field. This logical inversion means that if a crafted packet contains an FQDN where the final label is immediately followed by data at or beyond the end of the specified option, the parser will attempt to access memory one byte past the valid allocation boundary.
This specific implementation error classifies as CWE-125: Out-of-bounds Read, which involves accessing memory outside the intended buffer without writing to it. In the context of network service vulnerabilities, this is often categorized under CWE-20: Improper Input Validation because the software fails to adequately validate that all input data conforms to expected structural constraints before processing. The vulnerability allows an attacker positioned on the same local network segment to trigger this condition by sending a single, specially crafted DHCPv6 packet containing a malformed FQDN option. Because dnsmasq is widely deployed as both a DNS and DHCP server in home routers, small office environments, and embedded systems, the potential attack surface is significant for any device running this software with DHCPv6 services enabled.
From an operational impact perspective, while the vulnerability allows for memory access beyond buffer limits, it does not currently present a direct risk of remote code execution or denial-of-service through application crash in most scenarios. The extra byte read is not returned to the client nor logged by the server, which mitigates immediate data exfiltration risks associated with information disclosure vulnerabilities like CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. Furthermore, no crashes have been demonstrated, suggesting that the out-of-bounds access does not immediately corrupt critical control flow structures or trigger segmentation faults in typical execution environments. However, the presence of such a flaw indicates poor defensive coding practices and could potentially be chained with other vulnerabilities or exploited under specific memory layout conditions to achieve arbitrary code read operations, aligning with ATT&CK technique T1083: File and Directory Discovery if used for reconnaissance purposes within a compromised network segment.
Mitigation strategies primarily involve applying the vendor-provided patch that corrects the boundary checking logic to ensure pointer validation occurs before any byte access is attempted. Administrators should prioritize updating dnsmasq on all affected devices, particularly those exposed to untrusted local networks or acting as gateways for IoT devices which may be compromised and used to send malicious DHCPv6 packets. In environments where immediate patching is not feasible, network segmentation can reduce exposure by isolating the DNS/DHCP server from potentially hostile subnets. Additionally, enabling strict input validation at the firewall level to drop malformed DHCP options can provide a layer of defense-in-depth against this specific exploitation vector until the underlying software defect is resolved.