CVE-2026-10101
ACM/MCE pull-secret exposure via InfraEnv status conditions
Publication date: 2026-05-29
Last updated on: 2026-05-29
Assigner: Red Hat, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| redhat | openshift | * |
| redhat | assisted-service | From 2026-05-29 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-201 | The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-10101 is a security vulnerability in the assisted-service component of ACM/MCE where sensitive pull-secret data is unintentionally exposed. When pull-secret validation fails, the raw contents of the referenced pull-secret are written into the InfraEnv object's status conditions message field. This allows a user with only the default 'view' ClusterRole, which normally cannot read Secrets directly, to access sensitive pull-secret information such as usernames, passwords, emails, and base64-encoded authentication data by reading the InfraEnv status.
This vulnerability effectively bypasses the Kubernetes/OpenShift Role-Based Access Control (RBAC) separation between users who can view namespace resources and those who can read Secrets, enabling unauthorized access to secret credentials.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of sensitive credentials stored in pull-secrets, such as usernames, passwords, and authentication tokens. An attacker or unauthorized user with only read access to InfraEnv objects but no direct permission to read Secrets can recover these credentials.
Such exposure can compromise the security of container registries or other services relying on these pull-secrets, potentially leading to unauthorized access, data breaches, or further exploitation within the affected Kubernetes or OpenShift environment.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows unauthorized users with only the default 'view' ClusterRole to access sensitive pull-secret data, including usernames, passwords, emails, and authentication tokens, by bypassing Kubernetes/OpenShift RBAC restrictions.
Such unauthorized access to sensitive authentication credentials could lead to data breaches or unauthorized system access, which may violate compliance requirements under standards like GDPR and HIPAA that mandate strict controls over access to sensitive information.
Therefore, this vulnerability potentially undermines compliance with these regulations by exposing sensitive secrets to users who should not have access, increasing the risk of data exposure and non-compliance.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by inspecting the `InfraEnv.status.conditions[].message` fields in your Kubernetes/OpenShift cluster to see if they contain raw pull-secret contents, especially after pull-secret validation failures.
Since a user with the `view` ClusterRole can read `InfraEnv` objects but not Secrets, you can attempt to retrieve the `InfraEnv` objects and check their status messages for leaked secret data.
- Use kubectl or oc commands to list InfraEnv objects and describe their status conditions, for example:
- `kubectl get infraenv -n <namespace>`
- `kubectl describe infraenv <infraenv-name> -n <namespace>`
- Look specifically at the `status.conditions[].message` fields for any raw pull-secret data such as `.dockerconfigjson` contents.