dnsmasq vulnerabilities by version: what the NVD counts and what no release fixes

How many CVEs does the NVD list for my dnsmasq version?

Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 12 November 2026 through the NVD API without rejected entries, each hit re-checked against its configuration. The NVD lists dnsmasq as cpe:2.3:a:thekelleys:dnsmasq. The column “Shipped in” names the build system or distribution that ships this version.

The peak at 2.86 comes from seven CVEs the NVD lists for exactly 2.86. From 2.87 on, no version has a CVE with CVSS 9.0 or higher.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:thekelleys:dnsmasq:2.93&noRejected"  \
| jq .totalResults

0

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:thekelleys:dnsmasq:2.90&noRejected"  \
| jq .totalResults

2

Which dnsmasq CVEs have CVSS 9.0 or higher?

Which dnsmasq vulnerabilities does 2.93 not fix either?

On 29 October 2026 Red Hat, as CNA, published six dnsmasq CVEs. On 12 November 2026 the NVD has not mapped them to any version yet, so a version query for 2.93 does not find them. Five are fixed on the development branch, with commits from 16 and 17 October 2026; there is no release with these fixes. CVE-2026-93010 has no fix yet; Debian lists it as unfixed too.

Debian lists four of them as open for 2.90 and 2.91 too. The code behind the other two came with the 2.92 test series; they affect 2.92, 2.92rel2 and 2.93.

After 2.93, further security fixes without a CVE sit on the development branch, among them an out-of-bounds heap write in blockdata_read(), an escape from the TFTP directory through the file name and a double free. They are in no release either.

Which dnsmasq CVEs are missing from the version query?

On 12 November 2026, 13 dnsmasq CVEs have no configuration in the NVD (status “Awaiting Analysis” or “Deferred”). Besides the six from October these are six from 11 May 2026 and one from April 2026, all fixed in 2.93. The interim release 2.92rel2 of 11 May 2026 also fixes the six from May. A fourteenth, CVE-2020-37127, concerns the helper dhcp_release from dnsmasq-utils 2.79.

If you run 2.90, your source decides: Yocto 5.0 carries patches for all six from May and for the two the NVD counts. Debian 12 fixed the six from May with DSA-6264-1 and postponed the other two. Yocto 4.0 carries no CVE patch for 2.90.

Which dnsmasq version do Yocto, OpenWrt and Buildroot ship?

Read from the recipes at the release tags and branches on 12 November 2026: Yocto meta-networking/recipes-support/dnsmasq in meta-openembedded, OpenWrt package/network/services/dnsmasq/Makefile, Buildroot package/dnsmasq/dnsmasq.mk. Counted are patches that name a CVE in their file name or header.

So two devices reporting “dnsmasq-2.90” can stand very differently: a Yocto 5.0 build with eight fixes applied, a Yocto 4.0 build with none.

Where is the dnsmasq version in the binary?

dnsmasq stores its version in src/option.c as the text “dnsmasq-<version>” and answers the DNS query for version.bind in class CHAOS with it. That does not hold for OpenWrt: OpenWrt builds dnsmasq with -DNO_ID, and both the text and the answer are missing. The binary then holds only the version number, directly before the text “Dnsmasq version %s”. With the option --no-ident any other build switches the answer off as well. dnsmasq --version and the start line in the syslog show the version in every case.

The line names the upstream version. Debian's security patches do not change it; a build system's patches are in its recipe.

$ strings -a usr/sbin/dnsmasq | grep -m1 "^dnsmasq-[0-9]"

dnsmasq-2.91

$ strings -a usr/sbin/dnsmasq | grep -B1 -m1 "^Dnsmasq version"

2.93
Dnsmasq version %s  %s

How do I check this by hand?

1. 1

   Read the version: strings -a usr/sbin/dnsmasq | grep -m1 "^dnsmasq-[0-9]" in the unpacked file system, for OpenWrt grep -B1 -m1 "^Dnsmasq version" instead of the first pattern, on the device dnsmasq --version.

2. 2

   Find the origin: Yocto, Buildroot, OpenWrt or a build of your own. For Yocto, read the patches in the recipe; they are not in the version line.

3. 3

   Find the features: does the device run DHCPv6, TFTP, DNSSEC validation or leasequery? Several of the 2026 vulnerabilities only affect devices that use the feature.

4. 4

   Query the NVD with cpe:2.3:a:thekelleys:dnsmasq:<version>, then read the CVEs without NVD mapping against your version, for example in Debian's security tracker for dnsmasq.

5. 5

   Check the CISA KEV catalogue for actively exploited vulnerabilities.

Can this be done automatically?

LegacyMind reads dnsmasq, the kernel and the packages with their versions from the image and checks each against the public vulnerability sources, with the location in the image and a note when a vulnerability is actively exploited. If the image proves no version, the field stays empty.