CVE-2026-66878: Multicloud Operators Info Disclosure Flaw

CVE-2026-66878 Overview

CVE-2026-66878 is an information disclosure vulnerability in the multicloud-operators-subscription component used in Red Hat multi-cluster management environments. A namespace administrator with permissions to create Channel and Subscription resources can manipulate the Channel.Spec.SecretRef.Namespace field to reference Secrets in namespaces they do not own. The subscription controller then copies the referenced Secret contents into the attacker-controlled namespace, exposing sensitive data across tenancy boundaries. The flaw is classified as CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
An authenticated namespace administrator can read arbitrary Kubernetes Secrets from other namespaces, breaking multi-tenant isolation and exposing credentials, API tokens, and TLS material.

Affected Products

Red Hat multicloud-operators-subscription
Red Hat Advanced Cluster Management (RHACM) deployments consuming the subscription operator
Open Cluster Management channel/subscription workflows using cross-namespace SecretRef

Discovery Timeline

2026-08-12 - CVE-2026-66878 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-66878

Vulnerability Analysis

The multicloud-operators-subscription controller reconciles Channel custom resources that describe where subscribed content originates. Each Channel can reference an authentication Secret through the Spec.SecretRef field, which includes both a name and a namespace. The controller reads that Secret using its own elevated service account privileges and copies its contents into the namespace where the Subscription resource lives.

The controller does not verify that the requesting user has read access to the referenced Secret in the source namespace. Instead, it trusts the user-supplied SecretRef.Namespace value and performs the copy operation under controller privileges. This is a classic confused-deputy pattern where the operator's cluster-scoped permissions are exercised on behalf of a lower-privileged tenant.

Successful exploitation results in disclosure of Secret material such as registry pull credentials, Git repository tokens, TLS private keys, or workload service account tokens. Integrity and availability are not directly impacted, but disclosed credentials frequently enable follow-on attacks.

Root Cause

The root cause is missing authorization checks on the Channel.Spec.SecretRef.Namespace field. The controller acts as a privileged proxy without validating whether the submitting principal has get permission on the target Secret via SubjectAccessReview or an equivalent RBAC check.

Attack Vector

An attacker requires namespace-administrator privileges within a namespace where they can create Channel and Subscription custom resources. The attacker crafts a Channel whose SecretRef points at a Secret in a victim namespace, then binds a Subscription to that Channel. The reconciliation loop copies the Secret into the attacker's namespace, where it can be read with standard kubectl get secret operations. The scope-change indicator in the CVSS vector reflects the trust-boundary crossing between tenant namespaces.

Detection Methods for CVE-2026-66878

Indicators of Compromise

Creation of Channel resources where Spec.SecretRef.Namespace differs from the Channel's own namespace.
New Secrets appearing in tenant namespaces whose names match Secrets in unrelated namespaces such as openshift-config, kube-system, or other tenant namespaces.
Kubernetes audit log entries showing the subscription controller service account performing get operations on Secrets outside expected reconciliation paths.

Detection Strategies

Query the Kubernetes API server audit log for channels.apps.open-cluster-management.io create or update events and flag any where spec.secretRef.namespace is not equal to metadata.namespace.
Correlate subscription-operator Secret reads against the requesting user identity captured in the originating Channel resource to identify unauthorized cross-namespace access.
Baseline the expected set of Secrets per namespace and alert when unexpected Secret objects are created by controller service accounts.

Monitoring Recommendations

Forward Kubernetes audit logs and controller logs to a centralized analytics platform for long-term retention and correlation.
Enable admission-controller logging (OPA Gatekeeper, Kyverno) to record policy decisions on Channel submissions.
Track service-account activity for multicluster-operators-subscription and alert on Secret reads outside its own namespace.

How to Mitigate CVE-2026-66878

Immediate Actions Required

Apply the fixed multicloud-operators-subscription release as published in the Red Hat CVE-2026-66878 advisory.
Rotate any Secrets that may have been copied out of privileged namespaces, including registry credentials, Git tokens, and TLS keys.
Audit existing Channel resources cluster-wide and remove any where SecretRef.Namespace points outside the Channel's own namespace without justification.

Patch Information

Refer to the Red Hat security advisory and Red Hat Bug Report #2514226 for fixed component versions and errata mapping. Update Red Hat Advanced Cluster Management deployments to the patched build that ships the corrected authorization check.

Workarounds

Deploy an admission policy (Kyverno or OPA Gatekeeper) that rejects Channel resources whose spec.secretRef.namespace does not equal metadata.namespace.
Restrict create and update permissions on Channel and Subscription resources to trusted operators only, using namespace-scoped RoleBindings.
Segregate sensitive Secrets into dedicated namespaces protected by NetworkPolicies and RBAC that exclude tenant service accounts.

bash

# Kyverno policy to block cross-namespace SecretRef in Channel resources
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-channel-secretref-namespace
spec:
  validationFailureAction: Enforce
  rules:
    - name: secretref-must-match-channel-namespace
      match:
        any:
          - resources:
              kinds:
                - apps.open-cluster-management.io/v1/Channel
      validate:
        message: "Channel.Spec.SecretRef.Namespace must equal the Channel's own namespace."
        deny:
          conditions:
            any:
              - key: "{{ request.object.spec.secretRef.namespace }}"
                operator: NotEquals
                value: "{{ request.object.metadata.namespace }}"