CVE-2026-55707
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.
Statement
Red Hat OpenStack Platform (RHOSP) deployments that ship Neutron with the subnet_onboard API extension enabled are affected by this vulnerability. The vulnerability requires the attacker to be an authenticated project member with access to a shared network containing subnets from other projects, which is a common multi-tenant deployment pattern. Red Hat OpenShift on OpenStack (RHOSO) deployments using Neutron for network management are also potentially affected. The severity is rated as Important because the vulnerability allows authenticated cross-project modification of network state and potential disruption of L3 routing, but does not allow unauthenticated access or code execution.
Mitigation
Restrict the subnetpool onboarding API to administrators only by adding the following to the Neutron policy configuration (policy.yaml):
onboard_network_subnets: "role:admin"
This prevents non-admin project members from using the onboard_network_subnets API while maintaining the functionality for cloud administrators. If the subnet onboarding feature is not needed in the deployment, the API can be fully disabled by setting the policy to deny all:
onboard_network_subnets: "!"
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 | 7.1 | N/A | N/A |
| Attack Vector | Network | N/A | N/A |
| Attack Complexity | Low | N/A | N/A |
| Privileges Required | Low | N/A | N/A |
| User Interaction | None | N/A | N/A |
| Scope | Unchanged | N/A | N/A |
| Confidentiality | None | N/A | N/A |
| Integrity Impact | High | N/A | N/A |
| Availability Impact | Low | N/A | N/A |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Red Hat CVSS v3 Score Explanation
Network-accessible API, low-privilege authenticated user can modify another project's subnet state and disrupt L3 routing via missing cross-project authorization check
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 Tim Shephard (roiai.ca) as the original reporter.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
