CVE-2026-71193
Description
A flaw was found in OpenStack Designate. When the AttributeFilter scheduler is enabled with multiple DNS pools, an authenticated tenant can bypass zone ownership checks by scheduling a zone to a different pool. The database uniqueness constraint on zone names is pool-scoped, and the subzone/superzone ownership checks in the Central service include pool_id in their query criteria, making them pool-scoped rather than global. This allows a tenant to create zones that overlap with another tenant's zones in a different pool, bypassing cross-tenant namespace isolation. Successful exploitation could lead to cross-tenant DNS zone overlap and subzone ownership bypass.
Statement
Red Hat OpenStack Platform (RHOSP) ships Designate across multiple versions. Multipool deployments using the AttributeFilter scheduler were never a fully supported configuration in any RHOSP version. In RHOSP 13, 16.2, and 17.1 (TripleO deployment), the default scheduler_filters configuration is default_pool, which assigns all zones to a single pool and prevents the cross-tenant zone overlap.
For Red Hat OpenStack Services on OpenShift (RHOSO, openstack-18.0), the designate-operator hardcodes scheduler_filters to pool_id_attribute, in_doubt_default_pool in the central service configuration template. The pool_id_attribute filter enforces the zone_create_forced_pool policy check, which defaults to requiring the SYSTEM_ADMIN role, preventing regular tenants from selecting pools. Therefore, RHOSO is not affected in the default configuration. However, RHOSO becomes affected if an administrator uses the customServiceConfig field to set scheduler_filters to include the attribute filter, as customServiceConfig is a freeform string with no CRD validation or webhook filtering, written to a config-dir override that oslo.config loads with last-wins semantics, silently overriding the operator's safe default.
Mitigation
For deployments not using multi-pool DNS: verify that the 'scheduler_filters' configuration option in the [service:central] section only contains 'default_pool' (the default value). This prevents tenants from selecting alternative pools and eliminates the zone overlap vulnerability.
For deployments using multi-pool DNS: replace the 'attribute' filter with 'pool_id_attribute' in the 'scheduler_filters' configuration. The pool_id_attribute filter enforces the 'zone_create_forced_pool' policy check, which defaults to requiring the SYSTEM_ADMIN role, preventing regular tenants from choosing pools.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 4.3 | N/A | 9.6 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Changed |
| Confidentiality | None | N/A | None |
| Integrity Impact | Low | N/A | High |
| Availability Impact | None | N/A | High |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Red Hat CVSS v3 Score Explanation
Zone overlap only: authenticated tenant can bypass pool-scoped ownership checks to create overlapping DNS zones in a different pool
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data; Read Files or Directories
An attacker could bypass intended access restrictions to read sensitive data, either by reading the data directly from a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity
Technical Impact: Modify Application Data; Modify Files or Directories
An attacker could bypass intended access restrictions to modify sensitive data, either by writing the data directly to a data store that is not correctly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control
Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism
An attacker could bypass intended access restrictions to gain privileges by modifying or reading critical data directly, or by accessing privileged functionality.
Confidentiality,Integrity,Availability
Technical Impact: Execute Unauthorized Code or Commands
An attacker could use elevated privileges to execute unauthorized commands or code.
Availability
Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)
An attacker could gain unauthorized access to resources on the system and excessively consume those resources, leading to a denial of service.
Acknowledgements
Upstream acknowledges Omer Schwartz (Red Hat) and Tore Anderson (Redpill Linpro AS) as the original reporters.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
