Unauthenticated Flaws Pile Up in ML Feature Store Feast: Server Takeover and Arbitrary File Write (CVE-2026-56121 & CVE-2026-23537) — Update to v0.63.0

Feast, a data platform used in AI and machine learning development, has had serious vulnerabilities (software flaws) disclosed in quick succession — both exploitable from outside with no identity check (authentication). One lets an attacker take over the server itself, CVE-2026-56121 (severity 9.8); the other lets an attacker write arbitrary files onto the server, CVE-2026-23537 (severity 9.1). Both are high-risk types that can be triggered externally without authentication.

The bottom line first: updating Feast to 0.63.0 or later resolves both of these. CVE-2026-23537 was fixed in 0.59.0 and CVE-2026-56121 in 0.63.0, so moving to the latest version covers them together. It has newly come to light that CVE-2026-23537 also affects the Feast component bundled into Red Hat's AI platform, Red Hat OpenShift AI. Below we lay out both issues and the fixes.

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).

Feast has several server components, and these two issues sit in different ones. CVE-2026-56121 is in the "registry server" that holds the ledger of feature definitions; CVE-2026-23537 is in the "feature server" that serves feature values and the like over the network. Both are parts exposed to the network so that teams and programs can share them, and their request handling had a dangerous hole.

Who targets it, what they do, and what happens

First, as a premise, these flaws are dangerous in setups where Feast's server components are 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 a server to sit on the same cloud network as other services.

What an attacker who targets that does is run their own code on the server, or write arbitrary files onto it, without undergoing any identity check. 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 of both to the top class.

If the server is taken over, or configuration files and startup scripts are rewritten, 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 vulnerabilities are

Both share the trait of "processing a request that arrives over the network without an identity check." What happens, though, differs somewhat. Let us take them in turn.

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

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.

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.

CVE-2026-23537: unauthenticated arbitrary file write on the feature server (CVSS 9.1)

The other issue, CVE-2026-23537, is in the /save-document endpoint of Feast's feature server. According to the NVD description, this endpoint lacks an identity check (authorization check), so an unauthenticated outside attacker can write arbitrary JSON files onto the server's filesystem. There was an attempt to restrict where files could be written, but it was insufficient. It is classified as CWE-862 (missing authorization).

Being able to write files is dangerous on its own: overwriting configuration files or scripts loaded at startup can become a foothold for hijacking the server's behavior, and corrupting existing files through writes can lead to a service outage (DoS). In the severity breakdown, there is no data reading (no confidentiality impact), while the impact on tampering (integrity) and outage (availability) are both high, giving it a CVSS of 9.1. Like 56121, it can be triggered externally without a login (unauthenticated).

This flaw was fixed in 0.59.0, and is naturally included in 0.63.0 as well. In addition, the Feast component bundled with Red Hat's AI platform Red Hat OpenShift AI is said to be affected, and Red Hat's security page lists the affected images and how to update. If you use Feast within OpenShift AI, follow that update procedure too.

A quick check of whether you are affected

Affected are versions before 0.63.0, and it is especially dangerous if you expose the server components to the network. You can check your version with feast version or pip show feast in the environment where Feast is installed. The two fixed versions differ, but moving to 0.63.0 or later covers both at once.

If you do not use the server components 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. If you use Feast within Red Hat OpenShift AI, also follow Red Hat's guided update.

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. This resolves both 56121 and 23537.

If you cannot update immediately, an interim mitigation is to isolate the server components (registry server and feature server) where unknown parties cannot reach them. Concretely: limit the connection sources to a trusted range, stop a server if it was exposed externally, and place an authentication layer in front. Also inspect for unfamiliar processes or traffic, any newly added administrator accounts, and any unexpected added or rewritten files. 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 has had two serious vulnerabilities disclosed in quick succession: CVE-2026-56121 (CVSS 9.8), which lets the registry server be taken over without authentication, and CVE-2026-23537 (CVSS 9.1), which lets arbitrary files be written to the feature server without authentication. Both can be triggered externally without a login, but updating to 0.63.0 or later resolves both together. CVE-2026-23537 also affects the Feast component built into Red Hat OpenShift AI.

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 server components, 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 continue to track them by adding to this article.

References

• ▸NVD - CVE-2026-56121 (Feast registry server arbitrary execution)
• ▸NVD - CVE-2026-23537 (Feast feature server arbitrary file write)
• ▸Red Hat security page - CVE-2026-23537 (OpenShift AI)
• ▸VulnCheck (discoverer/reporter of 56121)
• ▸GitHub - feast-dev/feast (project, releases)
• ▸Feast Security Advisories (GitHub)
• ▸Feast official site (use cases, adopters)
• ▸PyPI - feast (package, versions)
• ▸dill (the Python restore library abused in 56121)