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
51 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The icreateimagesandbacking (aka createimagesandbacking) method in libvirt driver in OpenStack Compute (Nova) Grizzly, Havana, and Icehouse, when using KVM live block migration, does not properly create all expected files, which allows attackers to obtain snapshot root disk contents of other users via ephemeral storage.
Recommended action: Upgrade to 12.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.
The image parser in OpenStack Cinder prior to 7.0.2, and 8.0.0 and above, prior to 9.0.0; Glance prior to 14.00; and Nova prior to 12.0.4 does not properly limit qemu-img calls, which might allow attackers to cause a denial of service (memory and disk consumption) via a crafted disk image. This issue is patched in Cinder 7.0.2 and 9.0.0; Glance 14.0.0; and Nova 12.0.4
Recommended action: Upgrade to 12.0.4 or later, 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 exceptionwrapper.py in OpenStack Nova 13.x through 13.1.3, 14.x through 14.0.4, and 15.x through 15.0.1. Legacy notification exception contexts appearing in ERROR level logs may include sensitive information such as account passwords and authorization tokens.
Recommended action: Upgrade to 15.0.2, 14.0.5 or 13.1.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (Nova) Essex before 2011.3 allows remote authenticated users to cause a denial of service (Nova-API log file and disk consumption) via a long server name.
Recommended action: Upgrade to 12.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.
Algorithmic complexity vulnerability in OpenStack Compute (Nova) before 2013.1.3 and Havana before havana-3 does not properly handle network source security group policy updates, which allows remote authenticated users to cause a denial of service (nova-network consumption) via a large number of server-creation operations, which triggers a large number of update requests.
Recommended action: Upgrade to 12.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.
Multiple directory traversal vulnerabilities in OpenStack Nova before 2011.3.1, when the EC2 API and the S3/RegisterImage image-registration method are enabled, allow remote authenticated users to overwrite arbitrary files via a crafted (1) tarball or (2) manifest.
Recommended action: Upgrade to 12.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.
api/metadata/handler.py in OpenStack Compute (Nova) before 2013.2.4, 2014.x before 2014.1.2, and Juno before Juno-2, when proxying metadata requests through Neutron, makes it easier for remote attackers to guess instance ID signatures via a brute-force attack that relies on timing differences in responses to instance metadata requests.
Recommended action: Upgrade to 2014.1.2 or 2013.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.
OpenStack Compute (Nova) before 2013.1.3 and Havana before havana-2 does not properly enforce the os-flavor-access:ispublic property, which allows remote authenticated users to obtain sensitive information (flavor properties), boot arbitrary flavors, and possibly have other unspecified impacts by guessing the flavor id.
Recommended action: Upgrade to 2013.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (Nova) before 2014.1.4, 2014.2.x before 2014.2.3, and kilo before kilo-3 does not validate the origin of websocket requests, which allows remote attackers to hijack the authentication of users for access to consoles via a crafted webpage.
Recommended action: Upgrade to 2014.2.3 or 2014.1.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (nova) 2015.1 through 2015.1.1, 2014.2.3, and earlier does not stop the migration process when the instance is deleted, which allows remote authenticated users to cause a denial of service (disk, network, and other resource consumption) by resizing and then deleting an instance.
Recommended action: Upgrade to 112.0.0.0b3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The VMWare driver in OpenStack Compute (Nova) before 2014.1.3 allows remote authenticated users to bypass the quota limit and cause a denial of service (resource consumption) by putting the VM into the rescue state, suspending it, which puts into an ERROR state, and then deleting the image. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-2573.
Recommended action: Upgrade to 2014.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (nova) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) does not properly delete instances from compute nodes, which allows remote authenticated users to cause a denial of service (disk consumption) by deleting instances while in the resize state.
Recommended action: Upgrade to 2015.1.2 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 volumeutils.parsevolumeinfo function in OpenStack Compute (Nova) before 2015.1.3 (kilo) and 12.0.x before 12.0.1 (liberty) includes the connectioninfo dictionary in the StorageError message when using the Xen backend, which might allow attackers to obtain sensitive password information by reading log files or other unspecified vectors.
Recommended action: Upgrade to 12.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (Nova) Grizzly 2013.1.4, Havana 2013.2.1, and earlier uses world-writable and world-readable permissions for the temporary directory used to store live snapshots, which allows local users to read and modify live snapshots.
Recommended action: Upgrade to 12.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.
OpenStack Compute (Nova) before 2014.2.4 (juno) and 2015.1.x before 2015.1.2 (kilo) do not properly apply security group changes, which allows remote attackers to bypass intended restriction by leveraging an instance that was running when the change was made.
Recommended action: Upgrade to 2015.1.2 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.
OpenStack Compute (Nova) before 2014.1.4 and 2014.2.x before 2014.2.1 allows remote authenticated users to cause a denial of service (CPU consumption) via an IP filter in a list active servers API request.
Recommended action: Upgrade to 2014.2.1 or 2014.1.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 libvirt driver in OpenStack Compute (Nova) before 2013.2.2 and icehouse before icehouse-2 allows remote authenticated users to cause a denial of service (disk consumption) by creating and deleting instances with unique ostype settings, which triggers the creation of a new ephemeral disk backing file.
Recommended action: Upgrade to 12.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.
The libvirt driver in OpenStack Compute (Nova) before 2015.1.4 (kilo) and 12.0.x before 12.0.3 (liberty), when using raw storage and usecowimages is set to false, allows remote authenticated users to read arbitrary files via a crafted qcow2 header in an ephemeral or root disk.
Recommended action: Upgrade to 12.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The VMware driver in OpenStack Compute (Nova) before 2014.1.4 allows remote authenticated users to cause a denial of service (disk consumption) by deleting an instance in the resize state.
Recommended action: Upgrade to 12.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.
PyPI nova >= 15.0.0, < 15.1.1; >= 16.0.0, < 16.1.2
Fixed in
15.1.116.1.2· Vendor fix available
Issue
An issue was discovered in OpenStack Nova 15.x through 15.1.0 and 16.x through 16.1.1. By detaching and reattaching an encrypted volume, an attacker may access the underlying raw volume and corrupt the LUKS header, resulting in a denial of service attack on the compute host. (The same code error also results in data loss, but that is not a vulnerability because the user loses their own data.) All Nova setups supporting encrypted volumes are affected.
Recommended action: Upgrade to 16.1.2 or 15.1.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 the default FilterScheduler in OpenStack Nova 16.0.3. By repeatedly rebuilding an instance with new images, an authenticated user may consume untracked resources on a hypervisor host leading to a denial of service, aka doubled resource allocations. This regression was introduced with the fix for OSSA-2017-005 (CVE-2017-16239); however, only Nova stable/pike or later deployments with that fix applied and relying on the default FilterScheduler are affected.
Recommended action: Upgrade to 16.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenStack Nova through 14.0.9, 15.x through 15.0.7, and 16.x through 16.0.2, by rebuilding an instance, an authenticated user may be able to circumvent the Filter Scheduler bypassing imposed filters (for example, the ImagePropertiesFilter or the IsolatedHostsFilter). All setups using Nova Filter Scheduler are affected. Because of the regression described in Launchpad Bug #1732947, the preferred fix is a 14.x version after 14.0.10, a 15.x version after 15.0.8, or a 16.x version after 16.0.3.
Recommended action: Upgrade to 16.0.3, 15.0.8 or 14.0.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Compute (Nova) Grizzly, Folsom (2012.2), and Essex (2012.1) allows remote authenticated users to gain access to a VM in opportunistic circumstances by using the VNC token for a deleted VM that was bound to the same VNC port.
Recommended action: Upgrade to 12.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.
OpenStack Nova before 2012.1 allows someone with access to an EC2ACCESSKEY (equivalent to a username) to obtain the EC2SECRETKEY (equivalent to a password). Exposing the EC2ACCESSKEY via http or tools that allow man-in-the-middle over https could allow an attacker to easily obtain the EC2SECRETKEY. An attacker could also presumably brute force values for EC2ACCESSKEY.
Recommended action: Upgrade to 12.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.
Versions of nova before 2012.1 could expose hypervisor host files to a guest operating system when processing a maliciously constructed qcow filesystem.
Recommended action: Upgrade to 12.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.