Dnsmasq vulnerabilities in embedded firmware: identify, prioritise and fix

Because on most Linux-based routers, gateways and access points, dnsmasq is the DNS forwarder and the DHCP server at once, and it listens on every LAN client's path. The CERT/CC vulnerability note on DNSpooq describes it as "widely used open-source software that provides DNS forwarding and caching (and also a DHCP server)" and notes that it is "common in Internet-of-Things (IoT) and other embedded devices." OpenWrt packages it in three build variants, and vendor SDKs derived from OpenWrt inherit it.

That position makes a dnsmasq flaw a network-level problem. A memory corruption bug in its DNS parser can be triggered by a crafted answer from upstream, or by a query from a LAN client. A cache-poisoning weakness lets an attacker redirect every client that uses the device as its resolver. And because dnsmasq's lease-script helper keeps root privileges, as the CVE-2026-4892 patch notes, a flaw in the DHCP or script-helper code can lead straight to root on the device.

Three groups cover most of what a firmware scan will report. The version in the right-hand column comes from the dnsmasq CHANGELOG, which names the CVE next to each fix.

"NVD" marks NVD's own Primary score (CVSS 3.1 unless marked v3.0); "secondary" means the scores NVD lists from third parties. For the 2026 CVEs, the NVD record status on 2026-11-11 was "Awaiting Analysis", with no NVD Primary score published.

DNSpooq (2021). Seven CVEs found by JSOF and published on 2021-01-19, according to CERT/CC. Four are heap overflows in the DNSSEC code; the 2.83 changelog says "any dnsmasq with DNSSEC compiled in and enabled is vulnerable to this." The other three weaken how dnsmasq matches replies to queries: it did not tie a reply to the exact address and port of the forwarded query (CVE-2020-25684), it used "the very insecure CRC32" to check replies when built without DNSSEC (CVE-2020-25685), and it forwarded repeated identical queries separately, which multiplies an off-path attacker's chances (CVE-2020-25686). Together these make DNS cache poisoning practical.

The 2017 Google set. Google's security team reported six bugs fixed in 2.78. CVE-2017-14491 is the one with the widest reach: the changelog calls it "a potentially serious security hole" that "allows an attacker who can make DNS requests to dnsmasq, and who controls the contents of a domain" to overflow a heap buffer. Devices still on 2.77 or older carry it.

The 2026 set. On 11 May 2026 the dnsmasq author announced six CVEs for "long-standing bugs which apply to pretty much all non-ancient versions," released 2.92rel2 with the fixes applied, and published per-CVE patches. The same message describes a sharp rise in AI-assisted bug reports to the project, so more dnsmasq fixes are likely to follow. The patch for CVE-2026-4892 explains why that one is serious on routers: a DHCPv6 client ID of up to 65,535 bytes is hex-encoded into a 5,131-byte buffer, and "the helper process retains root privileges."

They show that the same upstream CVE list produces very different results per product, depending on how dnsmasq was built and configured. Cisco's DNSpooq advisory states that, at publication, "no Cisco products were found to be affected" by the four DNSSEC memory-corruption CVEs, while multiple products were affected by the cache-poisoning ones. In the CERT/CC note, Cradlepoint's statement rates its NetCloud OS devices "Low/Medium" in the default configuration with DNSSEC disabled, "Medium/High" with DNSSEC enabled, and "Critical" when DNS is exposed on WAN interfaces. Same software, three ratings.

Your own advisory should make the same distinctions. If your build has no DNSSEC, say so and mark the DNSSEC CVEs "not affected" with that justification in a VEX statement. Our CSAF and VEX for device makers guide shows the format.

Rank by reachability first, then by exploitation data, and use the CVSS base score only to break ties. Exploitation data as of 2026-11-10 (CISA KEV catalog version 2026.11.10, FIRST EPSS scores dated 2026-11-10):

Two points stand out. First, EPSS does not know your configuration: the DNSpooq DNSSEC overflows score above 0.75 even though they cannot run in a build without DNSSEC. Second, none of these CVEs was in CISA's KEV catalog in its 2026.11.10 release. A KEV listing would move a CVE to the top regardless of everything else. Our KEV and EPSS prioritisation guide covers how the two signals combine, and CVSS v4 vs v3.1 covers why base scores need environmental context.

Exposure matters as much as the feature list. A dnsmasq that answers DNS on the WAN interface turns local-network bugs into internet-reachable ones, which is exactly the difference between Cradlepoint's "Medium/High" and "Critical" ratings above.

Upgrade or patch, switch off what the product does not use, restrict where dnsmasq listens, then rebuild and re-scan to prove the result.

Upgrade or patch. dnsmasq 2.93, released on 2026-06-04 according to the project's download directory, contains the fixes for all the CVEs above. If a jump from an old base is too large for this release cycle, 2.92rel2 is 2.92 with the six 2026 fixes, and the CVE patch directory holds one diff per CVE. Its note explains that CVE-2026-4890 covers two problems, so there is one patch for 2.92 and another for 2.91 and earlier. A device on a base older than 2.83 also needs the DNSpooq and 2017 fixes, and at that point moving to 2.93 is usually less work than a long backport stack.

Disable unused services. Each of these removes whole CVE groups from reach:

Dropping DNSSEC validation is a trade-off, since validation also defends against spoofed answers. Where it stays on, the fix is to patch, not to disable it.

Restrict exposure. Bind dnsmasq to LAN interfaces with --interface, and use --local-service, which the man page says accepts "DNS queries only from hosts whose address is on a local subnet." Make sure the firewall does not open UDP and TCP port 53 on WAN. CERT/CC also recommends stateful filtering that drops unsolicited DNS responses, and disabling caching on embedded devices when an upstream caching resolver is available. --no-ident stops the version.bind answer that reveals the version to anyone who asks.

Rebuild, re-scan, release. Regenerate the firmware SBOM, compare it with the previous release, and confirm that the new version or patch level is what actually shipped. Our firmware diffing and patch analysis guide covers the binary-level comparison. Then publish the fix with affected versions, fixed version and the CVE list. If the same device also ships BusyBox, Dropbear or U-Boot, the same method applies; see our guides on BusyBox vulnerabilities, Dropbear SSH vulnerabilities and U-Boot bootloader security.

SoftWSP's automated scan unpacks a firmware image, catalogs the software components in the extracted file system, and identifies dnsmasq by name and version. On OpenWrt-style images this includes the opkg package record, with the package revision stripped so the upstream version can be matched. It then matches that version against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which dnsmasq CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: whether DNSSEC, DHCPv6 and TFTP are compiled in and switched on, whether DNS is reachable from WAN, and whether a vendor backport already closes a version-matched CVE. Version matching flags a patched Debian-style 2.90-4~deb12u2 build as affected; the review step is where backport and configuration evidence become a documented "not affected" decision.

For where dnsmasq review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the dnsmasq CHANGELOG, CVE patch directory, man page and dnsmasq-discuss announcement, CERT/CC VU#434904, Cisco's DNSpooq advisory, Debian DSA-6264-1 and the Debian Security Tracker, OpenWrt's dnsmasq package Makefile, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-10, all read directly on 2026-11-11.