Feast operator: tenant-supplied feature repo code runs with elevated privileges, reaching cluster admin

Impact

A tenant who can write to their own feature repository can inject code that an automated process later executes with elevated privileges. Red Hat states this allows the tenant to steal credentials from that process and escalate to administrative control of the Kubernetes cluster. On a shared GPU cluster this is the multi-tenancy break that matters most: one tenant's feature-store content becomes control over the control plane, and from there over every other tenant's workloads and the nodes their jobs land on. The record scores it as requiring high privileges (a tenant account) and high attack complexity, so it is not a drive-by, but the ceiling is full cluster compromise.

Who can reach it

Any tenant with write access to a feature repository consumed by the Feast operator. Network-reachable, authenticated as that tenant; no interaction from an administrator needed.

What to do

Update OpenShift AI to the builds in RHSA-2026:53261 / RHSA-2026:53262 for the 2.25 and 3.4 streams. The operator reconciles and restarts its own pods — no node drain or reboot. Because the payoff of this flaw is credential theft, rotate the service account tokens and any credentials the Feast automation process held on affected clusters.

References