CVE-2026-18941: Feast Authentication Bypass Vulnerability

CVE-2026-18941 Overview

CVE-2026-18941 is a missing authentication vulnerability [CWE-306] affecting the Feast feature store SDK and the feast-operator. Both components ship with a default configuration of no_auth, which installs no security manager. This default exposes the feature-server, registry-server, and offline-server endpoints to unauthenticated network access. A remote attacker with low privileges can store a malicious User-Defined Function (UDF) on the feature-server to achieve remote code execution, trigger re-materialization of all tenant features to cause denial of service, or read cross-tenant data.

Critical Impact
Unauthenticated access to Feast servers enables remote code execution via malicious UDFs, cross-tenant data exposure, and denial of service against feature pipelines.

Affected Products

Feast SDK (default no_auth configuration)
feast-operator (default no_auth configuration)
Red Hat OpenShift AI distributions of Feast (see RHSA-2026:53261, RHSA-2026:53262, RHSA-2026:53263)

Discovery Timeline

2026-08-10 - CVE-2026-18941 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-18941

Vulnerability Analysis

Feast is an open-source feature store used to serve machine learning features to models in production. The platform exposes three network services: the feature-server for online feature retrieval, the registry-server for feature metadata, and the offline-server for batch feature access. When deployed with the default no_auth setting, none of these services enforce identity or authorization checks on incoming requests.

The missing authentication allows an attacker with network reachability to interact with any endpoint as if they were a legitimate tenant. Because Feast supports User-Defined Functions to transform features server-side, an attacker can upload a UDF containing arbitrary Python code and have it executed by the feature-server process. The same lack of tenant isolation permits reading feature values belonging to other tenants and issuing materialization requests that force the backend to rebuild every feature view.

Root Cause

The root cause is an insecure default configuration. Both the Feast SDK and feast-operator initialize with no_auth, meaning no security manager is registered and all requests are treated as trusted. Operators who deploy Feast without explicitly overriding this default expose every endpoint to the network without authentication or authorization.

Attack Vector

Exploitation requires network access to a Feast deployment and low privileges as reflected in the CVSS vector. An attacker sends crafted requests directly to the feature-server, registry-server, or offline-server. Three primary abuse paths follow from the same missing-authentication root cause: storing a malicious UDF on the feature-server to obtain code execution, invoking re-materialization on all feature views to exhaust compute and storage, and querying registry or offline endpoints to read cross-tenant feature data. No verified public exploit code is available at publication. Refer to the Red Hat CVE Analysis for further technical detail.

Detection Methods for CVE-2026-18941

Indicators of Compromise

Unexpected UDF registrations or updates in the Feast registry, particularly from unknown client identities or unusual source IP addresses.
Anomalous child processes spawned by the feature-server, such as sh, bash, python -c, or outbound network utilities.
Bulk materialize or materialize-incremental calls that span feature views owned by multiple tenants.
Cross-tenant read patterns on the registry-server or offline-server that do not match documented service accounts.

Detection Strategies

Inspect Feast configuration files and Kubernetes custom resources for auth: no_auth or missing auth_type entries in feast-operator FeatureStore manifests.
Enable request logging on all three servers and alert on requests lacking authenticated principal metadata.
Baseline normal UDF registration frequency and alert on deviations, especially outside change windows.

Monitoring Recommendations

Forward Feast server logs and Kubernetes audit logs to a centralized analytics platform for correlation with process and network telemetry.
Monitor egress from feature-server pods for connections to non-approved destinations that may indicate post-exploitation activity.
Track CPU, memory, and storage usage on materialization backends for spikes consistent with forced re-materialization.

How to Mitigate CVE-2026-18941

Immediate Actions Required

Change the default no_auth setting on every Feast deployment to an authenticated mode such as OIDC or Kubernetes RBAC, as documented by the Feast project.
Restrict network access to feature-server, registry-server, and offline-server using NetworkPolicies, service meshes, or firewall rules until authentication is enforced.
Audit existing UDFs in the registry and remove any that cannot be attributed to a known owner or change request.

Patch Information

Red Hat has released fixes for affected distributions in RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263. Consult the Red Hat CVE Analysis for CVE-2026-18941 and Red Hat Bug Report #2511116 for the specific package versions and configuration guidance that address the missing authentication default.

Workarounds

Configure a security manager by setting an explicit auth block in feature_store.yaml or the feast-operator FeatureStore custom resource, rather than relying on the shipped default.
Place Feast servers behind an authenticating reverse proxy or API gateway that terminates identity before requests reach Feast.
Disable the offline-server and registry-server on internet-reachable networks and expose them only within trusted service-to-service boundaries.

bash

# Example: enable OIDC authentication in feature_store.yaml
auth:
  type: oidc
  client_id: <client-id>
  auth_discovery_url: https://<issuer>/.well-known/openid-configuration