CVE-2026-93008: Dnsmasq: dnsmasq: out-of-bailiwick cache injection through cname chase in split-dns configurations
A flaw was found in dnsmasq. When following a CNAME in a DNS response, the resolver can cache records for the CNAME target without checking that those records belong to the responding server's authorized zone. In split-DNS deployments that send some domains to a specific upstream, an attacker who controls that upstream can inject cache entries for unrelated names. Later clients may then receive attacker-chosen addresses for those names.
Other sources
An insufficient authenticity check was found in dnsmasq's DNS CNAME chase logic in src/rfc1035.c. When a response contains a CNAME, dnsmasq replaces the tracked query name with the CNAME target and rescans the answer section (cnameloop), then cacheinsert()s matching records. There is no bailiwick validation that those records fall within the responding server's zone of authority. Source inspection finds no bailiwick checks anywhere in dnsmasq.
In split-DNS configurations (server=/domain/ip), this lets an attacker who controls a delegated upstream inject a CNAME to an unrelated name plus a forged address record. dnsmasq caches the forged record for all clients, escaping the server=/domain/ containment boundary.
A related issue exists in findsoa() (rfc1035.c), introduced in v2.90 (commit 12ddb2a4): SOA suffix matching uses raw memcmp without a DNS label-boundary check, unlike inzone() and domainnorebind().
F3a (missing bailiwick on CNAME chase): all versions. F3b (findsoa label-boundary): v2.90 onwards. Fix: Not yet available (reporter coordinating with upstream). Reporter: Shubham Raj (Causal Security) PSIRT Ticket: PSIRTSUPT-23743
— Red Hat
Dnsmasq: dnsmasq: out-of-bailiwick cache injection through cname chase in split-dns configurations
— Microsoft