Description

Flyte 2.0.1 through 2.0.51 contains a cleartext secret storage vulnerability that allows users with Pod read access to obtain secrets by reading init container environment variables. The embedded secret manager webhook writes base64-encoded FILE-mounted secret values into the SECRETS environment variable, letting principals without Secret store access decode them from the Pod spec.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-11T13:17:16.590Z",
  "pubdate": "2026-10-11T13:17:16.590Z",
  "executiveSummary": "Flyte versions 2.0.1 through 2.0.51 are susceptible to a cleartext secret storage vulnerability originating from the embedded secret manager webhook.\nThe vulnerability allows unauthorized principals with Pod read access to retrieve sensitive credentials by inspecting environment variables within the Pod specification.\nBecause the webhook injects base64-encoded secret values directly into the SECRETS environment variable, secrets are persisted in the Pod's metadata rather than remaining protected by RBAC-restricted secret stores.\nThe impact is significant, as it effectively bypasses Kubernetes secret management security boundaries, enabling lateral movement or credential theft by any user or service account authorized to describe or list Pods.\nThis vulnerability represents a high-risk security flaw for environments hosting sensitive workflows, as it exposes the underlying secrets of integrated systems and infrastructure.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the Flyte secret manager webhook. During the pod mutation process, the webhook is designed to facilitate the mounting of external secrets into Flyte workflows. However, the component improperly handles the injection process by writing these secret values directly into the environment variable designated as SECRETS.\nThe affected versions are Flyte 2.0.1 through 2.0.51. The vulnerability occurs because the environment variables of a container are inherently part of the Pod specification (PodSpec), which is visible to any principal granted permissions to perform 'get' or 'list' operations on Pod resources within the Kubernetes API.\nThe attack flow follows a predictable pattern: 1) A workflow is initiated that utilizes the Flyte secret manager to mount a secret. 2) The webhook intercepts the Pod creation request. 3) The webhook retrieves the sensitive data from the configured secret provider. 4) Instead of strictly utilizing protected volumes or strictly scoped mounted files, the webhook populates the SECRETS environment variable with a base64-encoded representation of the secret material. 5) An attacker with Kubernetes RBAC permissions to view Pod specs executes 'kubectl get pod <pod_name> -o yaml' or queries the Kubernetes API directly. 6) The attacker extracts the base64-encoded string from the environment variable block and decodes it to obtain the original cleartext secret.\nThis behavior results in a total loss of confidentiality for the secrets managed by the webhook, as the standard Kubernetes permission model for 'read pod' access does not differentiate between observing metadata and observing sensitive environment configuration. Once the secret is injected into the environment variable, it remains static for the lifecycle of the Pod and is visible to any process or user with the ability to inspect the Pod definition. No specialized authentication or high-level cluster privileges are required for the exploitation, provided the attacker has basic Pod read-only access."
}