CVE-2026-77968

hawtio-operator ships with a ClusterRole that grants create, get, list, update, and watch permissions on Secret objects across all namespaces, while the operator itself only consumes a filtered subset via a controller-runtime label-selector cache used as a memory optimization. The operator's ServiceAccount token is nonetheless authorized to read every Secret in the cluster regardless of that cache, and the operator also makes direct API calls that bypass it entirely. An attacker who compromises the operator pod, or otherwise obtains its ServiceAccount token, can read all Secrets cluster-wide, including bootstrap tokens, cloud provider credentials, and other operators' secrets, and can also create or modify Secrets because write permissions are granted as well. Any Kubernetes or OpenShift cluster running hawtio-operator is affected; the issue was assigned by Red Hat's CNA, and no affected or fixed version ranges were provided in the available data. There are no reports of exploitation in the wild, no public proof-of-concept, and EPSS estimates only a 0.2% probability of exploitation within 30 days.

What to do: Check the Red Hat security advisory for a fixed hawtio-operator release and upgrade when available, since no fixed version was specified in this data. As an interim mitigation, scope the operator's ClusterRole to the specific namespaces or Secret label selectors it actually uses, or run the operator with a least-privilege ServiceAccount. If you suspect the operator pod was compromised, audit cluster Secrets, prioritizing bootstrap tokens and cloud provider credentials for rotation.