Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2024-52284

CVE-2024-52284: BundleDeployment Information Disclosure

CVE-2024-52284 is an information disclosure flaw in BundleDeployment resources allowing users with GET or LIST permissions to access Helm values containing sensitive credentials and secrets.

Updated:

CVE-2024-52284 Overview

CVE-2024-52284 is a sensitive information disclosure vulnerability in Rancher Fleet BundleDeployment resources. Any authenticated user holding GET or LIST permissions on BundleDeployment objects can read Helm chart values embedded in those resources. Helm values frequently contain credentials, API tokens, and other secrets used during application deployment. The flaw stems from storing sensitive Helm values in cleartext inside BundleDeployment resources rather than referencing them from Kubernetes Secret objects with stricter access controls [CWE-312].

Critical Impact

Low-privileged authenticated cluster users can extract credentials and secrets embedded in Helm chart values via BundleDeployment reads, enabling lateral movement and privilege escalation across managed clusters.

Affected Products

  • Rancher Fleet (GitOps controller for Kubernetes)
  • SUSE Rancher deployments using Fleet for bundle distribution
  • Kubernetes clusters managed via Fleet BundleDeployment resources

Discovery Timeline

  • 2025-09-02 - CVE-2024-52284 published to the National Vulnerability Database
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-52284

Vulnerability Analysis

Rancher Fleet distributes application bundles to downstream Kubernetes clusters using the BundleDeployment custom resource. When a bundle uses a Helm chart, the resolved Helm values are stored inside the BundleDeployment specification. These values often include database passwords, registry credentials, cloud provider API keys, and TLS private keys.

Kubernetes role-based access control (RBAC) commonly grants broad read access on custom resources to operators, developers, and monitoring tooling. The BundleDeployment resource kind was not treated with the same sensitivity as Secret objects, so read permissions were frequently granted without recognizing that plaintext credentials were exposed.

The scope change reflected in the CVSS metrics indicates that a low-privileged principal in one authorization domain can obtain data belonging to a different security domain, such as workload credentials owned by another team or tenant.

Root Cause

The root cause is cleartext storage of sensitive information inside a Kubernetes custom resource [CWE-312]. Helm values passed through Fleet are persisted directly on the BundleDeployment object rather than referenced from a Secret. Standard Kubernetes RBAC verbs get, list, and watch on the BundleDeployment kind therefore expose all embedded secrets to any principal with those verbs.

Attack Vector

An attacker requires authenticated access to the cluster with get or list permissions on BundleDeployment resources. The attacker enumerates BundleDeployment objects across namespaces and inspects the spec.options.helm.values field. Extracted credentials can then be reused against the target services referenced in the Helm chart, enabling lateral movement into databases, cloud accounts, or container registries.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-6h9x-9j5v-7w9h and the SUSE Bugzilla entry for CVE-2024-52284. No public exploit code has been published.

Detection Methods for CVE-2024-52284

Indicators of Compromise

  • Unexpected get or list API calls against the fleet.cattle.io/bundledeployments resource from user accounts or service accounts that do not manage Fleet.
  • Access to BundleDeployment objects from namespaces or identities outside the Fleet controller pipeline.
  • Downstream authentication events using credentials that were only ever distributed through Fleet Helm values.

Detection Strategies

  • Audit Kubernetes audit.log for verbs get, list, and watch targeting the bundledeployments.fleet.cattle.io resource, and baseline the expected callers.
  • Review ClusterRole and Role bindings that grant read verbs on bundledeployments and flag any binding that extends beyond Fleet system components.
  • Correlate suspicious BundleDeployment reads with subsequent authentication attempts against services whose credentials are managed via Fleet.

Monitoring Recommendations

  • Enable Kubernetes API server audit logging at the Metadata level or higher for fleet.cattle.io resources.
  • Alert on any new RoleBinding or ClusterRoleBinding that grants read access on BundleDeployment outside of the cattle-fleet-system namespace.
  • Rotate any credentials previously distributed as Helm values through Fleet and monitor for reuse of the old credentials.

How to Mitigate CVE-2024-52284

Immediate Actions Required

  • Upgrade Rancher Fleet to the fixed release identified in the GitHub Security Advisory GHSA-6h9x-9j5v-7w9h.
  • Rotate all credentials, tokens, and keys that were ever supplied to Fleet as Helm values.
  • Audit existing RBAC bindings and remove get, list, and watch verbs on bundledeployments.fleet.cattle.io from all principals that do not require them.

Patch Information

Refer to the GitHub Security Advisory GHSA-6h9x-9j5v-7w9h and the SUSE Bugzilla record for CVE-2024-52284 for fixed version details and vendor guidance. Apply the vendor patch across all Rancher management and downstream clusters running Fleet.

Workarounds

  • Restrict RBAC so that only the Fleet controller service account can read BundleDeployment resources.
  • Move sensitive Helm values out of Bundle and GitRepo definitions and reference them from Kubernetes Secret objects with dedicated RBAC.
  • Enable Kubernetes encryption-at-rest for fleet.cattle.io resources on etcd to reduce exposure if backups are stolen.
bash
# Identify subjects with read access to BundleDeployment resources
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name as $r | $r | test("fleet"))'

# List roles that grant verbs on bundledeployments
kubectl get clusterroles -o json | \
  jq '.items[] | select(.rules[]?.resources[]? == "bundledeployments")
      | {name: .metadata.name, rules: .rules}'

# Remove overly broad bindings after review
kubectl delete clusterrolebinding <binding-name>

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.