Vulnerabilities (CVE)

Filtered by vendor Openstack Subscribe
Filtered by product Folsom
Total 26 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2013-4497 1 Openstack 3 Folsom, Grizzly, Havana 2025-04-11 6.4 MEDIUM N/A
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.
CVE-2012-4573 1 Openstack 3 Essex, Folsom, Image Registry And Delivery Service \(glance\) 2025-04-11 5.5 MEDIUM N/A
The v1 API in OpenStack Glance Grizzly, Folsom (2012.2), and Essex (2012.1) allows remote authenticated users to delete arbitrary non-protected images via an image deletion request, a different vulnerability than CVE-2012-5482.
CVE-2013-0261 1 Openstack 2 Essex, Folsom 2025-04-11 4.4 MEDIUM N/A
(1) installer/basedefs.py and (2) modules/ospluginutils.py in PackStack allows local users to overwrite arbitrary files via a symlink attack on a temporary file with a predictable name in /tmp.
CVE-2013-1840 2 Amazon, Openstack 5 S3 Store, Essex, Folsom and 2 more 2025-04-11 3.5 LOW N/A
The v1 API in OpenStack Glance Essex (2012.1), Folsom (2012.2), and Grizzly, when using the single-tenant Swift or S3 store, reports the location field, which allows remote authenticated users to obtain the operator's backend credentials via a request for a cached image.
CVE-2012-5625 1 Openstack 2 Folsom, Grizzly 2025-04-11 4.3 MEDIUM N/A
OpenStack Compute (Nova) Folsom before 2012.2.2 and Grizzly, when using libvirt and LVM backed instances, does not properly clear physical volume (PV) content when reallocating for instances, which allows attackers to obtain sensitive information by reading the memory of the previous logical volume (LV).
CVE-2013-0208 2 Canonical, Openstack 3 Ubuntu Linux, Essex, Folsom 2025-04-11 6.5 MEDIUM N/A
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.