CVE-2025-11157

What it actually does

Unsafe PyYAML deserialization in the Feast Kubernetes materializer (feast 0.53.0, compute engine entrypoint) loads /var/feast/feature_store.yaml and /var/feast/materialization_config.yaml with yaml.load(..., Loader=yaml.Loader). That loader can instantiate arbitrary Python objects, so a crafted YAML document executes attacker-controlled code in the materializer worker pod before configuration validation. Impact is full confidentiality, integrity, and availability of the pod (CVSS 7.8, AV:L/PR:L): OS command execution, credential and kubeconfig theft from the pod identity, mutation of feature materialization outputs, and further Kubernetes API actions permitted by the job’s service account.

Why it matters to the business

Compromise of Feast materialization jobs can poison production features, sabotage ML training and inference pipelines, and expand into the surrounding Kubernetes cluster via the worker’s identity. Downstream model quality, regulatory reporting, and customer-facing predictions can be silently corrupted (supply-chain sabotage of ML data). The issue is not listed in CISA KEV, has no public exploit maturity, and a low, flat EPSS (~0.003 over 30 days), but it has been public for many months (~271 days). Organizations running Feast 0.53.0 materializer jobs on Kubernetes should still treat unpatched workers as high operational risk because a single writable config volume can yield cluster-level consequences.

How an attack unfolds

An attacker who can write or replace the YAML files consumed by the Kubernetes materializer—via a poisoned GitOps/config volume, a compromised CI artifact, a weakly permissioned PVC/ConfigMap/Secret, or a foothold on a node that mounts /var/feast—plants deserialization gadgets in feature_store.yaml or materialization_config.yaml. When the materializer job starts, feast/sdk/python/feast/infra/compute_engines/kubernetes/main.py deserializes those files with the unrestricted yaml.Loader before the store config is validated. PyYAML then constructs attacker-chosen Python objects, which run OS commands as the worker process. From there the attacker can steal the pod’s service-account token, call the Kubernetes API, alter or exfiltrate feature data, and persist in the cluster. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade feast-dev/feast off 0.53.0 to a build that includes commit b2e37ff37953b68ae833f6874ab5bc510a4ca5fb (or a later release that contains that fix). Replace every yaml.load(..., Loader=yaml.Loader) in materializer and related config loaders with yaml.safe_load or yaml.load(..., Loader=yaml.SafeLoader) so only primitive YAML types are accepted. Rebuild and roll materializer images, freeze image tags, and block old 0.53.0 images in admission policy. Restrict who can create or mutate ConfigMaps, Secrets, PVCs, and Git sources mounted at /var/feast; run materializer pods with a least-privilege service account, read-only root filesystem where possible, and no unnecessary host mounts. Treat Debian libxslt package entries in some scanners as a separate inventory item: if those packages are actually present, apply the distro updates listed as 1.1.29-1 for Debian 11–14 only after confirming they map to a real local package, not a mismatched CVE mapping.

How to confirm the fix worked

Inventory Feast deployments and images for version 0.53.0 and for kubernetes/main.py (or equivalent materializer entrypoint) that still calls yaml.load with yaml.Loader. After upgrade, confirm the running image/commit includes b2e37ff37953b68ae833f6874ab5bc510a4ca5fb and that config loading uses SafeLoader/safe_load only. In a non-production replica, deploy a materializer job whose YAML contains only safe mappings and verify successful materialization; separately confirm that documents using Python-object tags fail closed and do not start a worker payload. Review RBAC and volume mounts to ensure untrusted users cannot write the two /var/feast YAML paths.

Typical attack path

1. Obtain write access to Feast Kubernetes materializer inputs (ConfigMap, Secret, Git-synced volume, or host path that becomes /var/feast/feature_store.yaml or /var/feast/materialization_config.yaml).
2. Insert unsafe YAML tags that instantiate Python objects rather than plain mappings/lists.
3. Wait for or trigger a materialization Job/Pod that runs the Feast Kubernetes compute-engine entrypoint.
4. Job process deserializes the YAML with yaml.Loader before validation, executing code in the worker container.
5. Use the worker’s filesystem, environment, and service-account credentials to steal secrets, mutate feature outputs, or call the Kubernetes API.
6. Optionally persist (new workloads, modified volumes, poisoned feature definitions) to maintain access or sabotage the ML supply chain.

How to detect it

This CVE has no public exploit maturity and is not tied to named actors, so look for configuration tampering and unexpected worker behavior rather than a known malware family. Review Kubernetes audit logs and Git/CI history for unexpected updates to ConfigMaps, Secrets, or volumes that feed Feast materializer jobs. Inspect current and historical contents of /var/feast/feature_store.yaml and /var/feast/materialization_config.yaml for PyYAML object tags. On materializer pods, search process tables, container runtime logs, and syslog for shells or unexpected children of the Feast Python entrypoint around job start (deserialization happens before config validation). Check whether the pod service-account token was used for unusual API verbs after a job started. File-integrity monitoring on /var/feast and image-diff of 0.53.0 vs the patched commit help confirm both exposure and post-patch hygiene.

• /var/feast/feature_store.yaml
• /var/feast/materialization_config.yaml
• yaml.load
• Loader=yaml.Loader
• yaml.Loader
• feast/sdk/python/feast/infra/compute_engines/kubernetes/main.py
• !!python/object/apply
• !!python/object/new
• !!python/object/apply:os.system
• !!python/object/apply:subprocess.Popen
• !!python/module:os
• kind: Job (Feast Kubernetes materializer)
• serviceaccount token use from materializer pod after job start

What your security team should do

• Patch or rebuild all Feast Kubernetes materializer images to include commit b2e37ff37953b68ae833f6874ab5bc510a4ca5fb and retire 0.53.0 immediately.
• Hunt for yaml.Loader usage and Python-object YAML tags in materializer images, ConfigMaps, and /var/feast mounts before and after the rollout.
• Lock down write access to Feast config volumes and give materializer service accounts least privilege (no cluster-admin, no unnecessary secret listing).
• Add admission or CI checks that reject Feast images still importing unsafe PyYAML loaders.
• Because EPSS is low and the CVE is not in KEV, prioritize by actual Feast-on-Kubernetes exposure rather than mass emergency change, but do not leave 0.53.0 workers unpatched given RCE and data-poisoning impact.