High [CVE-2026-55707] Shared-network consumer can re-scope another project's subnets via subnetpool onboarding

In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers.

An authorization bypass was found in the OpenStack Neutron subnetpool onboarding API endpoint (PUT /v2.0/subnetpools/{id}/onboard_network_subnets). When a caller supplies a network_id, the API only verifies that the network is visible to the caller but does not verify that the caller owns the subnets on that network.

When a network is RBAC-shared or globally shared, any project member with network visibility can invoke the API to onboard another project's subnets into the caller's own subnetpool, mutating the victim's subnet records (setting subnetpool_id to the attacker-controlled pool).

If the attacker's subnetpool is associated with an address scope, Neutron syncs the victim's router interfaces with the attacker-controlled address scope, silently altering L3 routing, NAT, and address-scope behavior.

The upstream fix adds an ownership check ensuring the caller has admin-or-owner authority over each subnet being onboarded, not merely visibility of the parent network.