Feast vulnerabilities

Feast through 0.66.0 fails to verify JWT token signatures before establishing user identity, allowing attackers to bypass all role-based access control by presenting an unverified token with a hardcoded claim value. Attackers can obtain trusted internal identity and gain unchecked read and write access to all entities, feature views, data sources, and permission policies on the server.

A flaw was found in Feast where the system improperly deserializes user-defined functions (UDFs) stored in its registry, serialized using the 'dill' library. This allows a remote attacker to store a malicious UDF, leading to unauthenticated arbitrary code execution on the feature server in default configurations. An authenticated attacker can also achieve arbitrary code execution on the registry server by bypassing authorization checks during deserialization.

Feast before version 0.63.0 contains an unsafe deserialization vulnerability that allows unauthenticated or unauthorized attackers to achieve remote code execution by sending a crafted gRPC request to the registry server. The user_defined_function.body field of an OnDemandFeatureView spec is decoded from base64 and passed to dill.loads() before any authorization check is performed, enabling attackers to embed a malicious serialized Python object with an arbitrary __reduce__ method to execute OS commands as the feast service account.

In Feast prior to 0.65.0, .github/workflows/pr_integration_tests.yml uses pull_request_target with the synchronize event and preserves ok-to-test, approved, or lgtm labels across newly pushed commits, allowing a fork contributor to obtain approval for a benign revision and then run changed code through privileged make targets. The job exposes GCP, AWS, and Snowflake credentials to that code.

A vulnerability in Feast allows authorization bypass in the /materialize and /materialize-incremental endpoints. By sending a specially crafted request that omits the feature_views field, an attacker can bypass permission checks, allowing an unauthenticated remote attacker or any authenticated user to trigger a full re-materialization of all feature views. This results in a Denial of Service (DoS) due to data corruption and significant resource consumption.

A flaw was found in the Feast operator. A malicious tenant could inject arbitrary code into their feature repository. This code would be executed by an automated process with elevated privileges, allowing the tenant to steal sensitive credentials. This could lead to a direct escalation of privileges, granting the tenant administrative control over the Kubernetes cluster.

A vulnerability in Feast and feast-operator is due to the default 'no_auth' configuration, which installs no security manager. This allows unauthenticated and unauthorized access to feature-server, registry-server, and offline-server endpoints. A remote attacker can exploit the missing authentication to achieve remote code execution (RCE) by storing a malicious UDF, trigger DoS by forcing re-materialization, and gain unauthorized access to cross-tenant data.

A high-severity remote code execution vulnerability exists in feast-dev/feast version 0.53.0 in the Kubernetes materializer job. The use of yaml.load with Loader=yaml.Loader allows arbitrary Python object instantiation, enabling OS command execution on the worker pod.