Live › vulnerability › CVE-2026-56121
Feast's registry server decodes a user-defined function field with dill.loads() before checking authorization. An attacker who sends a crafted gRPC request can embed a malicious Python object and run OS commands as the Feast service account.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 21:24 UTC, 1h before NVD. All times on this page are UTC.
Teams running a Feast registry server that accepts gRPC requests, including requests that carry OnDemandFeatureView specs. Client-only use of Feast that never exposes the registry server is less exposed. The sources do not say whether authentication on the registry server changes exposure, because the deserialization runs before the authorization check.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| feast | pypi | < 0.63.0 | 0.63.0 |
pip show feast and check whether the version is below 0.63.0user_defined_function.body field0.63.0 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
Feast before 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.
This page as .md · .json · in your agent: get_signal("CVE-2026-56121")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.