CVE-2026-18948: Feast: insecure UDF deserialization enables RCE

CRITICAL
Published August 10, 2026
CISO Take

Feast, an open-source feature store used to serve real-time features to production ML models, deserializes user-defined functions (UDFs) with Python's dill library — functionally equivalent to unpickling attacker-controlled data — allowing arbitrary code execution the moment the feature server loads a malicious UDF, with no authentication required in the default configuration. This isn't a niche package: it has 3,744 downstream dependents and ships baked into 14 Red Hat OpenShift AI (RHOAI) container images spanning feature servers, pipeline runtimes (PyTorch, TensorFlow), and Jupyter workbenches, so the exposure extends well beyond teams who consciously chose Feast. Current exploitation signals are low — EPSS sits at 0.69%, there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK (lowest urgency) — but the CVSS 9.9 score, unauthenticated network-exploitable RCE, and cross-tenant lateral movement potential in shared MLOps clusters make this a priority patch rather than a monitor-and-wait item. Apply the Red Hat errata (RHSA-2026:53261/53262/53263) for affected RHOAI images now, and in the interim block network access to feature servers and lock down who can write UDFs to the registry.

Sources:NVDEPSSaccess.redhat.combugzilla.redhat.comATLASOpenSSF

What is the risk?

Technically this is about as severe as it gets: CVSS 9.9, network vector, low complexity, no user interaction, and the feature server path requires zero authentication by default. The registry server has an added authenticated bypass path, meaning even a low-privilege authenticated user can reach the same deserialization primitive. Actual exploitation likelihood right now is low (EPSS 0.69%, no PoC, no KEV, SSVC=TRACK), which suggests this hasn't been weaponized yet — but insecure deserialization via dill/pickle is a well-understood, easily-weaponized bug class, so a working exploit could appear quickly once researchers or attackers focus on it. The scope-changed CVSS vector (S:C) reflects the cross-tenant/lateral-movement risk explicitly called out in the advisory, which raises the practical severity for any shared or multi-tenant MLOps deployment.

How does the attack unfold?

Malicious UDF submission
Attacker with registry write access, or one who bypasses registry-server authorization checks, stores a dill-serialized UDF embedding malicious code in the Feast registry.
AML.T0011.000
Deserialization triggers RCE
The unauthenticated feature server loads and deserializes the malicious UDF via dill during normal feature computation, executing the attacker's code.
AML.T0050
Cross-tenant pivot
Using code execution on the feature server, the attacker accesses shared credentials or service accounts to move laterally into other tenants' data and pipelines.
AML.T0012
Data compromise and persistence
The attacker exfiltrates feature/training data across tenants and establishes a foothold elsewhere in the multi-tenant ML platform.
AML.T0025

What systems are affected?

PackageEcosystemVulnerable RangePatched
TensorFlowpip—No patch
201.4KOpenSSF 7.93.4K dependentsPushed 5d ago4% patched~1372d to patchFull package profile →
TensorFlowpip—No patch
201.4KOpenSSF 7.93.4K dependentsPushed 5d ago4% patched~1372d to patchFull package profile →
TensorFlowpip—No patch
201.4KOpenSSF 7.93.4K dependentsPushed 5d ago4% patched~1372d to patchFull package profile →
TensorFlowpip—No patch
201.4KOpenSSF 7.93.4K dependentsPushed 5d ago4% patched~1372d to patchFull package profile →
rhoai/odh-feature-server-rhel9——No patch
rhoai/odh-pipeline-runtime-datascience-cpu-py312-rhel9——No patch
rhoai/odh-pipeline-runtime-pytorch-cuda-py312-rhel9——No patch
rhoai/odh-pipeline-runtime-pytorch-llmcompressor-cuda-py312-rhel9——No patch
rhoai/odh-pipeline-runtime-pytorch-rocm-py312-rhel9——No patch
rhoai/odh-workbench-codeserver-datascience-cpu-py312-rhel9——No patch
rhoai/odh-workbench-jupyter-datascience-cpu-py312-rhel9——No patch
rhoai/odh-workbench-jupyter-pytorch-cuda-py312-rhel9——No patch
rhoai/odh-workbench-jupyter-pytorch-llmcompressor-cuda-py312-rhel9——No patch
rhoai/odh-workbench-jupyter-pytorch-rocm-py312-rhel9——No patch

How severe is it?

CVSS 3.1
9.9 / 10
EPSS
1.1%
chance of exploitation in 30 days
Higher than 66% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRLow
UINone
SChanged
CHigh
IHigh
AHigh

What should I do?

1 step
  1. Patch: apply the relevant Red Hat errata (RHSA-2026:53261, RHSA-2026:53262, RHSA-2026:53263) for affected RHOAI container images immediately; non-Red Hat Feast deployments should track upstream Feast release notes for the equivalent fix. Workaround: never expose feature servers directly to untrusted networks — require authentication/mTLS in front of them even though the app itself doesn't enforce it by default; restrict UDF registration and registry write access to a tightly-controlled, trusted set of service accounts; review registry authorization logic for the bypass path described in the advisory. Detection: audit the Feast registry for UDFs registered by unexpected principals or outside normal CI/CD workflows; monitor feature-server processes for unexpected child processes or outbound network connections consistent with a reverse shell; inventory RHOAI image versions across clusters and flag any pre-patch tags. Longer term: evaluate replacing dill/pickle-based UDF serialization with a safe, non-executable format, or run UDF deserialization in a sandboxed/isolated execution context.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15-Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.6-AI system security controls
NIST AI RMF
MEASURE 2.7-AI system security and resilience are evaluated and documented

Frequently Asked Questions

What is CVE-2026-18948?

Feast, an open-source feature store used to serve real-time features to production ML models, deserializes user-defined functions (UDFs) with Python's dill library — functionally equivalent to unpickling attacker-controlled data — allowing arbitrary code execution the moment the feature server loads a malicious UDF, with no authentication required in the default configuration. This isn't a niche package: it has 3,744 downstream dependents and ships baked into 14 Red Hat OpenShift AI (RHOAI) container images spanning feature servers, pipeline runtimes (PyTorch, TensorFlow), and Jupyter workbenches, so the exposure extends well beyond teams who consciously chose Feast. Current exploitation signals are low — EPSS sits at 0.69%, there's no public PoC or Nuclei template, it's not in CISA KEV, and CISA's own SSVC decision is TRACK (lowest urgency) — but the CVSS 9.9 score, unauthenticated network-exploitable RCE, and cross-tenant lateral movement potential in shared MLOps clusters make this a priority patch rather than a monitor-and-wait item. Apply the Red Hat errata (RHSA-2026:53261/53262/53263) for affected RHOAI images now, and in the interim block network access to feature servers and lock down who can write UDFs to the registry.

Is CVE-2026-18948 actively exploited?

No confirmed active exploitation of CVE-2026-18948 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-18948?

Patch: apply the relevant Red Hat errata (RHSA-2026:53261, RHSA-2026:53262, RHSA-2026:53263) for affected RHOAI container images immediately; non-Red Hat Feast deployments should track upstream Feast release notes for the equivalent fix. Workaround: never expose feature servers directly to untrusted networks — require authentication/mTLS in front of them even though the app itself doesn't enforce it by default; restrict UDF registration and registry write access to a tightly-controlled, trusted set of service accounts; review registry authorization logic for the bypass path described in the advisory. Detection: audit the Feast registry for UDFs registered by unexpected principals or outside normal CI/CD workflows; monitor feature-server processes for unexpected child processes or outbound network connections consistent with a reverse shell; inventory RHOAI image versions across clusters and flag any pre-patch tags. Longer term: evaluate replacing dill/pickle-based UDF serialization with a safe, non-executable format, or run UDF deserialization in a sandboxed/isolated execution context.

What systems are affected by CVE-2026-18948?

This vulnerability affects the following AI/ML architecture patterns: feature stores, MLOps pipelines, model serving, training pipelines, multi-tenant ML platforms.

What is the CVSS score for CVE-2026-18948?

CVE-2026-18948 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 1.08%.

What is the AI security impact?

Affected AI Architectures

feature storesMLOps pipelinesmodel servingtraining pipelinesmulti-tenant ML platforms

MITRE ATLAS Techniques

AML.T0010.001AI Software
AML.T0011.000Unsafe AI Artifacts
AML.T0012Valid Accounts
AML.T0050Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.6
NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

A flaw was found in Feast. The system improperly deserializes user-defined functions (UDFs) stored in its registry, which are serialized using the 'dill' library. This allows a remote attacker to store a malicious UDF, leading to unauthenticated arbitrary code execution on the feature server in default configurations. An authenticated attacker can also achieve arbitrary code execution on the registry server by bypassing authorization checks during deserialization. This vulnerability can result in cross-tenant data access and lateral movement within the system.

Exploitation Scenario

An attacker who can write to the Feast registry — either directly (compromised CI/CD credentials, insider access) or by exploiting the authorization bypass on the registry server — crafts a UDF object serialized with dill that embeds a malicious payload (e.g., a reverse shell command executed during unpickling). They store this UDF in the registry disguised as a legitimate feature transformation. When the feature server, which requires no authentication in its default configuration, next loads that UDF to compute on-demand features for a live model inference request, the dill deserializer executes the attacker's code, granting full remote code execution on the feature-serving host. From there, because feature servers and RHOAI pipeline runtimes often run in shared, multi-tenant Kubernetes clusters with mounted service-account credentials, the attacker pivots laterally — reading other tenants' feature data, stealing cloud IAM tokens, or compromising adjacent pipeline runtime pods — turning a single UDF write into a cross-tenant breach.

Weaknesses (CWE)

CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.

  • [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
  • [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

References

Timeline

Published
August 10, 2026
Last Modified
September 28, 2026
First Seen
August 11, 2026

Related Vulnerabilities