Database/Container, Kubernetes & orchestration
Red Hat Cluster Observability Operator (MonitoringStack ServiceAccount RBAC): The operator binds a ClusterRole to the
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
- Traefik: Path matcher flaw in PathPrefix/Path/PathRegex routing enables route and authorization bypassCVE-2025-32431 · TraefikHigh
- HyperShift operator: unvalidated tenant kubeconfig secrets yield code execution in the hosted control plane namespaceCVE-2026-101919 · Red Hat HyperShift operator (Multicluster Engine for Kubernetes) - kubeconfig secret handlingHigh
- Camel Karavan: any authenticated user can apply arbitrary Kubernetes resources, including privileged podsCVE-2026-103413 · Apache Camel Karavan (deployment path applying project kubernetes.yaml)High
- insights-runtime-extractor: incomplete privilege drop lets any pod get host root via its own argv[0]CVE-2026-104795 · Red Hat insights-runtime-extractor (privileged DaemonSet on OpenShift)High
- ingress-nginx: Config injection via the auth-method annotationCVE-2026-1580 · ingress-nginxHigh
- Kata Containers: Malformed or layer-less container image breaks Kata's handlingCVE-2026-24054 · Kata ContainersHigh
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.