The value that unlocks the most trusted identity in a Feast deployment is printed in Feast's own Helm chart, where anyone can read it. Feast never checks whether the token carrying it is genuine.
That is CVE-2026-92787, an authentication bypass in the open-source feature store that data and machine learning teams use to serve features to models in production. VulnCheck, which assigned the identifier, published its advisory on 16 September and scores the flaw 9.3 under version 4 of the CVSS scale and 9.8 under version 3.1. It credits George Chen. Peru's CNSD relayed it in an integrated security alert two days later.
A password that ships in the chart
Feast lets its own components skip normal authentication when they talk to each other. A feature server calling the registry server sends a token whose identity claim matches a value held in an environment variable, and Feast treats that as proof the caller is internal.
Two things go wrong at once. VulnCheck's summary is that 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. The claim is read from a JWT that has been decoded but never checked against a signature or an identity provider. And the value it is compared against is set, in Feast's own Helm chart for the feature server, to a fixed string anybody can look up.
So the token does not have to be real. According to the project's public issue, anyone able to send an HTTP, gRPC or Arrow Flight request to a server deployed from that chart can craft a JWT with a garbage signature and the one matching claim, and be handed an identity the security manager trusts completely: full read of every project's entities, feature views, data sources and permission policies, and full create, update and delete over all of them.
Nobody has shipped a fix
This is the uncomfortable part. The issue was reported privately on 7 July 2026, opened publicly on 26 August, and it is still open. Feast's most recent release, 0.66.0 from 21 August, is inside the affected range, and neither the advisory nor the project names a fixed version. There is no patch to apply.
What is left is the deployment. The trusted value reaches the server through an environment variable, and it is the chart's public default that makes the bypass free rather than the variable itself, so an operator who sets it to something unguessable removes the part an outsider can simply look up. That is a hedge, not a fix, because the signature check is still missing. The reliable control today is reachability: a Feast server that untrusted callers cannot open a connection to cannot be handed a forged token.
It is a familiar shape in AI infrastructure. Two weeks ago a one-character flaw in an LLM gateway exposed hundreds of deployments in much the same way, by letting a check pass that was never really performed.
Feature stores rarely appear on an asset inventory as security-relevant, which is how something like this stays quiet. They hold the data a company's models make decisions from, and write access to them is write access to those decisions.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.