CWE-653
Improper Isolation or Compartmentalization
ClassDraft
Description
The product does not properly compartmentalize or isolate functionality, processes, or resources that require different privilege levels, rights, or permissions.
When a weakness occurs in functionality that is accessible by lower-privileged users, then without strong boundaries, an attack might extend the scope of the damage to higher-privileged users.
Hierarchy (View 1000)
CVEs mapped to this weakness (24)
page 2 of 2| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2025-27027 | Med | 0.27 | 4.1 | 0.00 | Jul 9, 2025 | A user with vpuser credentials that opens an SSH connection to the device, gets a restricted shell rbash that allows only a small list of allowed commands. This vulnerability enables the user to get a full-featured Linux shell, bypassing the rbash restrictions. | |
| CVE-2024-43803 | Med | 0.25 | 4.9 | 0.00 | Sep 3, 2024 | 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-2025-41116 | Low | 0.14 | — | 0.00 | Nov 11, 2025 | When using the Grafana Databricks Datasource Plugin, if Oauth passthrough is enabled on the datasource, and multiple users are using the same datasource at the same time on a single Grafana instance, it could result in the wrong user identifier being used, and information for which the viewer is not authorized being returned. This issue affects Grafana Databricks Datasource Plugin: from 1.6.0 before 1.12.0 | |
| CVE-2025-3717 | Low | 0.14 | — | 0.00 | Nov 11, 2025 | When using the Grafana Snowflake Datasource Plugin, if Oauth passthrough is enabled on the datasource, and multiple users are using the same datasource at the same time on a single Grafana instance, it could result in the wrong user identifier being used, and information for which the viewer is not authorized being returned. This issue affects Grafana Snowflake Datasource Plugin: from 1.5.0 before 1.14.1. |