CVE-2026-93010 in dnsmasq
Summary
by MITRE • 10/29/2026
A flaw was found in dnsmasq. When DHCP leasequery is enabled without listing allowed source addresses, the server does not check who sent the query. A host on the local network can request DHCP lease records and learn assigned addresses, MAC addresses, hostnames, and related lease metadata. The feature is off unless an administrator turns it on.
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 stems from a critical access control deficiency within its Dynamic Host Configuration Protocol (DHCP) lease query functionality. When the DHCP server is configured to allow lease queries but fails to explicitly define a list of permitted source IP addresses, the service operates with an overly permissive security posture. In this misconfigured state, dnsmasq does not perform any authentication or authorization checks on incoming requests targeting the lease database. This oversight allows any device connected to the local network segment that has reachability to the DNS and DHCP server to interact directly with sensitive internal infrastructure data without requiring valid credentials or prior approval from a system administrator.
From a technical perspective, this flaw represents an insecure direct object reference combined with broken access control mechanisms. The software fails to validate whether the origin of the request is authorized before processing it and returning results. This behavior aligns closely with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Default Credentials or Settings, as the default configuration often leaves this feature disabled for security reasons, but when enabled without proper restriction parameters, it exposes internal network topology information to any local actor. The absence of source address filtering effectively turns a management interface into an open data dump accessible via standard UDP packets on port 67 or 53 depending on implementation specifics.
The operational impact of this vulnerability is significant for organizations relying on dnsmasq for DHCP services within their internal networks. An attacker with local network access can exploit this flaw to enumerate active devices, retrieve assigned IP addresses, capture MAC addresses associated with specific hosts, and identify hostnames used by various systems. This information provides a detailed map of the network environment, facilitating further reconnaissance activities such as targeted phishing attacks against identified users or services, lateral movement planning based on known device types and roles, and potential denial-of-service campaigns aimed at critical infrastructure components once their locations are confirmed. The exposure of MAC addresses also aids in tracking user devices across different time periods if logging is enabled elsewhere.
This vulnerability maps directly to the MITRE ATT&CK framework under the Discovery tactic, specifically relating to techniques like Network Service Scanning and System Information Discovery. By leveraging this flaw, an adversary can efficiently gather intelligence about the network architecture without triggering typical intrusion detection alerts associated with brute-force attacks or unauthorized login attempts. The simplicity of the exploit means that even low-skilled attackers can achieve substantial situational awareness regarding internal assets, which is often a precursor to more destructive phases like exploitation and exfiltration.
Mitigation strategies must focus on strict configuration management rather than relying solely on network segmentation. Administrators should ensure that if DHCP lease query functionality is required for legitimate operational purposes such as dynamic DNS updates or client identification services, it is explicitly restricted to known trusted source IP addresses using the appropriate dnsmasq configuration directives. This involves defining an allowlist of specific IPs or subnets authorized to perform queries, thereby enforcing principle of least privilege at the application level. Additionally, regular audits of service configurations should be conducted to verify that features are disabled unless absolutely necessary and always hardened with restrictive access controls when enabled. Network-level firewalls can provide a secondary layer of defense by blocking unauthorized UDP traffic destined for DHCP query ports from untrusted zones, ensuring that even if misconfiguration occurs, external or lateral movement paths remain restricted until the underlying software issue is resolved through updates or patches provided by upstream maintainers.