Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-19130

CVE-2026-19130: Multicluster-Engine Auth Bypass Vulnerability

CVE-2026-19130 is an authentication bypass flaw in multicluster-engine that allows attackers to intercept rotated provider credentials via label manipulation. This article covers technical details, affected systems, and mitigation.

Published:

CVE-2026-19130 Overview

CVE-2026-19130 is an authorization bypass vulnerability in the provider-credential-controller component of Red Hat multicluster-engine (MCE). An attacker with specific permissions on the hub cluster, combined with knowledge of a prior credential value, can manipulate copiedFrom labels to intercept newly rotated provider credentials. Successful exploitation results in unauthorized disclosure of sensitive provider credentials that should remain protected. The flaw is categorized under [CWE-639: Authorization Bypass Through User-Controlled Key].

Critical Impact

Attackers with limited hub cluster permissions can intercept rotated provider credentials, exposing sensitive cloud and infrastructure secrets managed by MCE.

Affected Products

  • Red Hat multicluster-engine (MCE)
  • provider-credential-controller component
  • Red Hat Advanced Cluster Management deployments that depend on MCE

Discovery Timeline

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

Technical Details for CVE-2026-19130

Vulnerability Analysis

The provider-credential-controller in MCE manages copies of provider credentials across the hub cluster. It uses copiedFrom labels to track the source of credential copies and to propagate updates when a source credential rotates. The controller does not sufficiently validate authorization when reconciling label-driven copy relationships. An attacker who can create or modify secrets on the hub cluster, and who already knows a prior credential value, can craft a secret carrying copiedFrom labels that reference a target source credential.

When the source credential rotates, the controller propagates the new credential value into the attacker-controlled copy. The attacker then reads the rotated secret through their existing permissions. The attack requires network access to the Kubernetes API, low privileges on the hub cluster, and user interaction tied to the rotation workflow. The scope changes because the impact crosses the trust boundary between managed cluster credentials and unrelated tenants of the hub.

Root Cause

The controller trusts user-controlled copiedFrom label values as the authoritative key for identifying legitimate credential copies. It does not verify that the requesting principal is authorized to receive copies of the referenced source credential. This mismatch between label-driven reconciliation logic and Kubernetes role-based access control creates the authorization bypass described in [CWE-639].

Attack Vector

The attack requires the following preconditions: authenticated access to the hub cluster with permissions to create or modify secrets in an accessible namespace, prior knowledge of an existing credential value, and a credential rotation event initiated by a legitimate user. The attacker plants a secret with copiedFrom labels pointing to a targeted provider credential. On rotation, the controller populates the attacker's secret with the newly generated credential material. No verified public exploit code is available. See the Red Hat CVE-2026-19130 Advisory and Red Hat Bug Report #2512105 for technical details.

Detection Methods for CVE-2026-19130

Indicators of Compromise

  • Unexpected Kubernetes Secret objects on the hub cluster carrying copiedFrom labels that reference provider credentials the creator should not access.
  • Audit log entries showing create or update operations on secrets by service accounts or users outside the credential management workflow.
  • Provider credential values appearing in namespaces that do not host the corresponding managed cluster resources.

Detection Strategies

  • Enable and centralize Kubernetes API audit logs for the hub cluster, focusing on secrets verbs and label modifications.
  • Alert on any secret creation that includes copiedFrom labels outside of the provider-credential-controller service account identity.
  • Correlate credential rotation events with subsequent read access on secrets bearing matching copiedFrom label values.

Monitoring Recommendations

  • Monitor RBAC bindings that grant create, update, or patch on secrets across hub cluster namespaces and review them regularly.
  • Track the provider-credential-controller reconciliation events and compare them against expected credential copy targets.
  • Ingest hub cluster audit and controller logs into a centralized analytics platform for retention and long-term correlation.

How to Mitigate CVE-2026-19130

Immediate Actions Required

  • Review the Red Hat CVE-2026-19130 Advisory and apply the fixed MCE component version once available for your channel.
  • Rotate any provider credentials that may have been exposed through unauthorized copies since MCE deployment.
  • Audit existing secrets on the hub cluster for unexpected copiedFrom labels and remove untrusted entries.

Patch Information

Refer to the Red Hat CVE-2026-19130 Advisory and Red Hat Bug Report #2512105 for fixed component versions and errata references specific to your MCE channel. Apply updates through the standard Operator Lifecycle Manager upgrade path.

Workarounds

  • Restrict create, update, and patch permissions on secrets in hub cluster namespaces to the minimum set of principals required for cluster operations.
  • Use Kubernetes admission controllers or policy engines to reject secrets bearing copiedFrom labels unless created by the provider-credential-controller service account.
  • Segment provider credential namespaces so that tenant workloads cannot enumerate or reference credentials belonging to other tenants.
bash
# Configuration example: admission policy pseudocode to block untrusted copiedFrom labels
# Reject Secret creation carrying 'copiedFrom' labels from non-controller identities
# Apply via your policy engine (e.g., Kyverno, OPA Gatekeeper)
#   match: kind=Secret, operation in [CREATE, UPDATE]
#   condition: has(labels['cluster.open-cluster-management.io/copiedFrom-name'])
#              AND request.userInfo.username != 'system:serviceaccount:multicluster-engine:provider-credential-controller'
#   action: deny

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.