Younaman

**Name of the Vulnerable Software and Affected Versions** External Secrets Operator versions prior to 0.10.2 **Description** The External Secrets Operator is a Kubernetes operator that integrates external secret management systems. It has a deployment called default-external-secrets-cert-controller, which is bound with a same-name ClusterRole. This ClusterRole has "get/list" verbs of secrets resources and path/update verb of validatingwebhookconfigurations resources. This can be used to abuse the SA token of the deployment to retrieve or get all secrets in the whole cluster, capture and log all data from requests attempting to update Secrets, or make a webhook deny all Pod create and update requests. **Recommendations** For versions prior to 0.10.2, update to version 0.10.2 to address this vulnerability. As a temporary workaround, consider restricting access to the `default-external-secrets-cert-controller` deployment and the associated ClusterRole to minimize the risk of exploitation. Avoid using the `get/list` verbs of secrets resources and the `path/update` verb of validatingwebhookconfigurations resources in the affected ClusterRole until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Hwameistor versions prior to 0.14.6 **Description** Hwameistor is a high-availability local storage system for cloud-native stateful workloads. This ClusterRole has excessive permissions, allowing a malicious user who can access the worker node with Hwameistor's deployment to abuse these permissions and perform any actions on the whole cluster, resulting in a cluster-level privilege escalation. **Recommendations** For versions prior to 0.14.6, upgrade to version 0.14.6 or later. For users unable to upgrade, update and limit the ClusterRole using security-role as a temporary workaround.

**Name of the Vulnerable Software and Affected Versions** Kanister (affected versions not specified) **Description** Kanister is a data protection workflow management tool. The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding. The "edit" ClusterRole is one of Kubernetes default-created ClusterRole, and it has the create/patch/update verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. A malicious user can leverage access to the worker node which has this component to make a cluster-level privilege escalation. This can be achieved by abusing the create/patch/update verbs of daemonset resources to create or modify a set of Pods to mount a high-privilege service account, or by using the create verb of serviceaccount/token resources to generate new Service Account tokens and operate with high-privilege roles. Additionally, the impersonate verb of serviceaccounts resources can be used to impersonate high-privilege Service Accounts, thereby gaining access to roles such as cluster administrators. **Recommendations** To mitigate this issue, set the `rbac.create` flag to `false` in the kanister helm chart, which controls whether the rbac rules for the kanister service account will be created. This will require the user to create rbac rules themselves and limit the role bindings for the kanister service account, for example, scope it to a specific namespace. The service account can also be configured via helm to restrict its privileges. As a temporary workaround, consider restricting access to the `default-kanister-operator` deployment and the `edit` ClusterRole to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Kubean versions prior to 0.18.0 **Description** The issue concerns a cluster lifecycle management toolchain where the ClusterRole has excessive permissions, allowing a malicious user to abuse these permissions and perform any action on the whole cluster, resulting in a cluster-level privilege escalation. This can occur if the malicious user gains access to the worker node with Kubean's deployment. **Recommendations** For versions prior to 0.18.0, upgrade to release version 0.18.0 or later to address the issue. At the moment, there is no information about other workarounds for this issue.

**Name of the Vulnerable Software and Affected Versions** Clusternet versions prior to 0.15.2 **Description** Clusternet is a general-purpose system for controlling Kubernetes clusters across different environments. An issue in Clusternet can be leveraged to lead to a cluster-level privilege escalation. The Clusternet has a deployment called `cluster-hub` inside the `clusternet-system` Kubernetes namespace, which runs on worker nodes randomly. The deployment has a service account called `clusternet-hub`, which has a cluster role called `clusternet:hub` via cluster role binding. The `clusternet:hub` cluster role has `"*"` verbs of `"*.*"` resources. Thus, if a malicious user can access the worker node which runs the Clusternet, they can leverage the service account to do malicious actions to critical system resources. For example, the malicious user can leverage the service account to get ALL secrets in the entire cluster, resulting in cluster-level privilege escalation. **Recommendations** To resolve the issue, update to version 0.15.2 or later. As a temporary workaround, consider restricting access to the `clusternet-hub` service account to minimize the risk of exploitation. Restrict access to the `cluster-hub` deployment and the `clusternet-system` Kubernetes namespace to prevent malicious users from leveraging the service account. Avoid using the `clusternet:hub` cluster role until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** OpenFeature Operator versions prior to 0.2.32 **Description** The issue allows an attacker to escalate the privileges of any service account in the cluster, assuming the pre-existence of a vulnerability that enables arbitrary code execution. This could lead to modification of cluster state, resulting in Denial of Service (DoS), or reading sensitive data, including secrets. The lax permissions configured on `open-feature-operator-controller-manager` are leveraged to achieve this escalation. **Recommendations** For versions prior to 0.2.32, update to version 0.2.32 to mitigate the issue by restricting the resources the `open-feature-operator-controller-manager` can modify. As a temporary workaround, consider restricting the permissions of the `open-feature-operator-controller-manager` to minimize the risk of exploitation.