Description

A flaw was found in hawtio-operator. The operator's ClusterRole grants secrets: [create, get, list, update, watch] across all namespaces. While the operator uses a controller-runtime label-selector cache as a memory optimization, the ServiceAccount token authorizes read access to every Secret in the cluster. The operator also bypasses the cache via direct API calls. Compromise of the operator pod would yield read access to every Secret in the cluster, including bootstrap tokens, cloud credentials, and other operators' secrets.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.2",
  "pubDate": "2026-09-08T12:16:59.427Z",
  "pubdate": "2026-09-08T12:16:59.427Z",
  "executiveSummary": "A privilege escalation vulnerability exists in the hawtio-operator where the assigned ClusterRole grants overly permissive access to Kubernetes Secrets across all namespaces.\nThe vulnerability allows for unauthorized access to sensitive data, including bootstrap tokens, cloud provider credentials, and inter-service authentication secrets.\nThe core issue is a violation of the principle of least privilege, as the controller possesses broad CRUD/read permissions on the core/v1/secrets resource type.\nIf the hawtio-operator pod is compromised, an attacker can leverage the mounted ServiceAccount token to perform unauthorized API calls to the Kubernetes API server, bypassing local cache mechanisms to extract highly sensitive cluster-wide information.\nThe risk implication is critical, as compromise of the operator effectively translates to a compromise of the entire Kubernetes cluster's credential management layer, potentially leading to full cluster takeover.\nExploitation requires initial access to the operator pod, which can be achieved through various vectors such as remote code execution in the application or other container-level vulnerabilities.",
  "technicalDetails": "The hawtio-operator is configured with a ClusterRole that defines explicit verbs [create, get, list, update, watch] on the resources: [secrets]. This binding is applied globally across all namespaces in the Kubernetes cluster.\nWhile the operator implements a controller-runtime label-selector cache intended to limit the scope of observed resources, the underlying ServiceAccount token remains authorized by the Kubernetes RBAC system to interact with all Secrets within the entire API surface.\nThe operator performs direct API calls that circumvent the local cache. By design, these direct requests are evaluated by the API server against the full scope of the ClusterRole. Because the RBAC definition does not restrict access to specific namespaces or resources, the API server permits the retrieval of any Secret.\nThe attack flow begins with an adversary achieving execution within the hawtio-operator pod environment. Once execution is obtained, the attacker extracts the mounted ServiceAccount token located at /var/run/secrets/kubernetes.io/serviceaccount/token.\nThe attacker utilizes the token to perform authenticated requests against the Kubernetes API server. By executing 'get' or 'list' operations on the secrets endpoint, the attacker bypasses any application-level security controls implemented by the operator. Because the operator runs with global ClusterRole privileges, the API server authorizes the retrieval of secrets belonging to other namespaces, including those belonging to system controllers, cloud integration agents, and other third-party operators.\nThe impact includes the exfiltration of sensitive material such as service account tokens for elevated identities, cloud provider secrets (e.g., AWS_ACCESS_KEY_ID), database credentials, and TLS certificates. This post-exploitation access allows an attacker to pivot, move laterally within the cluster, and escalate privileges to cluster-admin if the secrets contain sufficiently high-level service account tokens or administrator credentials."
}