OpenStack Neutron CVE-2026-50266

Exploitation requires the attacker to hold the PROJECT_MANAGER role within their own OpenStack project - this is an authenticated, privileged-user attack (CVSS PR:H confirmed). The target environment must have at least one shared network - a network created by one project and shared with others via Neutron RBAC or the shared flag - that the attacker's project can access; deployments using only per-project isolated networks are not exposed. The default Neutron port RBAC policies must be in place and unmodified; operators who have already hardened RBAC to remove PROJECT_MANAGER from device_owner assignment rules are not vulnerable. High attack complexity (CVSS AC:H) is noted, reflecting that shared-network topology and specific RBAC conditions must align. Actual impact (anti-spoofing bypass, security group bypass) is further conditional on backend plugin support - not all Neutron ML2 drivers enforce device_owner-based trust equally. Exploitation does not require any user interaction from the victim tenant.

The NVD CVSS 3.1 base score of 2.2 (AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:N) is notably low, reflecting that exploitation requires high privileges (PR:H - a project manager role) and high attack complexity (AC:H), with impact limited to integrity (I:L) within an unchanged scope. These signals suggest the CVSS score deliberately down-rates the issue given the privilege bar and deployment specificity. However, the real-world risk in multi-tenant OpenStack deployments hosting shared networks is materially higher than the score implies: successful exploitation enables network-layer spoofing attacks (DHCP, MAC, IP) that can compromise other tenants' traffic without any additional privilege escalation or user interaction. The absence of a CISA KEV listing and lack of identified POC code reduce urgency for most operators, but the regression nature of this flaw (it was already fixed as CVE-2015-5240 in 2015 and reintroduced) indicates it affects deployments that may have believed the issue was permanently resolved. EPSS data was not provided in the source intelligence, so probabilistic exploitation likelihood cannot be quantified. The realistic risk is highest in public or shared OpenStack clouds where multiple untrusted projects share networks; private, single-tenant, or isolated-network deployments face minimal exposure.

An authenticated OpenStack user holding the PROJECT_MANAGER role on their own project targets a cloud environment where a shared network owned by another project is accessible. The attacker issues a Neutron API call to create or update a port on that shared network, setting the device_owner field to 'network:dhcp'. Neutron's misconfigured RBAC policy accepts the request, granting the port trusted infrastructure status and exempting it from anti-spoofing and security group rules, after which the attacker can inject spoofed DHCP responses or forged IP/MAC traffic to intercept or disrupt other tenants' network communications on the same shared segment.