dnsmasq-Schwachstellen nach Version: was die NVD zählt und was kein Release behebt

Wie viele CVEs führt die NVD für meine dnsmasq-Version?

Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 12.11.2026 über die NVD-API ohne zurückgezogene Einträge, jeder Treffer gegen seine Konfiguration nachgeprüft. Die NVD führt dnsmasq unter cpe:2.3:a:thekelleys:dnsmasq. Die Spalte „Ausgeliefert in“ nennt, welches Build-System oder welche Distribution diese Version mitliefert.

Die Spitze bei 2.86 kommt von sieben CVEs, die die NVD nur für genau 2.86 führt. Ab 2.87 hat keine Version eine CVE mit CVSS ab 9,0.

$ 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

Welche dnsmasq-CVEs haben CVSS ab 9,0?

Welche dnsmasq-Lücken behebt auch 2.93 nicht?

Am 29.10.2026 hat Red Hat als CNA sechs dnsmasq-CVEs veröffentlicht. Die NVD hat sie am 12.11.2026 noch keiner Version zugeordnet, eine Versionsabfrage für 2.93 findet sie also nicht. Fünf sind im Entwicklungszweig behoben, mit Commits vom 16. und 17.10.2026; ein Release mit diesen Korrekturen gibt es nicht. Für CVE-2026-93010 gibt es noch keinen Fix, auch Debian führt sie als unbehoben.

Debian führt vier davon auch für 2.90 und 2.91 als offen. Der Code hinter den anderen zwei kam mit der Testreihe zu 2.92; sie treffen 2.92, 2.92rel2 und 2.93.

Nach 2.93 liegen im Entwicklungszweig weitere Sicherheitskorrekturen ohne CVE, darunter ein Schreibzugriff außerhalb des Heap-Puffers in blockdata_read(), ein Verlassen des TFTP-Verzeichnisses über den Dateinamen und ein doppeltes Freigeben von Speicher. Auch sie stehen in keinem Release.

Welche dnsmasq-CVEs fehlen in der Versionsabfrage?

13 dnsmasq-CVEs haben in der NVD am 12.11.2026 keine Konfiguration (Status „Awaiting Analysis“ oder „Deferred“). Neben den sechs vom Oktober sind das sechs vom 11.05.2026 und eine vom April 2026, alle behoben in 2.93. Die sechs vom Mai behebt auch der Zwischenstand 2.92rel2 vom 11.05.2026. Eine vierzehnte, CVE-2020-37127, betrifft das Zusatzwerkzeug dhcp_release aus dnsmasq-utils 2.79.

Wer 2.90 betreibt, hängt an seiner Quelle: Yocto 5.0 trägt Patches für alle sechs vom Mai und für die zwei, die die NVD zählt. Debian 12 hat die sechs vom Mai mit DSA-6264-1 behoben und die zwei anderen zurückgestellt. Yocto 4.0 trägt für 2.90 keinen CVE-Patch.

Welche dnsmasq-Version liefern Yocto, OpenWrt und Buildroot mit?

Gelesen aus den Rezepten an den Release-Tags und Zweigen, Stand 12.11.2026: Yocto meta-networking/recipes-support/dnsmasq in meta-openembedded, OpenWrt package/network/services/dnsmasq/Makefile, Buildroot package/dnsmasq/dnsmasq.mk. Gezählt sind Patches, die eine CVE im Namen oder im Kopf tragen.

Zwei Geräte mit „dnsmasq-2.90“ können also verschieden dastehen: ein Yocto-5.0-Build mit acht eingespielten Korrekturen, ein Yocto-4.0-Build ohne.

Wo steht die dnsmasq-Version im Binary?

dnsmasq legt seine Version in src/option.c als Text „dnsmasq-<Version>“ ab und beantwortet damit die DNS-Anfrage nach version.bind in der Klasse CHAOS. Das gilt nicht für OpenWrt: OpenWrt baut dnsmasq mit -DNO_ID, dort fehlen der Text und die Antwort. Im Binary steht dann nur die Versionsnummer, direkt vor dem Text „Dnsmasq version %s“. Mit der Option --no-ident schaltet auch jeder andere Build die Antwort ab. dnsmasq --version und die Startzeile im Syslog zeigen die Version in jedem Fall.

Die Zeile nennt die Upstream-Version. Debians Sicherheitspatches ändern sie nicht, die Patches eines Build-Systems stehen im Rezept.

$ 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

Wie prüfe ich das von Hand?

1. 1

   Version lesen: strings -a usr/sbin/dnsmasq | grep -m1 "^dnsmasq-[0-9]" im entpackten Dateisystem, bei OpenWrt grep -B1 -m1 "^Dnsmasq version" statt des ersten Musters, auf dem Gerät dnsmasq --version.

2. 2

   Herkunft klären: Yocto, Buildroot, OpenWrt oder ein eigener Build. Bei Yocto die Patches im Rezept lesen; sie stehen nicht in der Versionszeile.

3. 3

   Funktionen bestimmen: Läuft DHCPv6, TFTP, DNSSEC-Validierung oder Leasequery? Mehrere der Lücken von 2026 treffen nur Geräte, die diese Funktion nutzen.

4. 4

   NVD abfragen mit cpe:2.3:a:thekelleys:dnsmasq:<Version>, dann die CVEs ohne NVD-Zuordnung gegen Ihre Version lesen, etwa im Security Tracker von Debian für dnsmasq.

5. 5

   Den KEV-Katalog der CISA auf aktiv ausgenutzte Lücken prüfen.

Geht das auch automatisch?

LegacyMind liest aus dem Image dnsmasq, den Kernel und die Pakete mit ihren Versionen und gleicht jede gegen die öffentlichen Schwachstellenquellen ab, mit der Fundstelle im Image und dem Vermerk, ob eine Lücke aktiv ausgenutzt wird. Belegt das Image keine Version, bleibt das Feld leer.