CVE-2026-12969: dnsmasq Heap Out-of-Bounds Read via Crafted NXDOMAIN Response

Technical summary

CVE-2026-12969 is a heap out-of-bounds read in dnsmasq's find_soa() function (src/rfc1035.c). The root cause is improper validation during DNS packet parsing: the extract_name() function is invoked with extrabytes=0 when processing NS section records in NXDOMAIN responses, omitting the 10-byte buffer space required for fixed-length DNS record fields that follow the name. A remote attacker who controls a DNS zone can craft an NXDOMAIN response that triggers this condition, causing dnsmasq to read 10 bytes from heap memory beyond the legitimate packet boundary. The leaked data is not under attacker control but reflects whatever was previously allocated in that heap region. The CWE classification is CWE-125 (Out-of-bounds Read).

Business impact

Information disclosure is the primary concern. If dnsmasq is exposed to untrusted DNS sources or if an attacker can poison zone delegations, stale heap contents may leak. In environments where dnsmasq forwards queries or serves as a resolver for sensitive workloads, this could expose fragments of prior queries or responses. The attack requires DNS zone control, limiting the threat surface; opportunistic exploitation via public DNS services is less practical. However, in split-view DNS or internal zone scenarios where an attacker has zone authority, repeated exploitation could yield meaningful data. Service availability is not directly compromised—dnsmasq does not crash from this read violation.

Affected systems

dnsmasq versions affected by this vulnerability are those prior to the patched release. Red Hat Enterprise Linux distributions that bundle vulnerable dnsmasq versions are at risk, as are standalone dnsmasq deployments. The vulnerability applies specifically to code processing DNS responses with NXDOMAIN status and NS section records. Verify your exact dnsmasq version against the vendor advisory to confirm exposure.

Exploitability

Exploitation is straightforward from a network standpoint: an attacker must control a DNS zone (or intercept/poison DNS responses) and send a malformed NXDOMAIN packet. No authentication, credentials, or user interaction is required. The attack surface is broad if dnsmasq is exposed to untrusted recursive queries or downstream from insecure DNS paths. However, the utility of exploitation depends on whether leaked heap data contains sensitive information—heap spraying or heap feng shui techniques might improve information recovery, though such tactics are not disclosed in public analysis. CVSS 3.1 assigns a score of 5.3 (MEDIUM severity), reflecting low confidentiality impact and no integrity or availability impact. The vulnerability is not currently tracked in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Apply vendor patches immediately. For Red Hat Enterprise Linux, consult Red Hat Security Advisories for your specific release. For upstream dnsmasq, update to a patched version—verify the exact version number in the official dnsmasq release notes or GitHub repository. There is no known workaround; patching is the only mitigation. If immediate patching is infeasible, restrict DNS query sources and monitor for suspicious zone delegation patterns.

Patch guidance

1. Identify your dnsmasq version: check rpm -qa dnsmasq (RHEL) or dnsmasq --version (standalone). 2. Cross-reference against Red Hat Bugzilla or the dnsmasq GitHub repository to confirm the patched version for your release stream. 3. Test the patch in a non-production environment first, particularly if dnsmasq handles DHCP or serves critical split-view zones. 4. Redeploy and verify DNS resolution continues normally post-patch. 5. Confirm via version check that the patched code is running.

Detection guidance

Intrusion detection is limited because the exploit produces no obvious error signatures—dnsmasq silently performs the out-of-bounds read. Monitor for: (1) NXDOMAIN responses with malformed NS sections in your DNS query logs or packet captures, especially from unexpected sources; (2) unusual heap corruption warnings in dnsmasq debug logs if enabled; (3) repeated DNS queries to non-existent subdomains under a domain you do not control, which might indicate exploit probing. Network segmentation and DNS query whitelisting reduce exposure. Endpoint Memory Tagging Extension (MTE) or AddressSanitizer in debug builds can catch the violation if available.

Why prioritize this

This vulnerability merits prompt but not emergency patching. The CVSS 5.3 (MEDIUM) score reflects genuine but limited impact: information disclosure without authentication barriers is concerning, but the threat requires DNS zone control and does not affect availability. Prioritize patching for dnsmasq instances serving high-value networks, handling sensitive queries, or facing untrusted DNS sources. Lower priority for internal resolvers in well-segmented networks where DNS sources are tightly controlled. The fact that this is not on CISA's KEV list suggests limited active exploitation in the wild, but do not rely on this alone—vendor advisories and your own threat model should guide timeline.

Risk score, explained

CVSS 3.1 score of 5.3 is assigned under the MEDIUM severity band. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N reflects: Attack Vector Network (exploitable remotely), Attack Complexity Low (no special conditions beyond DNS zone control), Privileges Required None (unauthenticated), User Interaction None, Scope Unchanged, Confidentiality Low (heap data leakage), Integrity None (no modification), Availability None (no denial of service). The score reasonably balances the ease of exploitation with the limited impact; organizational risk depends on your DNS topology and data sensitivity.

Frequently asked questions