CVE-2025-11157: Feast-dev/feast RCE Vulnerability

CVE-2025-11157 Overview

A high-severity insecure deserialization vulnerability exists in feast-dev/feast version 0.53.0, specifically in the Kubernetes materializer job located at feast/sdk/python/feast/infra/compute_engines/kubernetes/main.py. The vulnerability arises from the use of yaml.load(..., Loader=yaml.Loader) to deserialize /var/feast/feature_store.yaml and /var/feast/materialization_config.yaml. This method allows for the instantiation of arbitrary Python objects, enabling an attacker with the ability to modify these YAML files to execute OS commands on the worker pod. This vulnerability can be exploited before the configuration is validated, potentially leading to cluster takeover, data poisoning, and supply-chain sabotage.

Critical Impact

Remote code execution via YAML deserialization enabling full cluster compromise, data poisoning, and supply-chain attacks in Kubernetes environments running Feast feature stores.

Affected Products

• feast-dev/feast version 0.53.0
• Feast Kubernetes materializer component
• Kubernetes-based Feast deployments using YAML configuration files

Discovery Timeline

• 2026-01-01 - CVE CVE-2025-11157 published to NVD
• 2026-01-02 - Last updated in NVD database

Technical Details for CVE-2025-11157

Vulnerability Analysis

This vulnerability is classified as CWE-502 (Deserialization of Untrusted Data). The core issue stems from the use of Python's yaml.load() function with the default yaml.Loader instead of the safer yaml.safe_load() alternative. When deserializing YAML content, the yaml.Loader class allows arbitrary Python object instantiation through YAML tags like !!python/object/apply: or !!python/object/new:. An attacker who gains write access to the configuration files can craft malicious YAML payloads that execute arbitrary Python code or system commands when the files are parsed.

The attack requires local access to modify the YAML configuration files in the worker pod filesystem. Once the malicious YAML is in place, code execution occurs during the materialization job initialization phase—before any configuration validation takes place. This pre-validation execution window makes the vulnerability particularly dangerous in automated pipeline environments.

Root Cause

The root cause is the use of yaml.load(f, Loader=yaml.Loader) to parse configuration files instead of yaml.safe_load(). The yaml.Loader class supports the full YAML specification, including Python-specific tags that enable arbitrary code execution. This design choice prioritizes feature completeness over security, creating an exploitable attack surface when configuration files can be influenced by untrusted sources.

Attack Vector

The attack vector is local, requiring the attacker to have the ability to modify YAML configuration files on the worker pod filesystem. Attack scenarios include:

1. Compromised container images - Malicious YAML files baked into a modified container image
2. ConfigMap/Secret manipulation - Kubernetes ConfigMaps or Secrets containing malicious YAML being mounted to the pod
3. Supply chain compromise - Upstream repository poisoning or dependency confusion attacks
4. Lateral movement - An attacker with initial cluster access modifying mounted volumes

The following patch demonstrates the security fix applied to address this vulnerability:

     logging.basicConfig(level=logging.INFO)
 
     with open("/var/feast/feature_store.yaml") as f:
-        feast_config = yaml.load(f, Loader=yaml.Loader)
+        feast_config = yaml.safe_load(f)
 
         with open("/var/feast/materialization_config.yaml") as b:
-            materialization_cfg = yaml.load(b, Loader=yaml.Loader)
+            materialization_cfg = yaml.safe_load(b)
 
             config = RepoConfig(**feast_config)
             store = FeatureStore(config=config)

Source: GitHub Commit Change

Detection Methods for CVE-2025-11157

Indicators of Compromise

• Unexpected modifications to /var/feast/feature_store.yaml or /var/feast/materialization_config.yaml files
• YAML files containing Python-specific tags such as !!python/object/apply:, !!python/object/new:, or !!python/module:
• Unusual process execution originating from Feast materializer worker pods
• Anomalous network connections from Kubernetes worker nodes running Feast jobs

Detection Strategies

• Monitor Kubernetes audit logs for unauthorized ConfigMap or Secret modifications affecting Feast configurations
• Implement file integrity monitoring on YAML configuration files within Feast pods
• Scan container images for malicious YAML payloads containing Python object instantiation tags
• Deploy runtime security tools to detect unexpected command execution in materializer pods

Monitoring Recommendations

• Enable Kubernetes audit logging with focus on ConfigMap and Secret access events
• Configure alerting for any process spawned by Feast materializer jobs that isn't part of normal operations
• Implement network segmentation monitoring to detect lateral movement attempts from worker pods
• Establish baseline behavior for Feast jobs to identify anomalous resource usage patterns

How to Mitigate CVE-2025-11157

Immediate Actions Required

• Upgrade feast-dev/feast to the patched version that includes commit b2e37ff37953b68ae833f6874ab5bc510a4ca5fb
• Audit all YAML configuration files for Python-specific object instantiation tags
• Review Kubernetes RBAC policies to restrict who can modify ConfigMaps and Secrets used by Feast
• Implement admission controllers to validate YAML content before deployment

Patch Information

The vulnerability has been addressed in the Feast repository. The fix replaces yaml.load(f, Loader=yaml.Loader) with yaml.safe_load(f) for all configuration file parsing. The security patch is available at commit b2e37ff37953b68ae833f6874ab5bc510a4ca5fb. Additional details about the vulnerability disclosure can be found on the Huntr Bounty Listing.

Workarounds

• Implement strict filesystem permissions on YAML configuration files to prevent unauthorized modifications
• Use Kubernetes Pod Security Policies or Pod Security Standards to run Feast pods with read-only root filesystems
• Deploy OPA Gatekeeper or Kyverno policies to block ConfigMaps containing potentially malicious YAML tags
• Isolate Feast workloads in dedicated namespaces with restricted network policies

# Configuration example - Kubernetes Pod Security Context for read-only filesystem
# Apply this security context to Feast materializer pods
securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000
  capabilities:
    drop:
      - ALL