CVE-2026-18948: Feast Feature Store RCE Vulnerability

CVE-2026-18948 Overview

CVE-2026-18948 is an insecure deserialization vulnerability in Feast, an open-source feature store for machine learning. The flaw resides in how Feast handles user-defined functions (UDFs) stored in its registry. Feast serializes these UDFs with the dill library and deserializes them without validation. A remote attacker can store a malicious UDF that triggers arbitrary code execution when loaded. In default configurations, the feature server processes these UDFs without authentication, exposing the system to unauthenticated remote code execution. Authenticated attackers can also bypass authorization checks on the registry server. The vulnerability enables cross-tenant data access and lateral movement across the Feast deployment.

Critical Impact
Unauthenticated remote code execution on Feast feature servers in default configurations, enabling cross-tenant data theft and lateral movement.

Affected Products

Feast feature store (feature server component)
Feast registry server (authenticated code execution path)
Red Hat distributions referenced in advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263

Discovery Timeline

2026-08-10 - CVE-2026-18948 published to the National Vulnerability Database
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-18948

Vulnerability Analysis

The vulnerability is an insecure deserialization flaw classified under [CWE-502]. Feast stores user-defined functions inside its registry as serialized Python objects produced by the dill library. When the feature server or registry server retrieves a UDF, it deserializes the stored payload directly into a callable Python object. dill extends pickle and preserves arbitrary code objects, so any attacker-controlled byte stream can execute code during deserialization.

In default Feast deployments, the feature server exposes UDF retrieval and evaluation over the network without authentication. An attacker who can reach the registry, or who can influence the stored UDF payload, achieves remote code execution in the process context of the feature server. On the registry server, authorization checks are performed at the API layer but are bypassed during the deserialization step, so any authenticated tenant can trigger execution outside its intended scope.

The multi-tenant architecture of Feast amplifies the impact. Code executed on shared registry or feature server components exposes feature data belonging to other tenants and enables pivoting into adjacent services such as object stores, databases, and orchestration platforms.

Root Cause

The root cause is the use of dill.loads (or equivalent unpickling routines) on data sourced from a mutable, network-reachable registry. Deserialization is performed before any integrity check, signature verification, or authorization gate is applied to the retrieved object.

Attack Vector

The attack vector is network-based. An unauthenticated attacker writes or influences a malicious serialized UDF in the registry, then triggers its retrieval by any client that queries the feature server. Authenticated attackers targeting the registry server craft a request that references a UDF outside their tenant scope; the deserialization step executes before authorization is enforced. See the Red Hat CVE Analysis for CVE-2026-18948 and Red Hat Bug Tracking Report #2511167 for additional technical detail.

// No verified public exploit code is available.
// The vulnerability is triggered when the feature server
// or registry server calls dill.loads() on an attacker-controlled
// UDF payload retrieved from the Feast registry.

Detection Methods for CVE-2026-18948

Indicators of Compromise

Unexpected child processes spawned by the Feast feature server or registry server process, particularly shells, python -c invocations, or network utilities.
Registry write operations that store UDFs from unusual client identities, source IPs, or outside normal deployment workflows.
Outbound network connections from Feast servers to unfamiliar destinations shortly after UDF retrieval.
Anomalous access to feature data or object storage across tenant boundaries.

Detection Strategies

Inspect registry storage for serialized UDF blobs whose byte patterns include dill/pickle opcodes referencing os, subprocess, builtins, or posix.
Correlate feature server request logs with process-execution telemetry to identify UDF loads that precede suspicious process activity.
Alert on any Feast service process that executes commands not on an approved allowlist for the workload.

Monitoring Recommendations

Enable verbose audit logging on the Feast registry to capture UDF create, update, and read operations with caller identity.
Ship Feast service logs and host process telemetry to a centralized analytics platform for cross-correlation.
Monitor egress traffic from Feast pods or hosts and baseline expected destinations, flagging deviations for review.

How to Mitigate CVE-2026-18948

Immediate Actions Required

Apply the fixed Feast packages distributed through the Red Hat advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263.
Restrict network access to the feature server and registry server so that only trusted clients on internal networks can reach them.
Audit the registry for UDF entries added since deployment and remove any that cannot be traced to a legitimate change.
Rotate credentials, tokens, and keys that were reachable from the Feast service accounts.

Patch Information

Red Hat has released fixed packages under advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263. Refer to the Red Hat CVE Analysis for CVE-2026-18948 for the definitive list of affected components and fixed versions. Upstream Feast users should upgrade to the patched release referenced in the advisories.

Workarounds

Require authentication and authorization on the feature server; do not run it in the default unauthenticated configuration on any reachable network.
Place the registry behind strict network policies that limit both read and write access to a small set of trusted service identities.
Enforce integrity controls on UDFs, such as signing serialized payloads and verifying signatures before deserialization.
Run Feast components under least-privileged service accounts with no ambient access to cross-tenant data or cloud credentials.

bash

# Example: restrict Feast feature server exposure with a Kubernetes NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: feast-feature-server-restrict
spec:
  podSelector:
    matchLabels:
      app: feast-feature-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              trust: internal
          podSelector:
            matchLabels:
              role: feast-client
      ports:
        - protocol: TCP
          port: 6566