Description

In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-08-12T23:17:22.030Z",
  "pubdate": "2026-08-12T23:17:22.030Z",
  "executiveSummary": "OpenStack Designate before versions 22.0.1 is affected by a cross-tenant DNS hijacking and denial-of-service vulnerability arising from improperly scoped zone creation checks. Specifically, validation functions such as _is_subzone, _is_superzone, and the duplicate-zone database constraint are incorrectly restricted to the target pool only rather than evaluating globally across all tenants.\nThe vulnerability allows an authenticated user to bypass isolation barriers by explicitly scheduling the creation of a zone to a different resource pool utilizing the AttributeFilter scheduler. This capability enables malicious actors to instantiate overlapping DNS zones that directly conflict with pre-existing zones owned by other tenants.\nSuccessful exploitation results in severe integrity and availability impacts, specifically facilitating cross-tenant DNS hijacking—where victim traffic is maliciously redirected to attacker-controlled IP addresses—and DNS denial of service yielding NODATA responses.\nThe primary exploitation requirement is a non-default yet documented and supported multi-pool deployment architecture where the AttributeFilter is actively configured within the scheduler_filters parameter. Attackers require standard authenticated user access within the OpenStack environment to leverage the scheduling mechanism for unauthorized zone placement.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient global scoping of zone creation validation logic within OpenStack Designate. The codebase relies on internal check routines—specifically _is_subzone, _is_superzone, and the core duplicate-zone database constraint—to enforce uniqueness and hierarchical validity. However, these validation mechanisms evaluate constraints exclusively within the boundaries of the designated target pool rather than performing a global verification across the entire DNS namespace or multi-pool topology.\nThe vulnerable components reside within the OpenStack Designate scheduling and zone creation handling modules, specifically affecting versions prior to 22.0.1. The flaw is exposed when deployments utilize a multi-pool architecture combined with the AttributeFilter scheduler enabled via the scheduler_filters configuration option.\nThe step-by-step attack flow proceeds as follows: First, an authenticated attacker identifies a target zone owned by a different tenant in the OpenStack environment. Second, the attacker issues a zone creation API request for an overlapping or identical DNS zone. Third, by leveraging the AttributeFilter scheduler, the attacker explicitly designates a different target pool for the new zone creation request. Fourth, because internal validation methods like _is_subzone, _is_superzone, and the duplicate-zone DB constraint only inspect the target pool specified in the request, they fail to detect the collision with the victim tenant's existing zone in another pool. Finally, Designate permits the creation of the conflicting zone.\nPost-exploitation impact includes the capability to execute cross-tenant DNS hijacking, successfully intercepting or redirecting victim traffic destined for the targeted domain to attacker-controlled infrastructure. Alternatively, attackers can induce DNS denial of service conditions by generating conflicting zones that result in NODATA responses, disrupting dependent services and applications within the cloud environment."
}