SUSE Fleet: Plain Text Storage of Vulnerability Exploit Helm Values

A high-severity vulnerability in SUSE’s Fleet, a GitOps management tool for Kubernetes clusters, has been disclosed by security researcher samjustus via GitHub Security Advisory GHSA-6h9x-9j5v-7w9h.

The vulnerability, tracked as CVE-2024-52284, allows Helm chart values—often containing sensitive credentials—to be stored inside BundleDeployment resources in plain text, exposing them to any user with GET or LIST permissions.

SUSE Fleet streamlines continuous deployment by reconciling Git repositories against Kubernetes manifests.

When users supply custom Helm values via the BundleDeployment.Spec.Options.Helm.Values field, Fleet applies those values directly in its reconciliation loop.

Unlike Helm v3, which stores chart state and values in Kubernetes Secrets (providing encryption at rest), Fleet historically embedded Helm values into BundleDeployment custom resources without encryption.

Kubernetes does not, by default, encrypt custom resource fields at rest, leaving any sensitive information unprotected in the cluster datastore.

The vulnerability’s primary impact is unauthorized disclosure of secrets. Any user granted the ability to list or retrieve BundleDeployment objects within a cluster namespace can harvest unencrypted Helm values, exposing credentials, tokens, or other critical data.

Because Kubernetes custom resources are stored as unencrypted etcd entries unless the cluster is explicitly configured with encryption at rest, leaked values remain vulnerable to compromise by anyone with cluster datastore access.

This behavior represents a significant deviation from Helm’s default security posture. Helm v3 stores release metadata and values in Secrets, benefiting from Kubernetes’ role-based access controls and optional etcd encryption.

Fleet’s prior approach leaves a glaring gap: sensitive configuration data in plain view whenever BundleDeployment objects are queried via kubectl or the API server.

CVSS and Severity

According to the disclosed details, the vulnerability carries a CVSS v3.1 base score of 7.4 (High). The breakdown is as follows:

• Attack Vector: Network.
• Attack Complexity: Low.
• Privileges Required: Low.
• User Interaction: None.
• Scope: Changed.
• Confidentiality Impact: High.
• Integrity Impact: None.
• Availability Impact: None.

These metrics underscore the ease with which an attacker or unauthorized user could harvest sensitive data, requiring only minimal permissions and no interaction beyond issuing standard API calls.

Fleet versions prior to 0.14.0 are affected, specifically:

• =0.11.0, <0.11.10
• =0.12.0, <0.12.6
• =0.13.0, <0.13.1

Versions 0.14.0, 0.13.1, 0.12.6, and 0.11.10 include the patch. The update introduces a mechanism where Fleet creates a dedicated Kubernetes Secret for each BundleDeployment’s Helm values, ensuring that these values no longer reside in plain text within CRD objects.

The Fleet controller now automatically generates a Secret in the same namespace before reconciliation, and the Fleet agent retrieves Helm values from that Secret rather than from the BundleDeployment spec.

Mitigations

Immediate remediation is to upgrade to one of the patched releases. For environments unable to upgrade promptly, Fleet users can mitigate exposure by avoiding direct in-spec value files.

Instead, reference values files by filename only, ensuring Fleet’s exclusion logic places them into Secrets:

Incorrect (risky) configuration:

texthelm:
  valuesFiles:
    - config-chart/values.yaml

Secure workaround:

texthelm:
  valuesFiles:
    - values.yaml

This naming convention ensures that Fleet interprets the file as external and excludes it from the plain-text spec dump.

Operators should:

1. Upgrade Fleet to v0.14.0 or later—or the corresponding patched version matching their current release line.
2. Audit existing BundleDeployments for inadvertently exposed secrets and rotate any compromised credentials immediately.
3. Enable Kubernetes encryption at rest for all critical namespaces to add a further layer of protection, even beyond Fleet’s built-in Secret storage.
4. Review RBAC policies to restrict GET and LIST operations on BundleDeployment resources to trusted users only.

For more context on credential theft techniques, refer to MITRE ATT&CK Technique T1555: Credentials from Password Stores.

Addressing this vulnerability not only secures SUSE Fleet deployments but reinforces the broader principle of never exposing secrets in plain text within cluster manifests.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.