Bug 2510947 (CVE-2026-71193) - CVE-2026-71193 openstack-designate: designate: cross-tenant DNS zone overlap via pool-scoped ownership checks when using AttributeFilter scheduler
Summary: CVE-2026-71193 openstack-designate: designate: cross-tenant DNS zone overlap ...
Keywords:
Status: NEW
Alias: CVE-2026-71193
Deadline: 2026-08-11
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-04 11:17 UTC by OSIDB Bzimport
Modified: 2026-08-17 16:46 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-04 11:17:20 UTC
Tore Anderson (Redpill Linpro AS) reported a vulnerability in OpenStack Designate zone scheduling. The database uniqueness constraint on zone names is scoped to (name, deleted, pool_id) in designate/storage/sqlalchemy/tables.py:146, allowing the same zone name to exist in multiple pools. The _is_subzone() and _is_superzone() ownership checks in designate/central/service.py (lines 288-328) include pool_id in their query criteria, making them pool-scoped rather than global. When the AttributeFilter scheduler (designate/scheduler/filters/attribute_filter.py) is enabled, any authenticated tenant with the default create_zone policy (role:member) can supply zone attributes that match a non-default pool, directing their zone there and bypassing the ownership checks. This allows cross-tenant zone overlap, subzone ownership bypass, and superzone takeover.

Omer Schwartz (Red Hat) discovered a related vulnerability in the mDNS handler. The _handle_notify() method in designate/mdns/handler.py (lines 90-171) performs a zone lookup using only {name, type='SECONDARY', deleted=False} without pool_id scoping. When colliding zones exist across pools, the storage layer's _find() method (designate/storage/sqlalchemy/base.py:270-280) finds 2 results and raises ZoneNotFound (it expects exactly 1 with one=True), causing all NOTIFY processing for the affected zone name to fail with NOTAUTH. This NOTIFY handler path is reachable via unauthenticated UDP on port 5354 (default: 0.0.0.0:5354) because the SerializationMiddleware creates an admin context with all_tenants=True for every request and TSIG enforcement is off by default.

The QUERY and AXFR handlers were previously updated to be pool-aware via _zone_criterion_from_request(), but the NOTIFY handler was not updated.

Affected versions: >=1.0.0 <20.0.2, >=21.0.0 <21.0.1, >=22.0.0 <22.0.1. Only deployments using the AttributeFilter scheduler with multiple pools are affected. The default configuration uses the default_pool filter and is not vulnerable to the zone overlap (Vuln 1), but remains vulnerable to the mDNS NOTIFY DoS (Vuln 2) if colliding zones are created by other means (e.g., admin using PoolIDAttributeFilter).

Upstream patches provided for master, stable/2025.1, stable/2025.2, and stable/2026.1 branches. Proposed public disclosure: 2026-08-11 1500UTC.

Original private report: https://launchpad.net/bugs/2160533
PSIRT Ticket: PSIRTSUPT-20989


Note You need to log in before you can comment on or make changes to this bug.