| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in PackStack. This vulnerability allows a local user to modify deployed systems by changing the answer file, which is created in insecure directories such as /tmp or the current working directory. This insecure file creation could lead to unauthorized system modifications. |
| 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). |
| A flaw was found in PackStack. A local user could exploit a symlink attack on a temporary file with a predictable name in the `/tmp` directory. This vulnerability allows the local user to overwrite arbitrary files on the system, potentially leading to system compromise or data corruption. |
| A flaw was found in the `puppetlabs-cinder` module, as used in PackStack. This vulnerability is due to incorrect file permissions, specifically world-readable permissions, on the `cinder.conf` and `api-paste.ini` configuration files. A local user can exploit this by reading these files, which leads to the disclosure of OpenStack administrative passwords. This information disclosure could allow unauthorized access to sensitive OpenStack resources. |
| A flaw was found in OpenStack Keystone. This vulnerability allows remote authenticated users to bypass intended authorization restrictions. This occurs because OpenStack Keystone does not properly handle EC2 (Elastic Compute Cloud) tokens when a user's role has been removed from a tenant. An attacker can leverage a token associated with a removed user role to gain unauthorized access. |
| A flaw was found in Ansible Operator Plugins. A low-privileged Kubernetes user can exploit a Jinja2 template injection vulnerability by crafting malicious custom resource (CR) specification values. These values are processed by Ansible without proper sanitization, allowing embedded Jinja2 expressions to be executed within the operator pod. This can lead to arbitrary code execution and privilege escalation, granting the attacker control over the operator's service account with cluster-wide permissions. |
| A flaw was found in openstack-network-exporter. The HTTP server within the component is configured without essential timeout settings, such as ReadHeaderTimeout. This vulnerability allows an unauthenticated, remote attacker to initiate multiple slow HTTP header connections. By trickling header bytes, the attacker can exhaust server resources, specifically file descriptors, leading to a Denial of Service (DoS) that prevents legitimate Prometheus metric scraping and alerting. |
| A flaw was found in openstack-network-exporter. When an operator configures user authentication but omits or misconfigures Transport Layer Security (TLS), the basic authentication mechanism is silently bypassed. This fail-open design allows an adjacent network attacker to access sensitive Open vSwitch (OVS) and Open Virtual Network (OVN) dataplane metrics without credentials. Consequently, an attacker can enumerate bridge names, port counters, OVN controller state, and host topology, leading to information disclosure. |
| A flaw was found in the Open Virtual Network (OVN). In OVN clusters where BFD is used between hypervisors for high availability, an attacker can inject specially crafted BFD packets from inside unprivileged workloads, including virtual machines or containers, that can trigger a denial of service. |
| A flaw was found in the OCAPI modules (ocapi_command, ocapi_info) of the
community.general Ansible collection. The shared OCAPI request helper disables
TLS certificate validation on every request and the modules expose no parameter
to re-enable it, while sending HTTP Basic-Auth credentials to an https endpoint.
An attacker positioned on the network path between the Ansible controller and the
OCAPI-managed storage/enclosure device can present any certificate, intercept the
session, capture the credentials, and tamper with responses. |
| A flaw was found in the memcached cache plugin of the community.general Ansible
collection. Although its documentation states that records are stored in JSON
format, the plugin performs no explicit serialization and relies on
python-memcached, which pickles values on write and unpickles them on read.
Because memcached is unauthenticated and cache keys are predictable, an attacker
able to reach a network-exposed or shared memcached instance can write a crafted
pickle payload that is deserialized and executed on the Ansible controller when
the poisoned fact cache is next read, leading to remote code execution. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: algif_aead - Revert to operating out-of-place
This mostly reverts commit 72548b093ee3 except for the copying of
the associated data.
There is no benefit in operating in-place in algif_aead since the
source and destination come from different mappings. Get rid of
all the complexity added for in-place operation and just copy the
AD directly. |
| A flaw was found in the ipa_getkeytab module of the community.general
Ansible collection. The module's bind_pw parameter, used to supply the LDAP simple-bind password when retrieving a Kerberos keytab, is not declared with no_log, unlike the sibling password parameter in the same module. As a consequence, the supplied IPA/LDAP bind password is recorded in cleartext in the managed host's system journal/syslog (the module's "Invoked with" record), is included in the module's return values and verbose (-v) output, and is displayed in Automation Controller / AWX job output. The password is additionally passed on the command line to the ipa-getkeytab helper (as --bindpw <value>), exposing it in the process list to local users while the command runs. An attacker able to read these logs, job output, or the process table can obtain the directory bind credential, potentially compromising the accounts and objects that credential can access. |
| The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| 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. |
| A flaw was found in OpenStack Keystone. A remote attacker could exploit this vulnerability by sending a large HTTP request, specifically by providing a long tenant name when requesting a token. This could lead to a denial of service, consuming excessive CPU and memory resources on the affected system. |
| OpenStack Mistral through 22.0.0 allows Arbitrary Remote Code Execution when the API is exposed. There are endpoints that allow code execution, which can lead to exfiltration of service credentials. |
| Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4. |
| Microarchitectural Fill Buffer Data Sampling (MFBDS): Fill buffers on some microprocessors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access. A list of impacted products can be found here: https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf |
| Microarchitectural Load Port Data Sampling (MLPDS): Load ports on some microprocessors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access. A list of impacted products can be found here: https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf |
