dnsdist CVE-2026-33599

The vulnerability requires two SPECIFIC prerequisites: (1) dnsdist must be explicitly configured with Discovery of Designated Resolvers upgrade enabled via the autoUpgrade option (Lua newServer configuration) or auto_upgrade setting (YAML configuration)-DDR is NOT enabled by default, so this is an opt-in feature requiring deliberate administrator configuration; (2) the attacker must be on the same network segment (AV:A) as dnsdist or between dnsdist and its configured backend DNS servers, capable of observing and spoofing backend DNS responses. Standard deployments with DDR disabled are not vulnerable. Exploitation is further limited by high attack complexity (AC:H), indicating the attacker must craft the SVCB response with specific malformed data that the current dnsdist version fails to handle-not a trivial attack. No special authentication is required from the attacker's perspective (PR:N), but the attacker must have network-layer adjacency.

Real-world risk is LOW-TO-MODERATE despite moderate CVSS score of 3.1, which reflects the technical reality: the vulnerability requires multiple limiting factors that substantially reduce exploitability. The CVSS vector (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) indicates adjacent network access only-not network-wide remote exploitation-and high attack complexity. Critically, DDR upgrade is NOT enabled by default, so only installations where administrators have explicitly activated autoUpgrade or auto_upgrade via configuration are at risk. This self-selected, opt-in configuration requirement dramatically narrows the attack surface. The impact is limited to availability (denial of service with low severity per the 'A:L' rating), with no confidentiality or integrity breach possible. No public exploit code or CISA KEV status has been identified at analysis time, and the vulnerability requires an attacker to be on the same network segment (adjacent network access) to respond to backend queries-a significant operational constraint. Organizations running dnsdist with DDR disabled (the default) face zero risk. This should be prioritized based on deployment specifics: if your organization uses dnsdist with DDR enabled in a hostile network environment (e.g., untrusted backend connectivity), patch immediately; if DDR is disabled or backends are trusted, risk is mitigated.

An attacker positioned on the same network segment as a dnsdist instance (e.g., a compromised host on the internal network, or an attacker with ARP/BGP hijacking capability) observes DNS queries from dnsdist destined for a backend resolver. When dnsdist has DDR enabled, it sends a DDR upgrade request (SVCB query) to the backend. The attacker intercepts this query and responds with a maliciously crafted SVCB record that triggers a parsing failure or resource exhaustion in dnsdist's DDR upgrade handler, causing the resolver to become unavailable or degrade performance. The high attack complexity suggests the SVCB crafting requires specific knowledge of dnsdist's parsing logic, and the adjacent-only vector means the attacker cannot exploit this from the internet.