GPU VulnDB

Database/Container, Kubernetes & orchestration

Red Hat Cluster Observability Operator (MonitoringStack ServiceAccount RBAC): The operator binds a ClusterRole to the

CVSS 8.8CVE-2025-2843Container, Kubernetes & orchestrationcurated

Impact

The operator binds a ClusterRole to the ServiceAccount it creates for a namespace-scoped MonitoringStack custom resource. A tenant who only holds rights inside one namespace can create a MonitoringStack there, then impersonate (or use the token of) the resulting ServiceAccount and act at cluster scope. On a shared GPU cluster that collapses the boundary between tenants: cluster-wide read of secrets and workloads, and the ability to schedule or mutate pods on any node, which on GPU fleets means reaching other tenants' accelerators and their model and dataset mounts. No node-level maintenance is needed to exploit it, and the escalation leaves only ordinary operator activity in the audit trail.

Who can reach it

An authenticated Kubernetes principal with only namespace-level rights in a namespace where MonitoringStack resources may be created - that is, any tenant given a namespace on a cluster running the operator. No cluster-level credentials and no node access required.

What to do

Update the Cluster Observability Operator to the fixed release shipped in RHSA-2025:21146 (fixed in Cluster Observability Operator after 1.3.1). This is an operator deployment rollout - the operator pod and the monitoring stacks it manages restart; no node drain or reboot is involved. Until updated, restrict who may create MonitoringStack resources in tenant namespaces and review existing ServiceAccounts and ClusterRoleBindings the operator has already created.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.