dnsmasq CVE-2026-93008

Exploitation requires a split-DNS deployment in which dnsmasq is configured to forward specific domains to a designated upstream server, AND the attacker must control that authorized upstream so it can return crafted CNAME responses. The missing control is a bailiwick check: dnsmasq caches records for the CNAME target without confirming they fall within the responding server's authorized zone. Limiting factors: this is not a default configuration (standard single-forwarder or root-hint setups are far less exposed), the attacker needs a trusted/authorized upstream position rather than arbitrary off-path access, and CVSS rates attack complexity as high (AC:H), all of which narrow realistic exploitation to environments that both use split-DNS and route some domains to an untrusted or compromisable upstream.

This is a moderate-severity DNS cache-poisoning flaw (CVSS 6.8, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N; CWE-345) whose real-world priority is bounded more by deployment conditions than by raw reach. The network vector (AV:N) and no-privilege/no-interaction metrics (PR:N/UI:N) make it look broadly exposed, but AC:H plus the description's own precondition - a split-DNS deployment where dnsmasq forwards certain domains to a specific upstream AND the attacker already controls that upstream - mean this is not a generic off-path internet attacker; it requires a privileged network position over an authorized upstream. The scope change (S:C) and high integrity impact (I:H) are justified: a successful attacker poisons cache entries that are then served to other clients for unrelated names, which is the classic trust-boundary break. No EPSS score, no CISA KEV listing, and no POC were supplied; the two references are the Red Hat advisory and Bugzilla tracker, not exploit code. The vendor decision label is 'this_month' (not act_now/emergency), consistent with a real-but-not-urgent issue: remediate on a normal patch cycle, prioritizing hosts that actually run split-DNS with untrusted or semi-trusted upstreams. No signals conflict here; the main caveat is that EPSS/KEV/POC data is simply absent, so exploitation likelihood cannot be quantified from the input.

An organization runs dnsmasq in a split-DNS configuration that forwards a set of domains to a particular upstream resolver the attacker controls (for example a compromised or malicious partner/branch resolver). The attacker answers a query with a CNAME whose target points to an unrelated name and includes attacker-chosen address records; dnsmasq caches those target records without verifying they belong to the responding server's authorized zone. Subsequent clients querying those unrelated names then receive the attacker's addresses. No public exploit was identified at time of analysis.