CVE-2026-92787

Executive Summary

CVE-2026-92787 is a critical authentication bypass (CWE-798, use of hard-coded credentials / insufficient verification of cryptographic material) in the Feast feature store through version 0.66.0. The server fails to verify JWT token signatures before establishing a caller's identity, so any unauthenticated network attacker can present a forged token with a hardcoded claim value and be trusted as an internal identity. Successful exploitation grants unchecked read and write access to all entities, feature views, data sources, and permission policies, yielding a full compromise of confidentiality and integrity (CVSS 9.8).

Technical Analysis

Feast is an open-source feature store used to serve machine-learning features to online and offline consumers. It exposes a server component (commonly the Feast feature server and the registry/metadata service) that authenticates and authorizes incoming API requests using JSON Web Tokens (JWTs). According to the NVD description, Feast through 0.66.0 "fails to verify JWT token signatures before establishing user identity."

The core defect is a trust-boundary failure in the token-validation logic. A correct JWT validation pipeline must perform, in order: (1) structural parsing, (2) signature verification against a trusted key/issuer, and (3) claim validation (issuer, audience, expiration, permitted values). This vulnerability indicates that the signature-verification step is skipped or not enforced; the server accepts the token's claims at face value and derives the caller's identity and role from unauthenticated, attacker-controlled claim data. Because identity is drawn directly from these unverified claims, the role-based access control (RBAC) layer downstream is rendered ineffective: the server believes the request originates from a trusted internal principal.

The description further states that a "hardcoded claim value" is sufficient to obtain a trusted internal identity. This means the attacker does not need a signing key, a valid credential, or a legitimate session — only the ability to craft a JWT whose relevant claim matches a value the server treats as privileged. This is consistent with CWE-798, which covers reliance on hard-coded secrets/values (here, a fixed claim value used as a trust anchor) and, more broadly, with class-level failures to cryptographically verify authentication tokens.

Because the flaw sits in the identity-establishment path, it applies globally across the server's authorization surface. There is no partial bypass: every entity, feature view, data source, and permission policy the API exposes becomes reachable in read and write mode. This combination of network reachability (AV:N), no privileges required (PR:N), no user interaction (UI:N), and high confidentiality and integrity impact places the vulnerability in the maximum severity band (9.8).

No specific function names, endpoints, file paths, or parameter names are provided in the CVE data, and no patch or advisory detail is available. Accordingly, this report describes the vulnerability at the class and mechanism level and does not fabricate implementation specifics.

Exploitation Scenarios

Note: No public PoC or exploit code is available; the attack chain below is inferred from the vulnerability class (improper JWT signature verification / authentication bypass) and the NVD description. It does not rely on invented endpoints or function names.

1. Reconnaissance / target identification. An attacker identifies an internet- or network-reachable Feast server running version <= 0.66.0. This could be a feature server or a registry/metadata service exposing the authenticated API. Attackers can enumerate such services with Shodan-style queries (e.g., product/http fingerprinting of Feast) and confirm the version where it is disclosed.

2. Triggering the flaw class. The attacker crafts a JWT and presents it as the credential on an API request. Because the server does not verify the token's signature, the token need not be signed by a trusted key. The attacker sets the claim that corresponds to a trusted internal identity (the "hardcoded claim value" referenced in the description) and submits the request. The server parses the claim, treats the caller as authenticated, and establishes a privileged identity.

3. Execution. With the request now attributed to a trusted internal principal, the server performs no further effective authorization check. The attacker issues standard API reads and writes as that identity. No proof-of-possession, password, or signing material is required; exploitation is a single crafted-request action per operation, and success does not depend on user interaction or a prior foothold.

4. Post-exploitation impact. Per the description, the attacker gains "unchecked read and write access to all entities, feature views, data sources, and permission policies on the server." This yields high confidentiality impact (bulk exfiltration of feature data, entity records, datasource configurations, and the permission policy itself) and high integrity impact (planting or modifying entities, feature views, data sources, and permission policies). In an ML feature-store context, unauthorized write access can poison features and data sources consumed by downstream models, and policy modification can entrench or widen the attacker's access.

Impact Assessment

The CVSS 3.1 base score is 9.8 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

• Confidentiality (C:H): Full read access to all entities, feature views, data sources, and permission policies. Feature stores frequently aggregate sensitive production data, so this maps directly to large-scale data disclosure.
• Integrity (I:H): Full write access to the same objects. An attacker can alter feature definitions and data-source configurations and rewrite permission policies, enabling data poisoning and persistent unauthorized access.
• Availability (A:H): The NVD text does not explicitly describe destructive operations, but unchecked write access to server objects and policies carries a plausible availability risk (for example, disabling or corrupting configuration). This is assessed from the description; treat it as a potential consequence of unrestricted write privilege.
• Scope: Unchanged (S:U). Attack vector: Network (AV:N), complexity Low (AC:L), no privileges (PR:N), no interaction (UI:N).

Blast radius: any Feast deployment at or below 0.66.0 that relies on JWT-based authentication is fully exposed to unauthenticated attackers. Because the bypass defeats RBAC globally, all tenants/namespaces sharing the server are in scope. High-value targets include organizations using Feast to serve features to production ML inference, where both the feature data and the integrity of the ML pipeline are at stake.

EPSS is not yet scored by FIRST.org, and CVE-2026-92787 is not listed in CISA KEV. No exploit code or Nuclei template is publicly tracked.

Detection Guidance

Sigma Rule

Detects authentication events where a JWT-based identity is established without signature verification, or where requests carry hardcoded/privileged claim values. Adjust field names to match your Feast access logging.

title: Potential Feast JWT Authentication Bypass (CVE-2026-92787)
id: 3f9a1c2e-7b4d-4a1e-9c6f-1d2e3f4a5b6c
status: experimental
description: Detects requests to a Feast server that establish a trusted identity without JWT signature verification, consistent with CVE-2026-92787.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-92787
author: valtersit.com
date: 2025-01-01
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026-92787
logsource:
  product: feast
  service: auth
detection:
  selection_endpoint:
    http.url|contains:
      - '/feast'
      - '/api'
  selection_bypass:
    jwks:
      - 'none'
      - ''
    signature_verified: false
  selection_hardcoded_claim:
    jwt.claim.role|contains:
      - 'admin'
      - 'internal'
      - 'service'
  condition: selection_endpoint and (selection_bypass or selection_hardcoded_claim)
falsepositives:
  - Legitimate service accounts using trusted internal identities
level: critical

YARA Rule

Hunts for indicators of unverified JWT handling / hardcoded trust values in Feast source or configuration artifacts captured during incident response.

rule CVE_2026_92787_Feast_JWT_Unverified
{
    meta:
        author = "valtersit.com"
        description = "Detects JWT handling that skips signature verification in Feast (CVE-2026-92787)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-92787"
        date = "2025-01-01"
    strings:
        $a1 = "decode(" ascii
        $a2 = "options={\"verify_signature\": False}" ascii wide
        $a3 = "verify_signature" nocase ascii wide
        $b1 = "jwt.decode" ascii wide
        $c1 = "feast" nocase ascii
        $hard = "hardcoded" nocase ascii wide
    condition:
        $c1 and $b1 and (any of ($a*)) or ($c1 and $hard)
}

Suricata IDS Rule

Network detection for API requests carrying a JWT with an unsigned/alg-none or attacker-controlled claim targeting a Feast endpoint. Validate the content pattern against your deployment.

alert http any any -> any any (msg:"CVE-2026-92787 Feast JWT Signature Bypass Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/feast"; http.header; content:"Authorization|3a 20|Bearer"; pcre:"/eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\./"; reference:cve,2026-92787; classtype:attempted-admin; sid:202692787; rev:1;)

Elastic Detection

Detects successful or attempted establishment of a trusted Feast identity without signature verification.

sequence by source.ip with maxspan=5s
  [ network where network.protocol == "http" and url.path : ("*/feast*", "*/api*") and
    http.request.headers.authorization : "Bearer *" ]
  [ network where url.path : ("*/feast*", "*/api*") and
    http.response.status_code == 200 and
    not http.request.headers.authorization : "*verified*" ]

Splunk SPL Query

Identifies Feast authorization events where identity was established from an unverified token or a fixed privileged claim.

index=feast sourcetype=feast:auth
| where match(http_url, "(?i)/feast|/api")
| search (signature_verified="false" OR signature_verified="" OR jwt_claim_role IN ("admin","internal","service"))
| stats count min(_time) as first_seen max(_time) as last_seen values(src_ip) as source_ips values(user_identity) as identities by dest_host
| where count > 0
| sort - count

Wazuh OSSEC Rule

Wazuh rule matching Feast authentication events that bypass signature verification.

<group name="feast,jwt,cve-2026-92787,">
  <rule id="100927" level="12">
    <decoded_as>json</decoded_as>
    <field name="service">feast</field>
    <field name="event">auth</field>
    <field name="signature_verified">false</field>
    <description>CVE-2026-92787: Feast JWT accepted without signature verification - authentication bypass</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100928" level="12">
    <decoded_as>json</decoded_as>
    <field name="service">feast</field>
    <field name="jwt_claim_role">admin|internal|service</field>
    <description>CVE-2026-92787: Feast request with privileged hardcoded JWT claim value</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Affected: Feast through 0.66.0. No vendor fix or workaround is published as of this writing.

1. Immediate mitigations

• Remove Feast servers (feature server, registry/metadata service) from untrusted networks; restrict reachability to trusted internal networks or a VPN/zero-trust gateway. Do not expose Feast's API to the internet while unpatched.
• Place an authenticating reverse proxy or service-mesh authorization layer in front of the Feast server that independently verifies JWT signatures before requests reach Feast, rejecting unsigned or unverifiable tokens.
• If a signature-verifying JWT configuration is available, ensure it is enabled and that the server is configured to reject tokens with "none" or unverified signatures. Verify behavior with controlled test tokens.
• Enforce network segmentation and egress monitoring, monitor for anomalous reads/writes across entities, feature views, data sources, and permission policies, and rotate any long-lived tokens or keys the deployment relies on.
• Treat the server's permission policies and datasource configurations as potentially tampered; review and re-derive them from trusted sources.

2. Patch/upgrade steps

• No patch is currently available. Monitor the upstream Feast project and security advisories for a fixed release beyond 0.66.0, and upgrade immediately once a version that verifies JWT signatures is published.
• Track the NVD entry for CVE-2026-92787 for updates to affected-version data and vendor references.

3. Long-term hardening

• Adopt a fail-closed JWT validation library and enforce signature verification, issuer/audience checks, and claim allowlisting as a mandatory, tested control.
• Eliminate hard-coded trust values and fixed privileged claims; derive identity only from cryptographically verified tokens.
• Add automated regression tests that assert unsigned, alg-none, and tampered-signature tokens are rejected.
• Apply least privilege to service identities and continuously audit RBAC policy changes.

References

• NVD — CVE-2026-92787: https://nvd.nist.gov/vuln/detail/CVE-2026-92787
• CWE-798 — Use of Hard-coded Credentials: https://cwe.mitre.org/data/definitions/798.html
• FIRST.org EPSS (CVE not yet scored): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-92787 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Feast project (upstream source and advisories): https://github.com/feast-dev/feast

Threat actor / exploit-in-the-wild note: No public PoC, exploit code, or Nuclei template is tracked for CVE-2026-92787, and it is not listed in CISA KEV. No threat-actor campaign has been attributed to this vulnerability based on available data.