CVE-2026-92787 in Feast
Summary
by MITRE • 09/16/2026
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. Attackers can obtain trusted internal identity and gain unchecked read and write access to all entities, feature views, data sources, and permission policies on the server.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Feast versions prior to 0.66.0 represents a critical authentication bypass stemming from improper validation of JSON Web Tokens (JWT). In this flawed implementation, the application fails to verify the cryptographic signature of incoming JWT tokens before processing them to establish user identity. This fundamental security oversight allows an attacker to construct and submit arbitrary JWTs that contain forged claims without possessing the valid signing key or certificate required by the server. By bypassing the signature verification step, the system treats any presented token as authentic, regardless of its origin or integrity, effectively nullifying the authentication mechanism designed to protect the service.
This technical flaw directly leads to a complete compromise of role-based access control (RBAC) within the Feast environment. Because identity is established based solely on the presence of claims rather than their verified authenticity, an attacker can inject hardcoded claim values that mimic privileged roles or administrative permissions. Consequently, unauthorized users gain trusted internal identity status, which grants them unchecked read and write access to all entities managed by the system. This includes sensitive feature views, underlying data sources, and critical permission policies, allowing for both information disclosure and potential service disruption through malicious modifications.
The operational impact of this vulnerability is severe, as it undermines the core security model of Feast, a platform used for managing machine learning features at scale. Attackers can exfiltrate proprietary training data embedded in feature definitions or alter configuration settings to disrupt ML pipelines. Furthermore, by modifying permission policies, an attacker could escalate privileges further or lock out legitimate administrators. The ability to write to any entity means that malicious actors can inject poisoned feature values into the dataset, potentially compromising the integrity of downstream machine learning models and leading to incorrect predictions in production environments.
From a classification perspective, this issue aligns with CWE-287 Improper Authentication, specifically where authentication credentials are not validated correctly against expected cryptographic standards. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as the attacker utilizes forged but structurally valid tokens to impersonate legitimate users and gain access to resources that should be restricted. The lack of signature verification is a deviation from standard OAuth 2.0 and OIDC best practices, which mandate strict validation of token signatures using public keys or shared secrets before trusting any claims contained within them.
To mitigate this vulnerability, organizations running Feast versions earlier than 0.66.0 must upgrade to the latest patched release immediately where signature verification is enforced as a mandatory step in the authentication pipeline. Until an upgrade can be performed, network-level controls such as API gateways or web application firewalls should be configured to inspect JWTs and reject any tokens that lack valid signatures from trusted issuers. Additionally, implementing strict input validation on token claims and monitoring for unusual access patterns involving high-privilege roles can help detect exploitation attempts in real-time. Regular security audits focusing on authentication flows are recommended to ensure no similar oversights exist in other components of the infrastructure.