Total
37 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2024-55456 | 1 Sammycage | 1 Lunasvg | 2025-04-15 | 6.5 Medium |
lunasvg v3.0.1 was discovered to contain a segmentation violation via the component gray_find_cell | ||||
CVE-2025-3086 | 2025-04-07 | N/A | ||
Improper isolation of users in M-Files Server version before 25.3.14549 allows anonymous user to affect other anonymous users views and possibly cause a denial of service | ||||
CVE-2025-29781 | 1 Redhat | 1 Openshift | 2025-03-18 | 6.5 Medium |
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace. | ||||
CVE-2025-26393 | 2025-03-18 | 5.4 Medium | ||
SolarWinds Service Desk is affected by a broken access control vulnerability. The issue allows authenticated users to escalate privileges, leading to unauthorized data manipulation. | ||||
CVE-2023-1305 | 1 Rapid7 | 2 Insightappsec, Insightcloudsec | 2025-02-26 | 8.1 High |
An authenticated attacker can leverage an exposed “box” object to read and write arbitrary files from disk, provided those files can be parsed as yaml or JSON. This issue was resolved in the Managed and SaaS deployments on February 1, 2023, and in version 23.2.1 of the Self-Managed version of InsightCloudSec. | ||||
CVE-2023-29580 | 1 Yasm Project | 1 Yasm | 2025-02-08 | 5.5 Medium |
yasm 1.3.0.55.g101bc was discovered to contain a segmentation violation via the component yasm_expr_create at /libyasm/expr.c. | ||||
CVE-2024-0135 | 1 Nvidia | 1 Container Toolkit | 2025-01-28 | 7.6 High |
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to modification of a host binary. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. | ||||
CVE-2024-0136 | 1 Nvidia | 1 Container Toolkit | 2025-01-28 | 7.6 High |
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code obtaining read and write access to host devices. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. | ||||
CVE-2024-0137 | 1 Nvidia | 1 Container Toolkit | 2025-01-28 | 5.5 Medium |
NVIDIA Container Toolkit contains an improper isolation vulnerability where a specially crafted container image could lead to untrusted code running in the host’s network namespace. This vulnerability is present only when the NVIDIA Container Toolkit is configured in a nondefault way. A successful exploit of this vulnerability may lead to denial of service and escalation of privileges. | ||||
CVE-2024-47520 | 2025-01-13 | 7.6 High | ||
A user with advanced report application access rights can perform actions for which they are not authorized | ||||
CVE-2024-10220 | 1 Kubernetes | 1 Kubelet | 2024-11-25 | 8.1 High |
The Kubernetes kubelet component allows arbitrary command execution via specially crafted gitRepo volumes.This issue affects kubelet: through 1.28.11, from 1.29.0 through 1.29.6, from 1.30.0 through 1.30.2. | ||||
CVE-2024-30388 | 1 Juniper Networks | 1 Junos Os | 2024-11-21 | 6.5 Medium |
An Improper Isolation or Compartmentalization vulnerability in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS on QFX5000 Series and EX Series allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS). If a specific malformed LACP packet is received by a QFX5000 Series, or an EX4400, EX4100 or EX4650 Series device, an LACP flap will occur resulting in traffic loss. This issue affects Junos OS on QFX5000 Series, and on EX4400, EX4100 or EX4650 Series: * 20.4 versions from 20.4R3-S4 before 20.4R3-S8, * 21.2 versions from 21.2R3-S2 before 21.2R3-S6, * 21.4 versions from 21.4R2 before 21.4R3-S4, * 22.1 versions from 22.1R2 before 22.1R3-S3, * 22.2 versions before 22.2R3-S1, * 22.3 versions before 22.3R2-S2, 22.3R3, * 22.4 versions before 22.4R2-S1, 22.4R3. | ||||
CVE-2023-1636 | 2 Openstack, Redhat | 3 Barbican, Openstack, Openstack Platform | 2024-11-21 | 6 Medium |
A vulnerability was found in OpenStack Barbican containers. This vulnerability is only applicable to deployments that utilize an all-in-one configuration. Barbican containers share the same CGROUP, USER, and NET namespace with the host system and other OpenStack services. If any service is compromised, it could gain access to the data transmitted to and from Barbican. | ||||
CVE-2024-49373 | 1 Nofusscomputing | 1 Centurion Erp | 2024-10-30 | 4.1 Medium |
No Fuss Computing Centurion ERP is open source enterprise resource planning (ERP) software. Prior to version 1.2.1, an authenticated user can view projects within organizations they are not apart of. Version 1.2.1 fixes the problem. | ||||
CVE-2024-20285 | 1 Cisco | 232 N9k-c92160yc-x, N9k-c92300yc, N9k-c92304qc and 229 more | 2024-10-22 | 5.3 Medium |
A vulnerability in the Python interpreter of Cisco NX-OS Software could allow an authenticated, low-privileged, local attacker to escape the Python sandbox and gain unauthorized access to the underlying operating system of the device. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by manipulating specific functions within the Python interpreter. A successful exploit could allow an attacker to escape the Python sandbox and execute arbitrary commands on the underlying operating system with the privileges of the authenticated user. Note: An attacker must be authenticated with Python execution privileges to exploit these vulnerabilities. For more information regarding Python execution privileges, see product-specific documentation, such as the section of the Cisco Nexus 9000 Series NX-OS Programmability Guide. | ||||
CVE-2024-43803 | 1 Redhat | 1 Openshift | 2024-09-03 | 4.9 Medium |
The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere). BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a `BareMetalHost`. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces. The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces. | ||||
CVE-2024-5801 | 2024-08-12 | N/A | ||
Enabled IP Forwarding feature in B&R Automation Runtime versions before 6.0.2 may allow remote attack-ers to compromise network security by routing IP-based packets through the host, potentially by-passing firewall, router, or NAC filtering. |