CVE-2026-50266
OpenStack Neutron Port RBAC Privilege Escalation Vulnerability
Publication date: 2026-06-04
Last updated on: 2026-06-04
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openstack | neutron | From 25.0.0 (inc) to 25.2.4 (exc) |
| openstack | neutron | From 26.0.0 (inc) to 26.0.4 (exc) |
| openstack | neutron | From 27.0.0 (inc) to 27.0.3 (exc) |
| openstack | neutron | to 28.0.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-50266 is a vulnerability in OpenStack Neutron where a project manager who does not own a network can create or update a port on a shared network owned by another project and set the device_owner field to a value starting with "network:", such as "network:dhcp".
This happens because the default port RBAC policies incorrectly included the PROJECT_MANAGER role without requiring network ownership, allowing these managers to obtain trusted network-service port behavior on shared networks.
As a result, this can bypass normal security protections like anti-spoofing, DHCP spoofing, MAC spoofing, and IP spoofing defenses, enabling attacks against other tenants on the shared network.
This vulnerability is a regression of a previously fixed issue (CVE-2015-5240) and was introduced by changes supporting the manager role.
How can this vulnerability impact me? :
This vulnerability can allow a project manager without network ownership to bypass security controls on shared networks.
Specifically, it can enable DHCP spoofing, MAC spoofing, and IP spoofing attacks against other tenants sharing the same network.
Such attacks can disrupt network services, compromise tenant isolation, and potentially lead to unauthorized network access or data interception.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves identifying if any project managers have created or updated ports on shared networks owned by other projects with the device_owner field set to values beginning with "network:", such as "network:dhcp".
You can audit Neutron port configurations to find ports where device_owner starts with "network:" but the port belongs to a project different from the network owner.
Suggested commands include using OpenStack CLI or API queries to list ports and filter by device_owner and project ownership. For example:
- openstack port list --shared --long
- openstack port show <port-id> to check device_owner and project_id
- Use scripts or queries to identify ports on shared networks where device_owner starts with "network:" but the port's project_id is not the network owner.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves applying patches that remove PROJECT_MANAGER from the create/update port policies allowing device_owner to be set to "network:*" without network ownership.
Ensure that only NET_OWNER_MEMBER or ADMIN_OR_NET_OWNER_MEMBER roles can create or update ports with device_owner values starting with "network:".
If patching is not immediately possible, restrict project managers' permissions to prevent them from creating or updating ports on shared networks with device_owner set to trusted network-service values.
Review and tighten RBAC policies related to port creation and updates in Neutron to enforce network ownership requirements.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows a project manager in OpenStack Neutron to bypass security protections such as anti-spoofing and security group rules by creating or updating ports on shared networks owned by other projects with trusted device_owner values. This can enable DHCP, MAC, or IP spoofing attacks against other tenants on the shared network.
Such unauthorized access and spoofing capabilities could lead to unauthorized data access or network disruptions, which may impact compliance with standards and regulations like GDPR and HIPAA that require strict controls on data confidentiality, integrity, and network security.
However, the provided resources do not explicitly discuss the direct impact of this vulnerability on compliance with these regulations.