CVE-2026-10101: ACM/MCE Pull-Secret Credential Exposure via InfraEnv Status

Technical summary

The vulnerability stems from insufficient sanitization of sensitive data during pull-secret validation in ACM/MCE. When a pull-secret reference fails validation, the system writes the complete referenced Secret's `.dockerconfigjson` content into the `InfraEnv.status.conditions[].message` field. Since InfraEnv objects are readable by principals holding the stock `view` ClusterRole, and `view` does not grant `get` or `list` permissions on Secrets, an attacker can bypass RBAC boundaries to recover authentication credentials. The exposed data includes synthetic registry username, password, email, and base64-encoded auth fields. This is classified under CWE-201 (Insertion of Sensitive Information into Sent Data).

Business impact

Registry credentials are foundational to supply-chain security. Exposure allows authenticated namespace viewers to pull private container images, potentially gaining access to proprietary code, build artifacts, or attack staging containers. In environments where namespace viewers are non-admin users (e.g., developers, operators, or delegated teams), this creates an unintended privilege escalation. Compromised credentials can be rotated, but the window of exposure and scope of affected registries depend on organizational practices. Secondary impact includes compliance violations if secrets are logged or transmitted outside secure channels.

Affected systems

ACM (Advanced Cluster Management for Kubernetes) and MCE (Multicluster Engine) installations with assisted-service components that validate pull-secrets during InfraEnv reconciliation. The exposure affects any OpenShift or Kubernetes cluster where InfraEnv objects are used for infrastructure provisioning with pull-secret references. Verify affected versions against Red Hat's official advisory or product documentation.

Exploitability

Exploitation requires an authenticated principal (PR:L in CVSS vector) with `view` or equivalent namespace read permissions. The attack does not require user interaction beyond reading an InfraEnv object, though the CVSS vector includes UI:R reflecting the need to observe or trigger a validation failure. No network access restrictions apply (AV:N). The barrier to exploitation is low for insiders or compromised service accounts with read-only access; external exploitation is blocked by the authentication requirement.

Remediation

Apply the latest security patch from Red Hat for ACM/MCE that sanitizes or redacts sensitive data from status condition messages. Immediate mitigations include: (1) restricting the `view` ClusterRole or creating custom RBAC policies to limit InfraEnv readability in sensitive namespaces, (2) rotating all pull-secrets that may have been exposed, (3) monitoring InfraEnv object reads via audit logs, and (4) implementing network policies to restrict container pulls from unauthorized registries. Verify patch availability and version compatibility with your deployment before applying.

Patch guidance

Consult Red Hat's security advisory for CVE-2026-10101 to identify fixed versions for your ACM/MCE deployment. Patches should filter or mask sensitive fields from status messages before serialization. Test patches in a non-production environment first, particularly if InfraEnv objects are used in active provisioning workflows. Coordinate updates with your infrastructure team to avoid disruption to cluster operations.

Detection guidance

Audit logs should be reviewed for (1) access patterns to InfraEnv objects by users or service accounts with limited cluster permissions, especially repeated reads from a single principal, and (2) any exfiltration attempts following InfraEnv reads (e.g., registry authentication failures from unexpected sources). Search logs for InfraEnv status messages containing `auth`, `username`, or `.dockerconfigjson` patterns. Monitor for pull-secret rotation or re-creation events following potential exposure windows. SIEM rules can flag high-volume InfraEnv reads by low-privilege accounts as suspicious behavior.

Why prioritize this

Although the CVSS score is MEDIUM (6.3), this vulnerability merits prioritization because it directly undermines RBAC—a foundational control in Kubernetes security. The attack is low-effort for insiders, the exposed asset (registry credentials) has high reuse value, and the finding suggests potential other information-leakage vectors in status fields. Organizations with strict namespace isolation policies should address this promptly to prevent privilege escalation within their cluster boundary.

Risk score, explained

CVSS 6.3 reflects a network-accessible, low-complexity, low-privilege attack with high confidentiality impact but limited integrity and no availability impact. The score appropriately captures the credential-exposure risk. However, context matters: in clusters where namespace viewers are trusted, risk is lower; in multi-tenant or untrusted-insider scenarios, effective risk is higher. Combine this score with your organization's threat model for pull-secret exposure and RBAC enforcement rigor.

Frequently asked questions