CVE-2026-92787: Feast JWT Authentication Bypass Vulnerability

CVE-2026-92787 Overview

CVE-2026-92787 is an authentication bypass vulnerability in Feast, an open-source feature store for machine learning, affecting all versions through 0.66.0. The Feast server fails to verify JSON Web Token (JWT) signatures before establishing user identity. Attackers can craft a token with a hardcoded claim value and present it to the server without possessing any signing key.

Once accepted, the forged token grants trusted internal identity. This bypasses all role-based access control (RBAC) and provides unchecked read and write access to entities, feature views, data sources, and permission policies. The weakness is classified under CWE-798: Use of Hard-coded Credentials.

Critical Impact
Unauthenticated network attackers can obtain full administrative control of a Feast feature store, exposing machine learning training data and permitting arbitrary modification of feature definitions and access policies.

Affected Products

Feast (feast-dev) versions through 0.66.0
Deployments using the feast-feature-server Helm chart with OIDC authentication enabled
Feast servers configured with the OIDC token parser (oidc_token_parser.py)

Discovery Timeline

2026-09-16 - CVE-2026-92787 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92787

Vulnerability Analysis

Feast exposes an authenticated feature server that relies on OpenID Connect (OIDC) bearer tokens for identity assertion. The token parser located in sdk/python/feast/permissions/auth/oidc_token_parser.py decodes the JWT payload but does not validate the token signature against the issuer's public keys.

Because signature verification is skipped, any client can forge a JWT with an arbitrary payload. The security_manager.py component then trusts the decoded claims and maps the attacker to an internal role with administrative privileges.

The vulnerability compromises confidentiality, integrity, and availability of the feature store. Attackers can exfiltrate feature data used for model training, poison features to influence downstream ML predictions, and rewrite permission policies to maintain persistence.

Root Cause

The OIDC token parser calls a JWT decode routine with signature verification disabled. The parser reads a claim value that is hardcoded in the deployment template and treats a match as proof of authentication. No cryptographic check binds the token to a trusted issuer, which violates the fundamental JWT trust model and constitutes hardcoded credential use under CWE-798.

Attack Vector

An unauthenticated remote attacker with network access to the Feast server crafts a JWT containing the expected claim value referenced in the Feast deployment template. The attacker signs the token with any key, or uses the none algorithm, and submits it in the Authorization: Bearer header. The server accepts the token, assigns the attacker a trusted identity, and grants full API access.

For technical details on the vulnerable code paths, see the VulnCheck Advisory on Feast and the Feast OIDC Token Parser Code.

Detection Methods for CVE-2026-92787

Indicators of Compromise

Requests to Feast API endpoints containing Authorization: Bearer headers with JWTs signed using the none algorithm or an unknown key ID (kid)
Unexpected creation, modification, or deletion of feature views, entities, data sources, or permission policies
Access to Feast endpoints from IP ranges outside of known ML pipeline infrastructure
Bulk read operations against feature data or metadata endpoints preceding data exfiltration

Detection Strategies

Inspect application logs for JWT decode operations that succeed without a matching issuer key
Correlate Feast API access logs with expected service account identities and alert on deviations
Monitor for administrative API calls (permission policy changes) originating from non-CI/CD sources
Deploy a reverse proxy in front of Feast that independently validates JWT signatures before forwarding requests

Monitoring Recommendations

Forward Feast server logs and Kubernetes audit logs to a centralized SIEM for retention and correlation
Baseline normal feature store API call volume and alert on statistical anomalies
Track outbound network egress from the Feast pod for signs of data exfiltration

How to Mitigate CVE-2026-92787

Immediate Actions Required

Restrict network exposure of the Feast feature server to trusted internal networks and ML pipeline sources using network policies or firewall rules
Disable OIDC authentication on Feast until an upstream fix is applied and rely on network-level access controls
Rotate any secrets, service account tokens, or credentials that may have been exposed to a compromised Feast server
Audit feature views, data sources, and permission policies for unauthorized modifications

Patch Information

At the time of publication, the NVD entry for CVE-2026-92787 does not list a fixed version. Track the Feast Issue #6785 and the Feast GitHub Repository for a release that adds JWT signature verification against the OIDC issuer's JSON Web Key Set (JWKS). Upgrade to the patched version once available.

Workarounds

Place Feast behind an authenticating reverse proxy (for example, an API gateway or service mesh sidecar) that validates JWT signatures against the OIDC provider's JWKS before passing traffic
Enforce mutual TLS (mTLS) between ML clients and the Feast server to require cryptographic client authentication independent of JWT claims
Apply Kubernetes NetworkPolicies to allow ingress to the Feast pod only from authorized namespaces and workloads
Remove the hardcoded claim value from the Helm deployment template and require a live OIDC discovery endpoint

bash

# Example NetworkPolicy restricting ingress to the Feast feature server
# Save as feast-restrict.yaml and apply with: kubectl apply -f feast-restrict.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: feast-restrict-ingress
  namespace: feast
spec:
  podSelector:
    matchLabels:
      app: feast-feature-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              purpose: ml-pipeline
      ports:
        - protocol: TCP
          port: 6566