CVE-2026-93017: Insights-operator: gather serviceaccount has cluster-wide secret read plus nodes/proxy and cluster-reader
FIND-001 from Project Glasswing AI-SAST audit of openshift/insights-operator (audit date 2026-06-09, commit unknown). The insights-operator-gather ClusterRole, bound to ServiceAccount openshift-insights, grants cluster-wide get/list on secrets and nodes/proxy. While the operator gathers diagnostic data from the cluster, access to all secrets cluster-wide exceeds what is needed for telemetry collection.
Other sources
The insights-operator-gather ClusterRole grants the operator's service account read access to secrets in the core API group with no namespace or resourceNames restriction — therefore, access to every secret in every namespace in the cluster.
Ref: https://github.com/openshift/insights-operator/blob/8f15e3157ff09f54ab22801f5b21da35a195cc6d/manifests/03-clusterrole.yaml#L368-L373 - apiGroups: - "" resources: - secrets verbs: - get - list
By spawning a pod with the gather service account mounted, an attacker will be able to access any secret in any namespace.
spec: serviceAccountName:"gather"
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Limit the insights-operator-gather ClusterRole's access to core API secrets; it currently grants cluster-wide get/list with no namespace or resourceNames restriction.
insights-operator-gather ClusterRole Secret RBAC permissions = Remove cluster-wide get/list access to secrets or restrict it by namespace/resourceNames
Event History
Frequently Asked Questions
What level of access would an attacker need to exploit this?
The attacker would need privileges sufficient to spawn a pod that uses the gather service account. The issue does not require user interaction, but it is not described as unauthenticated access.
What could an attacker access after obtaining the gather service account token?
A pod running with the gather service account can read secrets in every namespace because the associated ClusterRole permits get and list on secrets without namespace or resourceNames restrictions. The role also includes access to nodes/proxy.
How can I check whether my cluster has this exposure?
Inspect the insights-operator-gather ClusterRole for core API group secrets permissions with get and list verbs, and verify its binding to the openshift-insights service account. Also determine whether untrusted or insufficiently restricted workloads can be created with the gather service account.