CVE-2026-108728 in Flyte
Summary
by MITRE • 10/11/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Flyte versions 2.0.1 through 2.0.51 represents a critical failure in secret management architecture, specifically classified under CWE-319 as the use of cleartext credentials within communication or storage mechanisms. This flaw arises from an improper implementation of the embedded secret manager webhook, which is designed to inject sensitive configuration data into Kubernetes pods during their initialization phase. Instead of utilizing secure injection methods such as mounted volumes with restricted permissions or dedicated secret management APIs that enforce strict access controls, the system writes base64-encoded values directly into environment variables within the pod specification. This architectural decision fundamentally undermines the principle of least privilege and exposes sensitive information to any entity capable of inspecting the runtime state of the container infrastructure.
From a technical perspective, the core issue lies in how Kubernetes handles environment variable injection versus volume mounts. While environment variables are convenient for application configuration, they are inherently less secure because their values can be read by any process running within the pod or by external actors who have access to the pod's metadata API. In this specific case, the webhook intercepts secret retrieval requests and populates a SECRETS environment variable with base64-encoded data derived from FILE-mounted secrets. Although base64 encoding provides obfuscation rather than encryption, it is trivially reversible. Consequently, any user or service account granted read access to pods in the affected namespace can query the Kubernetes API server for pod specifications and extract these encoded values without needing explicit permissions on the underlying secret store itself.
The operational impact of this vulnerability is severe, particularly in multi-tenant environments where isolation between users or teams is required. An attacker with Pod read privileges, which are often granted broadly to developers for debugging purposes, can escalate their access by decoding the embedded secrets. These secrets may include database credentials, API keys, cloud provider tokens, or internal service authentication details. The exploitation of this flaw aligns with ATT&CK technique T1528, Steal Application Access Tokens, as well as T1098.004, SSH Authorized Keys, depending on the specific type of secret compromised. This allows for unauthorized access to downstream systems that trust these credentials, potentially leading to data exfiltration, lateral movement within the cluster, or complete compromise of dependent services.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. For organizations running affected versions, the primary action is to upgrade Flyte to version 2.0.52 or later, where this specific implementation flaw has been addressed by altering how secrets are injected into pods. Until an upgrade can be performed, administrators should restrict Pod read access in Kubernetes namespaces using Role-Based Access Control (RBAC) policies, ensuring that only highly privileged service accounts with explicit Secret store permissions can view pod specifications containing sensitive data. Additionally, auditing existing RBAC roles for overly permissive cluster-wide or namespace-level get/list operations on pods is essential to minimize the attack surface. Long-term resilience requires adopting secure secret injection patterns such as using projected volumes for secrets rather than environment variables and integrating with external secret management solutions like HashiCorp Vault or AWS Secrets Manager that enforce rigorous access logging and encryption at rest.