CVE-2026-55707

This is an authorization bypass in OpenStack Neutron's subnetpool onboarding feature. A tenant can attach subnets they don't own to their subnetpools if those subnets are on shared networks — the code never verified that the tenant initiating the onboarding operation has any claim to the subnet being attached. The patch in versions prior to 28.0.2 adds an ownership check to enforce that only the subnet's owning project (or an admin) can onboard that subnet into a pool. If you're running Neutron, check your version. Any deployment on trains prior to 28.0.2 is affected. The vulnerable code path is triggered when a non-admin project calls whatever API surface handles subnet-to-subnetpool attachment — specifically when the target subnet lives on a network with shared=True. The attack surface requires an authenticated tenant, which limits scope to multi-tenant OpenStack clouds, but the impact extends beyond the attacking tenant: mutating subnetpool membership alters address scope behavior and can cascade into L3 routing state that affects other tenants sharing that network infrastructure. The severity is worth contextualizing. CVSS 7.1 doesn't capture the multi-party nature of the harm — one tenant can persistently reconfigure network topology that another tenant depends on, without the victim's knowledge. This isn't just data modification; it's infrastructure mutation across trust boundaries. Remediate by upgrading to 28.0.2 or later. After patching, audit your existing subnetpool membership to identify any onboarding events that shouldn't have been permitted — the vulnerability may have been exploitable for years before this disclosure. Pay particular attention to subnetpools that contain subnets from projects other than the pool's owner, as those represent the exact composition path this bypass enabled. The deeper pattern here is worth noting: this exact class of flaw — cross-tenant authorization bypass through shared resource composition — recurs across infrastructure platforms. The fix 'just' adds an ownership check, but the underlying issue is that shared network semantics create authorization boundaries that are easy to implement incorrectly. Treat any API operation touching shared resources as requiring dual authorization reasoning: does the caller have permission, AND does the operation affect resources owned by parties who haven't consented?

Reviewed through automated stages and approved by a human before publication.