CVE-2026-71194 in Designate
Summary
by MITRE • 08/13/2026
In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The _handle_notify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability in OpenStack Designate versions prior to 22.0.2 represents a critical denial-of-service condition that stems from improper handling of DNS record lookups across multiple pools. This flaw occurs within the mDNS handler component which processes both record queries and NOTIFY requests without proper pool context awareness, creating a scenario where duplicate zone names across different pools can trigger deterministic failures. The technical implementation lacks proper isolation mechanisms between pool configurations, allowing a single malformed or malicious packet to cascade into complete service disruption for affected DNS resolution paths.
The operational impact of this vulnerability extends beyond simple service interruption to encompass potential exploitation through unauthenticated UDP packets targeting the _handle_notify path. This creates an attack surface where remote adversaries can trigger REFUSED responses for all subsequent DNS queries through the compromised pathway, effectively rendering the mDNS handler ineffective for legitimate traffic. The deterministic nature of the error means that attackers can reliably reproduce this condition, making it particularly dangerous for production environments where consistent DNS resolution is critical for system operations.
This vulnerability manifests in two primary attack vectors: the cross-tenant zone overlap scenario described in related CVEs and legitimate same-tenant cross-pool configurations. Both scenarios exploit the fundamental flaw in pool context handling where the mDNS service fails to properly distinguish between zones with identical names residing in different pool configurations. The absence of effective mitigation through BIND9 views is particularly concerning since it demonstrates that upstream DNS configuration layers cannot compensate for this lower-level service flaw, indicating a design weakness in the service architecture itself.
The security implications align with CWE-200 (Information Exposure) and CWE-347 (Improper Verification of Cryptographic Signature) categories, as the vulnerability exposes system state information through deterministic error responses while also enabling unauthorized service disruption. From an ATT&CK framework perspective, this maps to T1499.004 (Endpoint Denial of Service) and potentially T1566.001 (Phishing via Social Media), as the service disruption can be achieved through simple UDP packet injection without requiring authentication or complex attack chains. The vulnerability's exploitation requires minimal resources and can cause cascading failures throughout the DNS resolution infrastructure, making it particularly dangerous in cloud environments where Designate serves as a foundational component for tenant networking.
Organizations should implement immediate mitigations including upgrading to OpenStack Designate 22.0.2 or later versions that contain proper pool context handling, implementing network-level restrictions to limit UDP packet access to the mDNS handler ports, and monitoring for unusual patterns in DNS REFUSED responses that may indicate exploitation attempts. Additionally, administrators should review existing zone configurations to eliminate duplicate zone names across pools where possible, though this may not always be feasible in complex multi-tenant environments where such overlaps are legitimate business requirements.