A flaw was found in the Observability Operator. The Operator creates a ServiceAccount with *ClusterRole* upon deployment of the *Namespace-Scoped* Custom Resource MonitorStack. This issue allows an adversarial Kubernetes Account with only namespaced-level roles, for example, a tenant controlling a namespace, to create a MonitorStack in the authorized namespace and then elevate permission to the cluster level by impersonating the ServiceAccount created by the Operator, resulting in privilege escalation and other issues.
Security readout for executives and security teams
Plain-English summary
CVE-2025-2843 is a high-severity privilege escalation in Red Hat’s Cluster Observability Operator. A namespace-level Kubernetes user could trigger creation of a service account with cluster-wide permissions, then use it to gain broader control. This is most urgent for multi-tenant OpenShift or Kubernetes environments where teams or tenants can create MonitorStack resources.
Executive priority
Prioritize remediation for multi-tenant clusters and environments with delegated namespace administration. The business risk is unauthorized cluster-wide access from a lower-privileged tenant account, potentially affecting confidentiality, integrity, and availability across workloads.
Technical view
The Observability Operator creates a ServiceAccount with ClusterRole permissions when a namespace-scoped MonitorStack custom resource is deployed. A user with namespaced privileges can create that resource in an authorized namespace and impersonate the operator-created ServiceAccount, escalating from namespace scope to cluster-level permissions. CVSS is 8.8, AV:N/AC:L/PR:L/UI:N, with high confidentiality, integrity, and availability impact.
Likely exposure
Exposure is likely limited to environments running the affected Red Hat Cluster Observability Operator package/version and allowing non-admin namespace users to create namespace-scoped MonitorStack resources. Single-tenant clusters or clusters without this operator are less likely exposed based on the provided sources.
Exploitation context
Sources describe a low-complexity, authenticated privilege escalation requiring existing namespaced Kubernetes permissions. The source bundle does not indicate public exploitation, proof-of-concept availability, or inclusion in CISA KEV. Treat risk as serious in shared clusters because the escalation crosses namespace boundaries.
Researcher notes
Evidence comes from Red Hat/CVE records. The flaw is CWE-266 privilege management. The bundle names one affected Red Hat package/version and a rhobs observability-operator entry with default status unaffected. Details on fixed versions, exploit artifacts, and real-world exploitation are not present in the supplied data.
Mitigation direction
Review RHSA-2025:21146 and apply the Red Hat-provided update or remediation.
Restrict who can create MonitorStack resources until the fix is applied.
Review RBAC allowing impersonation of operator-created ServiceAccounts.
Limit tenant permissions in namespaces hosting observability resources.
Monitor Red Hat CVE and Bugzilla pages for updated guidance.
Validation and detection
Identify clusters running Red Hat Cluster Observability Operator 1.3.0 affected builds.
Check whether namespace-scoped MonitorStack resources are enabled or delegated to tenants.
Review RBAC bindings for ClusterRole grants created by the operator.
Confirm the installed operator version matches Red Hat’s fixed advisory guidance.
Audit recent creation of MonitorStack resources by non-cluster-admin users.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-266: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
5Timeline events
1ADP providers
4Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-266 · source CWE mapping
Incorrect Privilege Assignment
Incorrect Privilege Assignment represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.