Red Hat OpenShift EUVD-2026-95030

Exploitation requires an authenticated foothold able to create or influence a pod specification in at least one namespace (RBAC permission to create pods, or control over a workload manifest) AND the ability to set 'serviceAccountName: gather' on that pod; the vulnerable insights-operator-gather ClusterRole is present by default in OpenShift Container Platform 4 installs. The limiting factor is the pod-create/service-account-binding privilege (reflected as PR:L) - an attacker with no cluster access cannot trigger this, so it functions as a privilege-escalation primitive rather than remote-unauthenticated compromise. There is no user-interaction requirement and no reliance on a non-default feature flag; the over-broad grant exists out of the box.

This is a privilege-escalation flaw (CWE-269) in the insights-operator shipped by default with Red Hat OpenShift Container Platform 4, where the insights-operator-gather ClusterRole grants the 'gather' service account cluster-wide get/list on core-group secrets with no namespace or resourceNames scoping. The CVSS 7.7 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) is internally consistent with the description: PR:L reflects that an attacker must already hold some authenticated foothold able to schedule a pod, S:C reflects the scope break (reading secrets belonging to every other namespace/workload), and C:H/I:N/A:N correctly captures pure confidentiality impact with no integrity or availability loss. No EPSS score, CISA KEV listing, SSVC decision, or public POC was supplied in the input; per precision rules this is therefore 'no public exploit identified at time of analysis.' The realistic priority is driven less by raw CVSS than by the pre-condition: an attacker needs the ability to create a pod and bind it to the gather service account, so this is primarily a privilege-escalation lateral-movement amplifier for an actor who already has a namespace foothold rather than a remote-unauthenticated mass-exploitation bug. The AV:N label should be read in Kubernetes terms (the API server is network-reachable) and does NOT imply unauthenticated internet exposure - verify RBAC exposure against your own cluster's pod-creation permissions. One caveat: the input provides no EPSS/KEV/POC signals at all, so exploitation-likelihood scoring is inferred solely from the CVSS vector and description.

An attacker who has obtained the ability to create or control pod specifications in any namespace of an affected OpenShift 4 cluster (e.g., a compromised CI pipeline, a tenant with namespace-level pod-create rights, or a low-privileged account after initial access) schedules a pod with 'serviceAccountName: gather'. Because the mounted gather service account inherits cluster-wide secret read access, the pod can then enumerate and read every secret in every namespace - including other tenants' credentials, TLS keys, and tokens. No public exploit code is referenced in the input, but the technique is trivially reproducible from the manifest shown.