| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenStack Image Registry and Delivery Service (Glance) before 2013.2.4, 2014.x before 2014.1.3, and Juno before Juno-3, when using the V2 API, does not properly enforce the image_size_cap configuration option, which allows remote authenticated users to cause a denial of service (disk consumption) by uploading a large image. |
| OpenStack Object Storage (Swift) before 2.3.0, when allow_version is configured, allows remote authenticated users to delete the latest version of an object by leveraging listing access to the x-versions-location container. |
| OpenStack Object Storage (Swift) before 2.4.0 allows attackers to obtain sensitive information via a PUT tempurl and a DLO object manifest that references an object in another container. |
| OpenStack Murano before 1.0.3 (liberty) and 2.x before 2.0.1 (mitaka), Murano-dashboard before 1.0.3 (liberty) and 2.x before 2.0.1 (mitaka), and python-muranoclient before 0.7.3 (liberty) and 0.8.x before 0.8.5 (mitaka) improperly use loaders inherited from yaml.Loader when parsing MuranoPL and UI files, which allows remote attackers to create arbitrary Python objects and execute arbitrary code via crafted extended YAML tags in UI definitions in packages. |
| 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. |
| 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 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. |
| OpenStack Glance 2014.2.x through 2014.2.1, 2014.1.3, and earlier allows remote authenticated users to bypass the storage quota and cause a denial of service (disk consumption) by deleting an image in the saving state. |
| The TripleO Heat templates (tripleo-heat-templates) do not properly order the Identity Service (keystone) before the OpenStack Object Storage (Swift) staticweb middleware in the swiftproxy pipeline when the staticweb middleware is enabled, which might allow remote attackers to obtain sensitive information from private containers via unspecified vectors. |
| The TripleO Heat templates (tripleo-heat-templates), when deployed via the commandline interface, allow remote attackers to spoof OpenStack Networking metadata requests by leveraging knowledge of the default value of the NeutronMetadataProxySharedSecret parameter. |
| The boot-from-volume feature in OpenStack Compute (Nova) Folsom and Essex, when using nova-volumes, allows remote authenticated users to boot from other users' volumes via a volume id in the block_device_mapping parameter. |
| python-keystoneclient before 0.2.4, as used in OpenStack Keystone (Folsom), does not properly check expiry for PKI tokens, which allows remote authenticated users to (1) retain use of a token after it has expired, or (2) use a revoked token once it expires. |
| The user-password-update command in python-keystoneclient before 0.2.4 accepts the new password in the --password argument, which allows local users to obtain sensitive information by listing the process. |
| The ReST API in OpenStack Orchestration API (Heat) before Havana 2013.2.1 and Icehouse before icehouse-2 allows remote authenticated users to bypass the tenant scoping restrictions via a modified tenant_id in the request path. |
| The python-qpid client (common/rpc/impl_qpid.py) in OpenStack Oslo before 2013.2 does not enforce SSL connections when qpid_protocol is set to ssl, which allows remote attackers to obtain sensitive information by sniffing the network. |
| The cloudformation-compatible API in OpenStack Orchestration API (Heat) before Havana 2013.2.1 and Icehouse before icehouse-2 does not properly enforce policy rules, which allows local in-instance users to bypass intended access restrictions and (1) create a stack via the CreateStack method or (2) update a stack via the UpdateStack method. |
| The XML libraries for Python 3.4, 3.3, 3.2, 3.1, 2.7, and 2.6, as used in OpenStack Keystone Essex, Folsom, and Grizzly; Compute (Nova) Essex and Folsom; Cinder Folsom; Django; and possibly other products allow remote attackers to cause a denial of service (resource consumption and crash) via an XML Entity Expansion (XEE) attack. |
| OpenStack Keystone, as used in OpenStack Folsom 2012.2, does not properly implement token expiration, which allows remote authenticated users to bypass intended authorization restrictions by creating new tokens through token chaining. NOTE: this issue exists because of a CVE-2012-3426 regression. |
| Interaction error in OpenStack Nova and Neutron before Havana 2013.2.1 and icehouse-1 does not validate the instance ID of the tenant making a request, which allows remote tenants to obtain sensitive metadata by spoofing the device ID that is bound to a port, which is not properly handled by (1) api/metadata/handler.py in Nova and (2) the neutron-metadata-agent (agent/metadata/agent.py) in Neutron. |
| The ec2tokens API in OpenStack Identity (Keystone) before Havana 2013.2.1 and Icehouse before icehouse-2 does not return a trust-scoped token when one is received, which allows remote trust users to gain privileges by generating EC2 credentials from a trust-scoped token and using them in an ec2tokens API request. |
| The XenAPI backend in OpenStack Compute (Nova) Folsom, Grizzly, and Havana before 2013.2 does not properly apply security groups (1) when resizing an image or (2) during live migration, which allows remote attackers to bypass intended restrictions. |
