GPU VulnDB

Database/Control plane, storage & DevOps

Flyte: FILE-mounted secrets land in pod spec env vars, readable by anyone with pod read

CVSS 7.1CVE-2026-108728Control plane, storage & DevOpscurated

Impact

Flyte schedules ML training and batch workloads onto GPU nodes, and its embedded secret manager webhook mutates task pods to deliver secrets. For FILE-mounted secrets it base64-encodes the value into a SECRETS environment variable on an init container, which means the secret body lives in the pod spec rather than only in a mounted volume. Any principal with get/list on pods in that namespace - a far more commonly granted permission than read on Secrets - can decode the plaintext from the spec. On a shared cluster this collapses the separation between "can see what workloads are running" and "can read the credentials those workloads use": object-store keys, registry credentials and model-repository tokens belonging to other teams.

Who can reach it

Any authenticated principal with pod read access in the namespace where Flyte task pods run, including service accounts belonging to other tenants' workloads if RBAC grants pod listing. No access to the Kubernetes Secret store itself is needed.

What to do

Affects Flyte 2.0.1 through 2.0.51; the record names no fixed release. Until one lands, tighten RBAC so pod get/list is not granted broadly in Flyte's execution namespaces, avoid FILE-mounted secrets through the embedded secret manager (use an external secrets backend or volume-only delivery), and rotate any secret that was delivered this way. Remediation is control-plane configuration plus a Flyte propeller/webhook restart; GPU nodes do not need draining.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.