Feast Has a 9.8 JWT Bypass — Attackers Can Become the Internal Service

• The Mess: Feast accepts an unverified JWT as a trusted internal identity, allowing an unauthenticated attacker to bypass the entire RBAC layer. The hardcoded trust value is sitting in the project’s own Helm chart.
• The Damage: A network-accessible Feast server can expose unrestricted read/write access to feature views, data sources, entities and permission policies.
• The Fix: Upgrade to a release containing the security fix and immediately review any externally reachable Feast deployment.

Feast is supposed to control access to machine-learning features.

Its RBAC system is supposed to answer a simple question:

Who is allowed to read or modify this data?

CVE-2026-92787 effectively breaks that question.

Feast versions through 0.66.0 fail to properly verify a JWT signature before using the token to establish an internal identity. An attacker can construct an unsigned token containing a specific hardcoded claim and receive the same trusted identity used for communication between Feast components.

The vulnerability carries a CVSS 3.1 score of 9.8 and requires no credentials or user interaction.

The authentication check happens too late

The bug is buried in the way Feast handles its internal service identity.

Normally, a JWT should go through roughly this sequence:

Receive token → verify signature → validate claims → establish identity → authorize request

Feast’s vulnerable path effectively did this:

Receive token → decode without signature verification → check for internal identity → trust it → skip normal authorization

That difference is catastrophic.

The vulnerable OIDC token parser explicitly performs a JWT decode with signature verification disabled. If the preferred_username claim matches the configured internal-communication value, Feast immediately creates a trusted user object.

The actual signature validation happens later — but the attacker never needs to reach it.

The trusted value was not actually a secret

This is where the vulnerability gets particularly ugly.

Feast’s Helm chart sets INTRA_COMMUNICATION_BASE64 to a fixed value derived from:

intra-server-communication

The resulting Base64 value is:

aW50cmEtc2VydmVyLWNvbW11bmljYXRpb24=

It is therefore not a deployment-specific secret.

It is not randomly generated.

It is not protected by a key-management system.

It is a constant embedded in the deployment template.

The researchers found that an attacker who can reach the Feast service can reproduce the same identity without possessing a legitimate credential.

Feast itself was generating the dangerous token

There is an even stranger part.

The vulnerable internal communication mechanism was deliberately designed around an unsigned JWT.

Feast’s own client code creates the token using:

algorithm="none"

and an empty key.

The payload contains the trusted internal username.

That means the system effectively had a built-in credential that says:

“I am an internal Feast component.”

But the credential had no cryptographic proof attached to it.

Anyone able to reproduce its format could present the same identity.

RBAC does not merely weaken — it disappears

This is not a case where an attacker gets access to one low-privilege account.

The vulnerable identity causes Feast’s permission checks to be skipped.

The security manager checks whether the current user is the special intra-communication identity. If it is, the authorization layer treats authentication as unnecessary for the request.

The researchers documented that this bypasses permission checks across projects.

That can expose:

• entities
• feature views
• data sources
• permission policies
• project-level resources

And the access is not read-only.

The documented impact includes create, update and delete operations.

This is why the CVSS confidentiality, integrity and availability components are all rated high.

One token can cross project boundaries

Multi-project deployments are particularly interesting.

Imagine a Feast installation containing:

project_a

and

project_b

Each project has its own RBAC rules.

An attacker should not be able to move from one project to another without the appropriate role.

The vulnerable internal identity bypasses that model.

Once the attacker is recognized as the trusted internal communication user, the normal project-specific permissions are no longer the barrier they were supposed to be.

The result is effectively a global authorization bypass on the affected server.

REST, gRPC and Arrow Flight are in the blast radius

This is not restricted to one obscure HTTP endpoint.

The Feast issue documents the same authentication handling being used across multiple serving interfaces:

• REST
• gRPC
• Arrow Flight

All three resolve the current identity through the vulnerable token-parsing mechanism.

That significantly expands the importance of network exposure.

If a Feast deployment exposes several of these interfaces to an attacker-controlled network, the authentication bypass can potentially be reached through more than one protocol.

The proof of concept is already public

The disclosure contains a working proof of concept.

The researchers demonstrated a Feast REST Registry Server configured with OIDC authentication and showed that:

• requests without a token were rejected;
• properly signed tokens without the required RBAC role were rejected;
• the forged unsigned internal-communication token bypassed the permission model.

The important point is that the attack does not depend on stealing a legitimate JWT.

The attacker can manufacture the token.

That makes this fundamentally different from a credential-theft scenario.

This is an ML infrastructure problem

Feast is a feature store used in machine-learning systems.

Feature stores sit between data pipelines and models, providing features used for training and inference.

That makes the authorization layer particularly important.

An attacker who can modify feature definitions or feature data is not simply accessing a web application’s database.

They may be altering the data consumed by downstream ML workloads.

The exact consequences depend heavily on the deployment architecture, but unauthorized modification of feature-store data can affect model inputs, pipelines and application behavior.

This is one reason authentication failures in ML infrastructure deserve the same attention as failures in traditional databases and API gateways.

Kubernetes makes the deployment pattern especially relevant

The vulnerable trust value is explicitly present in the Feast Helm chart.

That means Kubernetes deployments using the affected chart deserve immediate review.

Administrators should identify:

• Feast Feature Server deployments
• Registry Server deployments
• exposed REST endpoints
• gRPC listeners
• Arrow Flight interfaces
• OIDC configuration
• Kubernetes service-account authentication
• network policies controlling access to Feast

The vulnerability also affects the Kubernetes token parser path.

The issue documents a similar trust decision based on an unverified token value before normal authentication completes.

What defenders should do now

First, determine whether the environment is running Feast 0.66.0 or earlier.

Those versions are listed as affected by CVE-2026-92787.

Then:

1. Upgrade to a fixed Feast release as soon as one is available for your deployment.
2. Review Helm values and generated Kubernetes manifests.
3. Check whether INTRA_COMMUNICATION_BASE64 uses the publicly known default.
4. Restrict network access to Feast APIs.
5. Review authentication logs for unexpected internal identities.
6. Search for unexpected changes to feature views, entities, data sources and RBAC policies.
7. Inspect recent Kubernetes API activity around Feast workloads.
8. Rotate credentials associated with the deployment if unauthorized access is suspected.
9. Treat exposed instances as potentially compromised rather than assuming the issue was theoretical.

At publication time, the public vulnerability records identify 0.66.0 and earlier as affected; the public release page currently shows 0.65.0 as the latest listed release, so administrators should verify the project’s current security-fixed release before upgrading rather than assuming a particular future version.

No CISA KEV listing — yet

There is an important distinction here.

CVE-2026-92787 is critical and has a public technical disclosure and PoC, but current vulnerability data does not show it in CISA’s Known Exploited Vulnerabilities catalog.

So this should not be reported as an actively exploited zero-day.

The more accurate description is:

Critical authentication bypass with public technical details and a demonstrated exploitation path.

That is already bad enough.

Bugstoday’s take

This is the kind of vulnerability that happens when an internal trust mechanism quietly turns into an authentication mechanism.

Feast wanted internal components to communicate without going through the normal authentication path.

Fine.

But then it used a publicly predictable value inside an unsigned JWT to identify those components.

That is not authentication.

That is a string comparison wearing a JWT costume.

CVE-2026-92787 also shows why ML infrastructure deserves serious security review. The model may be perfectly protected while the feature store feeding it has a broken front door.

Patch Feast. Lock down the API. Audit the data.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Feast GitHub security issue #6785 — technical analysis, vulnerable authentication flow and proof of concept.
• CVE-2026-92787 — CVE/NVD vulnerability record and affected versions.
• Feast GitHub repository — source code and project releases.
• GitHub Advisory Database — CVE-2026-92787 publication record.