dnsmasq: DNSSEC Bug Enables Unauthenticated Remote DoS

A vulnerability in dnsmasq's NSEC/NSEC3 DNSSEC record parsing allows remote denial-of-service attacks without authentication. The flaw, tracked as CVE-2026-4890, was publicly disclosed on August 13, 2026.

A vulnerability in dnsmasq's processing of NSEC and NSEC3 DNSSEC records enables remote denial-of-service attacks without authentication. The defect, tracked as CVE-2026-4890, was publicly disclosed on August 13, 2026, via advisory ZDI-26-584 following a coordinated disclosure initiated on May 20. The mechanism is an infinite loop in the record-type bitmap parsing: a loop lacking an exit condition consumes CPU until the DNS service stalls.

Key Takeaways

CVE-2026-4890: DoS vulnerability in dnsmasq tied to DNSSEC processing of NSEC/NSEC3 records
Remote, unauthenticated attack: anyone able to send DNS packets to the target can trigger the infinite loop
Root cause is a missing proper exit condition in the NSEC record handling loop, per the ZDI advisory
Coordinated disclosure: vendor report on May 20, 2026; public release on August 13, 2026

The Mechanism: An Infinite Loop in DNS Security

The core of the problem lies in how dnsmasq handles NSEC and NSEC3 records—the DNSSEC mechanisms for proving the non-existence of a record. These records contain a bitmap listing the record types present for a domain name. According to advisory ZDI-26-584, "the specific flaw exists within the handling of NSEC records. The issue results from a lack of a proper exit condition in a loop."

When dnsmasq encounters a malicious DNS response with a crafted NSEC or NSEC3 structure, the bitmap parsing loop never terminates. The CPU is saturated in an operation that produces no useful output: the dnsmasq process becomes unresponsive and subsequent DNS requests time out. This is not an immediate crash with a segmentation fault, but a more insidious resource starvation equally effective at denying service.

The remote nature of the attack amplifies its severity. The ZDI advisory explicitly states that "authentication is not required to exploit this vulnerability." In configurations where dnsmasq is exposed to answer DNS queries from networks not fully controlled—a common scenario in edge networks, cloud infrastructure, and containerized deployments—the attack vector is open without compromised credentials or an internal network position.

"This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of dnsmasq. Authentication is not required to exploit this vulnerability." — Advisory ZDI-26-584

Why dnsmasq Is a Sensitive Target

dnsmasq is a lightweight DNS forwarder and DHCP server present by default in countless Linux distributions, embedded systems, home routers, and virtualization platforms. Its adoption in OpenStack Neutron, Kubernetes clusters for internal DNS, and container runtimes as part of local name resolution makes it an infrastructural component rather than a discrete application.

When DNSSEC is enabled—a prerequisite for this vulnerability's exploitability—dnsmasq sits in the validation path of the DNS chain of trust. The security function becomes the entry point for instability. This pattern has appeared before in other DNSSEC implementations, but the specificity of this flaw is its mechanical simplicity: it requires no cryptographic complexity, only a response with the appropriate NSEC/NSEC3 structure.

The ZDI advisory does not specify which dnsmasq versions are affected. The dossier documents neither the existence of an official patch nor the version number that introduces one. This gap complicates risk assessment for operators managing heterogeneous or embedded deployments with long update cycles.

The ZDI Disclosure Context

Trend Micro's Zero Day Initiative managed the disclosure on the program's standard timeline: vendor report on May 20, 2026, coordinated public release on August 13, 2026. The roughly three-month interval between report and publication aligns with typical coordination windows, though the dossier does not specify whether a patch was produced during this period or if the vendor released updates.

The identifier CVE-2026-4890 has been assigned, and the CVE record corroborates the vulnerability's nature as a "Denial of Service (DoS) vulnerability in the DNSSEC validation of dnsmasq." However, the CVE record adds no technical detail beyond the ZDI advisory, which remains the primary structured source for understanding the mechanism.

The CVSS 7.5 HIGH reported in the dossier's official facts section—with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H—is not attributed to a specific primary source in the ZDI advisory, which reports neither score nor vector. The dossier does not clarify whether this value derives from a subsequent NVD analysis or another source. The number should be read with this provenance uncertainty.

Why It Matters

The dossier documents no specific mitigations or operational recommendations from the vendor. The source does not specify the nature of data potentially exposed during an attack: impact is limited to denial-of-service, with no evidence of information leakage or alteration of DNS responses.

The brief does not indicate the presence of a public exploit or active in-the-wild exploitation. The absence of this information does not equate to absence of risk: the simplicity of the vector—a specially crafted DNS response—suggests the technical barrier to exploitation is low, though the dossier neither confirms nor denies observed exploitation activity.

For infrastructure operators, the critical point is visibility into which dnsmasq instances have DNSSEC enabled. The brief provides no indicators of compromise or specific detection tools for this vulnerability. Assessing one's own attack surface remains, for now, an internal inventory exercise.

Questions That Remain Open

Which dnsmasq versions are actually at risk?

Advisory ZDI-26-584 does not list specific affected versions. Without this information, every deployment with DNSSEC enabled must be considered potentially exposed until verified with the vendor or the relevant distribution maintainer.

Is a patch available?

The dossier does not document the status of an official patch. The vendor URL referenced in the ZDI advisory points to the advisory itself, not to a security bulletin or release notes with fixes.

Is DNSSEC enabled by default in common distributions?

The brief does not specify which distributions or deployments enable DNSSEC by default on dnsmasq. Configuration variability across home routers, cloud providers, and embedded systems makes this necessary information unavailable in the dossier.

The tension between security and availability manifests here in paradoxical form: the mechanism designed to guarantee DNS response authenticity, DNSSEC, hosts a bug that turns that very guarantee into a service disruption vector. This is not the first time a trust function has introduced operational fragility, but the combination of remote exploitability and no required authentication elevates the priority for vendor clarity on affected versions and the remediation path.

Information is based on the cited advisory and current as of publication.

Sources

Information is based on the cited source and current as of publication.

Sources

Sources and references