CVE-2026-12969: 
dnsmasq vulnerability analysis and mitigation

CVE-2026-12969 is an out-of-bounds read vulnerability in dnsmasq's find_soa() function located in src/rfc1035.c. When parsing NS section records in NXDOMAIN/NODATA responses, extract_name() is called with extrabytes=0, failing to validate that 10 additional bytes exist for fixed-length DNS record fields (type, class, TTL, rdlen), allowing a remote attacker controlling a DNS zone to trigger a 10-byte heap out-of-bounds read via a crafted NXDOMAIN response. All dnsmasq versions prior to 2.93 are affected, as well as Red Hat Enterprise Linux 10.0. The vulnerability was published on June 23, 2026, with a patch available in dnsmasq 2.93rc1. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an out-of-bounds read (CWE-125) in the find_soa() function in src/rfc1035.c. When processing NS section records during NXDOMAIN/NODATA response parsing, extract_name() is invoked with extrabytes=0, which only validates that the DNS name fits within the packet but does not verify that an additional 10 bytes exist for the fixed-length record fields. The subsequent GETSHORT/GETLONG macros then unconditionally read 10 bytes past the valid packet boundary. An attacker controlling a DNS zone can craft an NXDOMAIN response where the NS record name (using a compression pointer) extends to the packet boundary, triggering the over-read; the 10-byte over-read typically stays within dnsmasq's over-allocated packet buffer (headroom of ~1035 bytes), limiting crash risk but potentially exposing stale heap data from prior DNS transactions. The upstream fix is available at commit 14094e88beca519c53151184cc4553656672b54f in the dnsmasq mirror repository (Red Hat Bugzilla, GitHub Advisory).

Successful exploitation results in a limited confidentiality impact: an unauthenticated remote attacker can cause dnsmasq to read up to 10 bytes of stale heap memory from prior DNS transactions, potentially disclosing sensitive data such as fragments of previous DNS query/response content. There is no integrity or availability impact, and the over-read is unlikely to cause a crash due to dnsmasq's over-allocated packet buffer. The vulnerability does not enable code execution or lateral movement on its own, but memory disclosure could theoretically assist in further attacks (GitHub Advisory, Red Hat Bugzilla).

There is no known public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is automatable (no user interaction or privileges required), as an attacker only needs to control a DNS zone that dnsmasq queries. The EPSS score is approximately 0.25% (16th percentile), indicating a low near-term exploitation probability. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported (GitHub Advisory).

1. Control a DNS zone: The attacker must operate or compromise an authoritative DNS server for a zone that the target dnsmasq instance will query (e.g., by registering a domain or performing DNS hijacking).
2. Craft a malicious NXDOMAIN response: Construct a DNS NXDOMAIN response that includes an NS record in the authority section where the NS record name is encoded as a compression pointer that extends exactly to the packet boundary, leaving no room for the 10-byte fixed-length fields (type, class, TTL, rdlen).
3. Deliver the response: Route the crafted NXDOMAIN response to the target dnsmasq instance when it queries the attacker-controlled zone. This can occur naturally when a client behind dnsmasq resolves a non-existent name in the attacker's zone.
4. Trigger the out-of-bounds read: dnsmasq's find_soa() calls extract_name() with extrabytes=0, passes boundary validation, and then GETSHORT/GETLONG macros read 10 bytes beyond the packet boundary into heap memory.
5. Obtain disclosed data: The 10 bytes read from heap memory may contain stale data from prior DNS transactions processed by dnsmasq, which could be captured or inferred through observable DNS behavior (Red Hat Bugzilla).

• Network: Unusual NXDOMAIN responses from authoritative DNS servers containing NS records with compression pointers at the packet boundary; unexpected DNS queries from dnsmasq to newly registered or suspicious domains.
• Logs: dnsmasq logs showing repeated NXDOMAIN responses for queries to the same zone from an unexpected authoritative server; anomalous DNS response sizes or malformed packet warnings in system logs.
• Process: Unexpected memory access patterns or heap anomalies in dnsmasq process (detectable via memory safety tools such as AddressSanitizer in debug builds).

Update dnsmasq to version 2.93 or later, which includes the upstream fix (commit 14094e88beca519c53151184cc4553656672b54f) that adds proper extrabytes validation in find_soa() (Red Hat Bugzilla, GitHub Advisory). As a workaround, restrict which DNS zones dnsmasq is configured to accept responses from, limiting exposure to untrusted DNS authorities. Red Hat Enterprise Linux 10.0 users should monitor Red Hat's security advisories for updated dnsmasq packages (Red Hat CVE).