Unauthenticated Server Takeover Flaw in ML Feature Store Feast (CVE-2026-56121) — Update to v0.63.0

Feast, a data platform used in AI and machine learning development, has been found to contain a vulnerability (a software flaw) that lets an attacker take over the server from outside without any identity check (authentication). It is tracked as CVE-2026-56121, with a severity of 9.8 out of 10 (Critical), near the top of the scale.

The affected versions are those before 0.63.0. It was found and reported by the U.S. security firm VulnCheck and disclosed on June 24, 2026. The fix is included in 0.63.0. If you expose part of Feast's functionality to the network, an attacker can send a single crafted request and run arbitrary code on the server where Feast is running, so an update is needed right away.

What kind of tool is Feast?

Feast is an open-source platform for centrally managing and serving the data items (features) that machine learning models use. It is a type of software called a "feature store," and in AI systems such as fraud detection, product recommendations, and credit scoring, it keeps the data consistent between training and production so the two do not diverge.

Its user base is broad: according to its official site, adopters include Robinhood, NVIDIA, Discord, Cloudflare, Walmart, Shopify, Salesforce, IBM, and Capital One, and downloads exceed 12 million. With over 7,100 stars on GitHub, it is one of the standard tools in machine-learning operations (MLOps).

This flaw is in the part of Feast called the "registry server." Feast keeps a ledger (a registry) of feature definitions, and to let multiple teams and programs share that ledger, it offers a server that provides it over the network using a communication method called gRPC. The request handling in this shared server had a dangerous hole.

Who targets it, what they do, and what happens

First, as a premise, this flaw is dangerous in setups where Feast's registry server is exposed to the network (an internal LAN, inside a cloud, or worse, externally) without authentication. Machine-learning platforms are often placed deep inside an internal network, but it is not unusual for access to be widened for cross-team sharing, or for the server to sit on the same cloud network as other services.

What an attacker who targets that does is send the registry server a request embedded with a malicious program and, without undergoing any identity check, run their own code on that server. No login or key is required; it works for anyone in a position to reach the server with a request, which is what pushes the severity to the top class.

If the server is taken over, the damage does not stop at Feast itself. A machine-learning platform tends to concentrate training data, the models pushed to production, and connection details to external services (credentials for databases and clouds). From that foothold, an attacker could steal data, tamper with models (laying the groundwork to make them produce malicious predictions), and move deeper into the internal network.

This danger of running externally sourced data without being able to deploy it safely also ties into how you manage the third-party components used in development. Inspecting the packages and services you bring in is worth revisiting alongside the ideas in our OSS supply-chain scanner overview. Vulnerabilities that begin to be used in real attacks can be added to the U.S. agency CISA's "list of vulnerabilities under active attack"; we maintain a Japanese-language overview in our CISA KEV Dashboard (Japanese edition).

What the vulnerability is

The cause is that data received over the network is "restored" defenselessly. In programming, it is common to pack data into a string to send it, then turn it back into its original form on the receiving side (deserialization). If that "turn it back" step trusts the incoming contents too much, an attacker can use crafted contents to run arbitrary code.

CVE-2026-56121: arbitrary execution via the registry server's defenseless restore step (CVSS 9.8)

According to VulnCheck's analysis, Feast's registry server took data sent over gRPC, extracted it from base64 encoding, and restored it with the Python library "dill." The problem is that there was no identity check (authorization check) at all before this restore step.

Python deserialization like dill is inherently prone to abuse for RCE (arbitrary program execution). By sending crafted data embedded with a mechanism called __reduce__, an attacker can run any command the moment it is restored. Because execution happens with the privileges of the Feast service, the attacker's reach extends to whatever data and credentials that server can touch. In short, it is the most dangerous type of flaw: an unauthenticated party can take over the server with a single request.

In the fixed version 0.63.0, this restore step was reworked so that untrusted input is no longer executed as-is. The issue was reported by VulnCheck through the bug-bounty platform Huntr, with a CVSS of 9.8 under the 3.1 scheme and 9.3 under the newer 4.0.

A quick check of whether you are affected

Affected are versions before 0.63.0, and it is especially dangerous if you expose the registry server to the network. You can check your version with feast version or pip show feast in the environment where Feast is installed.

If you do not use the registry server and run only with local files on hand, the risk is lower because requests cannot reach you from outside. But considering setups reachable from another machine on the internal network, or the possibility of switching to a server deployment later, updating to 0.63.0 or later is recommended in any case.

What to do now

The top priority is to update Feast to 0.63.0 or later. Because it is distributed as a Python package, you can update it with something like pip install --upgrade feast. Check the latest version on the distribution page.

If you cannot update immediately, an interim mitigation is to isolate the registry server where unknown parties cannot reach it. Concretely: limit the connection sources to a trusted range, stop the server if it was exposed externally, and place an authentication layer in front. Also inspect for unfamiliar processes or traffic and any newly added administrator accounts. In case you have already been compromised, the safe move is to rotate the database and cloud credentials the Feast server held after you update.

Summary

Feast's CVE-2026-56121 is a vulnerability in which the registry server defenselessly restores received data without authentication, allowing arbitrary code to be run from outside. Its severity is CVSS 9.8, near the very top, and it affects versions before 0.63.0, fixed in the latest 0.63.0.

A machine-learning platform like Feast is a key point where training data, models, and credentials to external services concentrate. Because a takeover spreads easily to its surroundings, the risk of leaving it unpatched is not small. If you expose the registry server, update as a top priority; even if you do not, update to 0.63.0 or later soon. If new vulnerabilities concerning Feast emerge, we will track them by adding to this article.

References

• ▸NVD - CVE-2026-56121 (Feast registry server arbitrary execution)
• ▸VulnCheck (discoverer/reporter)
• ▸GitHub - feast-dev/feast (project, releases)
• ▸Feast Security Advisories (GitHub)
• ▸Feast official site (use cases, adopters)
• ▸Feast official docs (registry explanation)
• ▸PyPI - feast (package, versions)
• ▸dill (the Python restore library abused here)