Why is dill deserialization dangerous in the context of Feast UDFs?

Dill is a Python library that extends pickle to serialize complex objects including closures and lambdas. Like pickle, dill deserialization executes code embedded in the serialized payload via the __reduce__ method. Feast stores User-Defined Functions (UDFs) in its registry using dill serialization. When the feature server loads a UDF, it calls dill.loads() on the stored bytes. An attacker who can write a malicious payload to the registry — either by compromising a registry-writing account or, in default configurations, without authentication — gets arbitrary code execution on every host that deserializes the UDF.

Does CVE-2026-18948 require authentication to exploit?

It depends on the deployment configuration. In default Feast configurations, the feature server can load UDFs from a registry without requiring authentication on the feature serving path. An unauthenticated attacker can trigger deserialization on the feature server simply by crafting a request that causes it to fetch and execute a malicious UDF. Exploiting the registry server directly requires authenticated access, but even an authenticated low-privileged user achieves RCE because authorization checks are not performed before deserialization. The CVSS 9.9 score reflects the worst-case unauthenticated vector with Scope:Changed, meaning the vulnerable component affects other systems.

What did CVE-2026-23537 fix in Feast 0.59.0?

CVE-2026-23537 was an unauthenticated arbitrary file write via the /save-document endpoint on the Feast feature server. The endpoint accepted a filename parameter and wrote arbitrary content to disk without restricting the write path to a safe directory. By traversing with ../ sequences or providing an absolute path, an attacker could overwrite Feast configuration files, startup scripts, or any file the server process had write access to. Overwriting a script executed on restart is a straightforward path to persistent code execution. Feast 0.59.0, released in late July 2026, added path canonicalization and directory allowlisting to the endpoint.

Feast Feature Store: Two Critical Flaws Enable Unauthenticated RCE

Two critical vulnerabilities disclosed in July and August 2026 put Feast, the most widely deployed open-source ML feature store, in a difficult position: both flaws are unauthenticated in default configurations, both lead to code execution, and together they cover the full attack surface of a typical Feast deployment.

CVE-2026-18948 carries a CVSS score of 9.9 with Scope:Changed. CVE-2026-23537 scores 9.1. Neither requires a sophisticated attacker.

What Feast Is and Why It Matters

Feast (Feature Store) is an open-source project originally developed at Gojek and now maintained under the Linux Foundation’s LF AI & Data umbrella. It’s the glue layer between data engineering and model serving: data teams define feature transformations, store computed values in an online store, and ML models retrieve low-latency features at inference time.

In production ML environments, the feature server sits in a critical position. It holds connections to the online store (Redis, DynamoDB, Bigtable), receives inference-time requests, and executes feature transformations on live data. Compromise of the feature server means access to real-time production data — often the same customer records the model uses to make decisions.

User-Defined Functions (UDFs) are a Feast capability that lets data teams register custom transformation logic in the registry. The feature server loads and executes these UDFs at serving time. The storage and retrieval mechanism for UDFs is where CVE-2026-18948 originates.

CVE-2026-18948: Dill Deserialization to RCE

Feast stores UDFs in its registry using Python’s dill library, an extension of pickle designed to handle closures, lambdas, and other objects that pickle cannot serialize. The registry path looks simple: a data team registers a UDF, dill serializes it, and the bytes go into the registry store. When the feature server needs the UDF, it fetches the bytes and calls dill.loads().

The fundamental problem is that dill.loads() is code execution, not data retrieval. Dill’s deserialization invokes __reduce__ methods embedded in the serialized payload. A malicious payload can call subprocess.Popen, os.execv, or any other callable during the loads operation. There is no sandboxing, no signature verification, and no allowlisting of safe UDF types. The feature server unconditionally executes whatever the registry contains.

The unauthenticated vector. In default Feast configurations, the feature server exposes serving endpoints that trigger UDF loading without requiring the caller to authenticate. An attacker who can write a malicious UDF payload to the registry — and then trigger the feature server to load it — achieves code execution on the feature server without any credentials. The CVSS vector reflects this: AV:Network, AC:Low, PR:Low, UI:None, S:Changed, C:High, I:High, A:High. The Scope:Changed rating indicates that a vulnerable registry component affects the separate feature server component.

The authenticated registry path. Against the registry server directly, exploitation requires authenticated access — a low bar in organizations that grant registry write access to data engineering teams broadly. An authenticated attacker can register a malicious UDF and trigger its execution on the registry server during processing. The authorization check occurs after the deserialization call, not before, so the registered UDF executes before any permission decision is made.

Cross-tenant implications. In multi-tenant Feast deployments, the registry is shared infrastructure. A malicious UDF registered by one team can execute in the context of another team’s feature server requests. The Red Hat advisory explicitly notes cross-tenant data access as a consequence, which elevates the practical impact beyond the CVSS base score for organizations running shared feature stores.

CVE-2026-23537: Arbitrary File Write via /save-document

Disclosed on July 9, 2026, this vulnerability predates CVE-2026-18948 and was fixed in Feast 0.59.0, released in late July. Organizations still running older versions are exposed to both flaws simultaneously.

The Feast feature server exposes a /save-document endpoint intended for internal document management within the serving infrastructure. The endpoint accepted a user-controlled filename parameter and wrote request body content to disk at the specified path. There was no restriction to a safe directory, no path canonicalization, and no authentication requirement.

An attacker who could reach the endpoint could:

Write to arbitrary paths that the Feast process has filesystem access to, including application configuration directories
Use ../ traversal sequences to escape any intended working directory
Specify absolute paths directly

The practical exploitation path is overwriting a configuration file or startup script and waiting for a restart. On Kubernetes deployments, Feast pods restart automatically on health check failure — triggering a restart to execute an overwritten script is a low-effort follow-on step.

This vulnerability does not require a deserialization primitive or any special knowledge of Feast internals. The attack surface is a simple HTTP POST with a path and content body.

Combined Attack Surface Assessment

The two CVEs cover Feast’s attack surface from different angles.

CVE-2026-23537 provides a file write primitive with no authentication. CVE-2026-18948 provides code execution through the ML-specific UDF loading path. In environments running unpatched versions of both (any Feast release before 0.59.0), an attacker with network access to the feature server has multiple independent paths to code execution.

The risk is compounded by how Feast deployments are typically positioned. Feature servers are frequently deployed inside the ML platform perimeter, treated as internal infrastructure with limited exposure to the public internet. This reasoning leads to relaxed security controls: no WAF, minimal access logging, and authentication skipped because “it’s internal.” Network-reachable means exploitable, regardless of the intended exposure level. Sysdig’s 2025 AI threat landscape report found that 34% of ML serving endpoints in surveyed enterprise environments were reachable from other internal network segments beyond their intended scope.

Remediation

Upgrade. The only complete remediation for CVE-2026-23537 is upgrading to Feast 0.59.0 or later, which adds path canonicalization and directory allowlisting to the /save-document endpoint.

For CVE-2026-18948, the underlying root cause — dill.loads() on untrusted data — is architectural. The Feast maintainers have acknowledged the issue and are working on a registry signing mechanism that would allow feature servers to verify UDF payloads before deserialization. Until that fix ships, mitigations are network-level rather than code-level.

Restrict the feature server network exposure. Feature servers should not be reachable from network segments where untrusted parties operate. Verify that network policies, security groups, or firewall rules limit access to expected callers — the inference pipeline, not arbitrary internal hosts.

Restrict registry write access. Limit which identities can write to the Feast registry. In default deployments this is often too permissive. Treat registry write access as equivalent to code execution on every feature server in the deployment.

Audit registry UDF contents. Examine registered UDFs for unexpected entries or entries registered by unexpected identities. Dill-serialized payloads are not human-readable, but their registry metadata (registration time, registering user) should be auditable. Entries that don’t correspond to known data engineering work warrant investigation.

Add authentication at the proxy layer. For CVE-2026-18948’s unauthenticated vector, deploying an authenticating reverse proxy (Envoy, nginx, or a service mesh sidecar) in front of the feature server adds a control layer while the upstream fix is in progress.

Audit restart triggers. For CVE-2026-23537 exposure, review what restart mechanisms the Feast deployment uses and whether any configuration files or startup scripts are writable by the process. Kubernetes liveness probes and readiness probes that trigger pod restarts are worth examining in this context.