Flyte EUVD-2026-96894

Requires a Flyte 2.0.1-2.0.51 deployment whose embedded secret manager webhook mounts secrets in FILE mode, because the webhook base64-encodes those FILE-mounted values into the SECRETS environment variable of the task's init container within the Pod spec. The attacker must hold Kubernetes RBAC permission to read Pods (get/list) in the relevant namespace but does NOT need access to the Kubernetes Secret store - that privilege split is precisely what the flaw bypasses. Limiting factors: exploitation is confined to principals already authenticated to the cluster with Pod read rights, only affects secrets configured as FILE mounts (not necessarily env-injected secrets), and is most impactful in multi-tenant clusters that intentionally segregate Pod-read from Secret-read permissions.

This is a credible but conditional information-disclosure issue rather than a critical remote-takeover bug. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) scores 7.1 HIGH, driven entirely by high confidentiality impact with no integrity or availability impact. PR:L confirms an authenticated principal is required - specifically a Kubernetes user/service account holding Pod read permission - so this is not an unauthenticated internet-facing flaw despite AV:N. The AV:N reflects that the Kubernetes API server (where Pod specs are read) is network-reachable, but exploitation presupposes existing cluster credentials. No EPSS score, CISA KEV listing, or POC/exploit-code flag is present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the only exploitation-relevant artifacts are a VulnCheck advisory and a third-party hackmd technical write-up describing the mechanism. The signals are consistent with each other (no conflict between CVSS and description), pointing to a real but privilege-gated priority: it matters most as a privilege-boundary/least-privilege bypass inside multi-tenant Flyte-on-Kubernetes clusters, not as a mass-exploitable vulnerability. Patch/fixed-version information is NOT present in the provided input and could not be independently verified.

In a multi-tenant Flyte-on-Kubernetes deployment, a low-privileged user who has been granted only Pod read access (but explicitly denied access to the Kubernetes Secret store) lists or gets a task Pod and reads its init container spec. The embedded secret manager webhook has written FILE-mounted secret values as base64 into the SECRETS environment variable, so the user simply base64-decodes those values to recover secrets they were never authorized to see. No public exploit code is identified at time of analysis, but the technique is fully documented in the referenced write-up and requires no special tooling.