CVE-2026-107176 in OpenShift Container Platform
Summary
by MITRE • 10/07/2026
A flaw was found in the cluster-samples-operator. The RBAC Role coreos-pull-secret-reader in namespace openshift-config grants get, list, and watch permissions on all Secret resources without resourceNames scoping. The operator only requires access to the pull-secret Secret. If the samples-operator pod or its service account token is compromised through a separate vulnerability, an attacker could read all secrets in openshift-config, potentially including OAuth identity provider credentials, cloud provider credentials, and other sensitive cluster configuration.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The identified vulnerability resides within the cluster-samples-operator component of OpenShift clusters, specifically affecting the RBAC Role named coreos-pull-secret-reader located in the openshift-config namespace. This role is configured with overly permissive access controls that grant get, list, and watch permissions on all Secret resources without any resourceNames scoping to restrict access to specific objects. While the operational intent of this operator is strictly limited to accessing a single designated pull-secret for image registry authentication purposes, the current configuration effectively provides unrestricted read access to every secret stored within the openshift-config namespace. This discrepancy between required privileges and granted permissions represents a classic case of excessive privilege assignment that violates the principle of least privilege.
The technical flaw allows any entity with access to the service account token associated with this role or compromised pod running under its context to enumerate and retrieve all secrets in the target namespace. In an OpenShift environment, the openshift-config namespace houses critical cluster configuration data including OAuth identity provider credentials, cloud provider authentication tokens, webhook secret keys, and other sensitive operational parameters. An attacker who exploits a separate vulnerability to compromise the samples-operator pod or steal its service account token can leverage this excessive RBAC permission set to exfiltrate these high-value secrets. This capability significantly lowers the barrier for lateral movement within the cluster environment, as access to identity provider credentials often facilitates authentication bypasses and further privilege escalation attacks against administrative accounts.
From an operational impact perspective, this vulnerability poses a severe risk to cluster security posture by enabling potential data breaches of sensitive configuration details. The exposure of OAuth identity provider secrets could allow attackers to impersonate legitimate users or administrators if those secrets are used for signing tokens or verifying signatures. Similarly, the disclosure of cloud provider credentials might enable unauthorized provisioning of resources in connected infrastructure environments, leading to financial loss and further compromise of external systems. Additionally, access to webhook secrets could permit manipulation of admission controllers or other automated workflows that rely on these cryptographic keys for integrity verification. The cumulative effect is a substantial increase in attack surface area where a single point of failure can lead to widespread credential theft across multiple security domains within the cluster architecture.
To mitigate this vulnerability, it is imperative to update the RBAC Role definition to scope access strictly to the specific pull-secret resource required by the operator rather than granting blanket permissions on all secret resources. This involves modifying the role binding or role itself to include a fieldNames restriction targeting only the name of the intended pull-secret object. Regular auditing of RBAC policies should be implemented to ensure that service accounts do not accumulate excessive privileges over time through various operators and applications. Furthermore, implementing network policies to restrict pod-to-pod communication can limit the blast radius if an operator container is compromised. Monitoring tools should also be configured to detect unusual access patterns to secrets in critical namespaces such as openshift-config, providing early warning indicators of potential exploitation attempts aligned with techniques described in MITRE ATT&CK for credential dumping and unauthorized API access within Kubernetes environments.