What is the CVSS score of CVE-2026-50266?

CVE-2026-50266 has a CVSS 3.1 base score of 2.2 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-50266?

Yes, a patch is available for CVE-2026-50266. Update the affected software to the latest version immediately.

OpenStack Neutron CVE-2026-50266

EUVD-2026-34301 LOW

Incorrect Authorization (CWE-863)

2026-06-04 mitre

GHSA-qmc5-gv6v-8p22

Authentication Bypass Neutron

2.2

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

2.2 LOW

AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Jun 04, 2026 - 17:05 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

29 pypi packages depend on neutron (29 direct, 1 indirect)

Ecosystem-wide dependent count for version 28.0.1.

DescriptionCVE.org

In OpenStack Neutron before 28.0.1, a project manager can create or update a port on a shared network owned by another project and set device_owner to a value that has "network:" at the beginning ("network:dhcp" for example). The default port RBAC policies incorrectly included PROJECT_MANAGER without requiring network ownership, allowing any project manager to obtain trusted network-service port behavior on shared networks. Depending on backend and deployment, this can bypass anti-spoofing and security group protections, enabling DHCP, MAC, or IP spoofing against other tenants on the shared network. This is a regression of CVE-2015-5240 (OSSA-2015-018).

AnalysisAI

Incorrect RBAC policy in OpenStack Neutron before 28.0.1 allows an authenticated project manager to set device_owner on ports of shared networks they do not own to privileged network-service values (e.g., 'network:dhcp'), obtaining trusted network-service port behavior without owning the underlying network. Depending on backend and deployment configuration, this enables DHCP, MAC, or IP spoofing against co-tenants sharing that network, effectively bypassing anti-spoofing and security group protections. This is a confirmed regression of CVE-2015-5240 (OSSA-2015-018); no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.

Technical ContextAI

OpenStack Neutron is the network-as-a-service component of OpenStack, responsible for managing virtual networks, ports, and associated security policies for multi-tenant cloud deployments. Neutron enforces access control through RBAC policies that govern which roles can perform which port operations. The root cause, classified as CWE-863 (Incorrect Authorization), is that Neutron's default port RBAC policies for create and update operations incorrectly included the PROJECT_MANAGER role without a corresponding ownership check on the target network. Normally, setting device_owner to a value prefixed with 'network:' (such as 'network:dhcp' or 'network:router_interface') signals to the Neutron data plane that the port belongs to a trusted infrastructure service, which exempts it from anti-spoofing rules and security group enforcement. By exploiting the missing ownership guard, a project manager on any project with access to a shared network can impersonate a network-service port on that network. The affected CPE is cpe:2.3:a:openstack:neutron:*:*:*:*:*:*:*:*, covering all Neutron versions prior to 28.0.1.

RemediationAI

The primary fix is to upgrade OpenStack Neutron to version 28.0.1 or later, where the default port RBAC policies have been corrected to require network ownership when setting a device_owner value prefixed with 'network:'. Three upstream patch commits have been published: https://review.opendev.org/990273, https://review.opendev.org/990353, and https://review.opendev.org/990356. Operators unable to patch immediately should audit and manually restrict their port RBAC policies to remove PROJECT_MANAGER from the rules governing device_owner assignment on shared networks - note that this may break legitimate automation workflows that rely on project managers managing their own network-service ports, requiring policy review before applying. Additionally, operators should audit existing ports on shared networks for unexpected device_owner values beginning with 'network:' that were set by non-owner projects, as these may indicate prior exploitation or misconfiguration. The Launchpad bug (https://launchpad.net/bugs/2152115) and oss-security thread (https://www.openwall.com/lists/oss-security/2026/06/04/6) provide additional operator guidance.