CVE-2026-77968: Hawtio-operator: hawtio-operator: cluster-wide secrets read/write granted to operator serviceaccount
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.
Other sources
H-1 from Project Glasswing security audit of hawtio-operator. The ClusterRole grants secrets: [create, get, list, update, watch] across all namespaces. The controller-runtime label-selector cache is a memory optimisation only; the SA token authorises GET/LIST on every Secret. Compromise of the operator pod yields read of every Secret in the cluster. Source: hawtio-operator-security-audit.json#H-1.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is exposed to the cluster-wide Secret access?
Any cluster running the affected operator is exposed because its ServiceAccount token is authorized to read Secrets in every namespace. A compromise of the operator pod would give an attacker access to cluster-wide Secrets, including bootstrap tokens, cloud credentials, and other operators' Secrets.
Does the controller-runtime label-selector cache limit the operator's Secret permissions?
No. The label-selector cache is only a memory optimization and does not constrain the ServiceAccount's API authorization. The operator can also bypass the cache through direct API calls.
What access would an attacker need to exploit this issue?
An attacker would need to compromise the operator pod in order to use its ServiceAccount token. That token has cluster-wide Secret read access and also permits Secret creation and updates across namespaces.