openstack-neutron: openstack-neutron: Shared-network consumer can re-scope another project's subnets via subnetpool onboarding
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| OpenStack | Neutron | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Openstack | Neutron |
|
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4735-1 | neutron security update |
Debian DSA |
DSA-6444-1 | neutron security update |
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.427% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | 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. |
| CPEs | cpe:2.3:a:openstack:neutron:*:*:*:*:*:*:*:* | |
| References |
| |
| Metrics |
cvssV4_0
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Openstack
Openstack neutron |
|
| Vendors & Products |
Openstack
Openstack neutron |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | openstack-neutron: openstack-neutron: Shared-network consumer can re-scope another project's subnets via subnetpool onboarding | |
| Weaknesses | CWE-863 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|