Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 deviceowner to a value that has "network:" at the beginning ("network:dhcp" for example). The default port RBAC policies incorrectly included PROJECTMANAGER 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).
Recommended action: Upgrade to 28.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenStack Neutron before 28.0.1, the tagging controller enforces plural policy action names on single-tag write operations while the defined policy rules use singular names. The mismatched names evaluate as allowed under the default policy, permitting a project reader to create and update tags on same-project resources. Deployments running Neutron 26.0.0 or later are affected.
Recommended action: Upgrade to 28.0.1, 27.0.3 or 26.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenStack Neutron before 25.0.1, neutron/extensions/tagging.py can use an incorrect ID during policy enforcement. It does not apply the proper policy check for changing network tags. An unprivileged tenant is able to change (add and clear) tags on network objects that do not belong to the tenant, and this action is not subjected to the proper policy authorization check. This affects 23 before 23.2.1, 24 before 24.0.2, and 25 before 25.0.1.
Recommended action: Upgrade to 25.0.1, 24.0.2 or 23.2.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.
Recommended action: Upgrade to 20.3.0, 19.5.0 or 18.6.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the routes middleware in OpenStack Neutron before 16.4.1, 17.x before 17.2.1, and 18.x before 18.1.1. By making API requests involving nonexistent controllers, an authenticated user may cause the API worker to consume increasing amounts of memory, resulting in API performance degradation or denial of service.
Recommended action: Upgrade to 18.1.1, 17.2.1 or 16.4.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in OpenStack Neutron before 16.4.1, 17.x before 17.2.1, and 18.x before 18.1.1. Authenticated attackers can reconfigure dnsmasq via a crafted extradhcpopts value.
Recommended action: Upgrade to 18.1.1, 17.2.1 or 16.4.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Neutron before 16.4.1, 17.x before 17.1.3, and 18.0.0 allows hardware address impersonation when the linuxbridge driver with ebtables-nft is used on a Netfilter-based platform. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the hardware addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations.
Recommended action: Upgrade to 17.1.3 or 16.4.1 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in openstack-neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Source: OpenStack project. Versions before openstack-neutron 15.3.3, openstack-neutron 16.3.1 and openstack-neutron 17.1.1 are affected.
Recommended action: Upgrade to 17.1.1, 16.3.1 or 15.3.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The l3-agent in OpenStack Neutron 2012.2 before 2013.2.3 does not check the tenant id when creating ports, which allows remote authenticated users to plug ports into the routers of arbitrary tenants via the device id in a port-create command.
Recommended action: Upgrade to 2013.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Race condition in OpenStack Neutron before 2014.2.4 and 2015.1 before 2015.1.2, when using the ML2 plugin or the security groups AMQP API, allows remote authenticated users to bypass IP anti-spoofing controls by changing the device owner of a port to start with network: before the security group rules are applied.
Recommended action: Upgrade to 7.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The IPTables firewall in OpenStack Neutron up to 7.0.4 and 8.x before 8.1.0 allows remote attackers to bypass an intended MAC-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via (1) a crafted DHCP discovery message or (2) crafted non-IP traffic.
Recommended action: Upgrade to 8.1.0 or 7.1.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Neutron before 2014.2.4 (juno) and 2015.1.x before 2015.1.1 (kilo), when using the IPTables firewall driver, allows remote authenticated users to cause a denial of service (L2 agent crash) by adding an address pair that is rejected by the ipset tool.
Recommended action: Upgrade to 2015.1.1 or 2014.2.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended DHCP-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a crafted DHCP discovery message.
Recommended action: Upgrade to 8.1.1 or 7.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The IPTables firewall in OpenStack Neutron before 7.0.4 and 8.0.0 through 8.1.0 allows remote attackers to bypass an intended ICMPv6-spoofing protection mechanism and consequently cause a denial of service or intercept network traffic via a link-local source address.
Recommended action: Upgrade to 8.1.1 or 7.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Live-migrated instances are briefly able to inspect traffic for other instances on the same hypervisor. This brief window could be extended indefinitely if the instance's port is set administratively down prior to live-migration and kept down after the migration is complete. This is possible due to the Open vSwitch integration bridge being connected to the instance during migration. When connected to the integration bridge, all traffic for instances using the same Open vSwitch instance would potentially be visible to the migrated guest, as the required Open vSwitch VLAN filters are only applied post-migration. Versions of openstack-neutron before 13.0.0.0b2, 12.0.3, 11.0.5 are vulnerable.
Recommended action: Upgrade to 13.0.0.0b2 (pre-release), 12.0.3 or 11.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in the iptables firewall module in OpenStack Neutron before 10.0.8, 11.x before 11.0.7, 12.x before 12.0.6, and 13.x before 13.0.3. By setting a destination port in a security group rule along with a protocol that doesn't support that option (for example, VRRP), an authenticated user may block further application of security group rules for instances from any project/tenant on the compute hosts to which it's applied. (Only deployments using the iptables security group driver are affected.)
Recommended action: Upgrade to 13.0.3, 12.0.6, 11.0.7 or 10.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in OpenStack Neutron 11.x before 11.0.7, 12.x before 12.0.6, and 13.x before 13.0.3. By creating two security groups with separate/overlapping port ranges, an authenticated user may prevent Neutron from being able to configure networks on any compute nodes where those security groups are present, because of an Open vSwitch (OVS) firewall KeyError. All Neutron deployments utilizing neutron-openvswitch-agent are affected.
Recommended action: Upgrade to 13.0.3, 12.0.6 or 11.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using the Linux bridge ml2 driver, non-privileged tenants are able to create and attach ports without specifying an IP address, bypassing IP address validation. A potential denial of service could occur if an IP address, conflicting with existing guests or routers, is then assigned from outside of the allowed allocation pool. Versions of openstack-neutron before 13.0.0.0b2, 12.0.3 and 11.0.5 are vulnerable.
Recommended action: Upgrade to 13.0.0.0b2 (pre-release), 12.0.4 or 11.0.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTPSConnections in OpenStack Keystone 2013, OpenStack Compute 2013.1, and possibly other OpenStack components, fail to validate server-side SSL certificates.
Recommended action: Upgrade to 7.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.