CVE-2026-18948: Feast Unsafe UDF Deserialization Bug - What It Means for Your Business and How to Respond

Introduction

CVE-2026-18948 is a critical security vulnerability affecting Feast, an open-source feature store commonly used to operationalize machine learning data for analytics, recommendation engines, fraud detection, and other artificial intelligence workloads. If your organization runs Feast directly, uses it within a managed or containerized AI platform, or operates Red Hat OpenShift AI environments that include the affected component, this issue deserves prompt executive and technical review.

The risk is not limited to a single application outage. Successful exploitation can give an attacker the ability to run unauthorized commands in parts of your AI infrastructure, potentially exposing data, interrupting production services, or providing a foothold for movement into connected systems. The issue is particularly important for shared or multi-team AI platforms, where a compromise may extend beyond one project or workload.

This post explains the business implications, practical exposure checks, realistic scenarios, and response priorities. A technical appendix follows for security engineers, platform owners, and penetration testers.

Background & History

CVE-2026-18948 was published on August 10, 2026, after being reported through Red Hat’s security process. The issue affects Feast, an open-source feature store that helps organizations manage and serve machine learning features. Red Hat is the CVE Naming Authority source for the vulnerability, and the National Vulnerability Database lists the record as awaiting further enrichment.

The vulnerability received a Critical severity rating of 9.9 out of 10 under the Common Vulnerability Scoring System. In plain language, Feast can treat stored user-defined functions as trusted when it processes them, even though those functions may have been altered or supplied by an attacker. That unsafe handling can permit unauthorized code to run within Feast services.

The underlying issue was reported in Red Hat Bugzilla on August 4, 2026. Red Hat’s public CVE record identifies impacts on Feast deployments in Red Hat OpenShift AI, while the NVD record was last modified on August 27, 2026. Organizations should follow applicable vendor advisories and determine their specific deployed package and platform exposure rather than relying only on upstream version labels.

What This Means for Your Business

For your business, CVE-2026-18948 can turn an AI data-management component into an entry point for a broader compromise. In default Feast configurations described by Red Hat, an external attacker may be able to cause unauthorized code to run on the feature server. In environments where authentication is enabled, an authenticated user may still exploit an authorization weakness to run code on the registry server.

That creates four material business risks:

• Operational disruption: An attacker could interfere with the services that supply data to machine learning models, affecting fraud screening, customer personalization, demand forecasting, or other production processes.
• Data exposure: Because feature stores often aggregate customer, transaction, product, and behavioral data, compromise can create a path to sensitive information. In multi-tenant deployments, one team’s workload may affect another team’s data environment.
• Reputational harm: Customers and business partners expect AI systems to be governed with the same rigor as core applications. A breach involving an AI platform can undermine confidence in both data protection and model reliability.
• Compliance impact: Depending on your sector and data types, an incident could trigger notification, audit, contractual, privacy, or regulatory obligations in the United States and Canada.

This is not solely an information technology concern. You should treat the affected feature-store environment as part of your production data and application estate, with accountable ownership, access controls, monitoring, and tested incident response procedures.

Real-World Examples

A regional bank: A regional bank uses machine learning features to support fraud scoring and customer-risk analysis. If an attacker compromises the Feast feature-serving environment, they could disrupt data supplied to fraud models or access connected systems and sensitive data, forcing the bank to investigate transaction integrity, customer notification obligations, and service continuity.

A mid-sized retailer: A retailer uses Feast to deliver features for product recommendations, inventory planning, and pricing analytics. An incident could interrupt recommendation services during a high-volume sales period, reduce conversion performance, and create unplanned work for data, platform, security, and customer-support teams.

A healthcare technology provider: A healthcare technology provider runs shared AI infrastructure for several internal products. A compromise in one Feast project could expose weaknesses in tenant separation, creating risk that data or workloads associated with other internal teams become reachable. The resulting investigation may involve contractual requirements, privacy assessments, and validation that affected analytics outputs were not manipulated.

A software-as-a-service company: A growing software-as-a-service provider allows multiple engineering teams to publish machine learning features. If registry write permissions are too broad, a compromised developer account could become a more serious platform incident, potentially enabling unauthorized activity under a service account and allowing movement to connected cloud resources.

Am I Affected?

• You may be affected if you operate Feast as part of a production, staging, or development machine learning platform.
• You may be affected if you use Red Hat OpenShift AI 2.25, 3.3, or 3.4 packages that include the vulnerable Feast component and have not confirmed the vendor-provided fixed build status.
• You should investigate immediately if a shared Feast feature server supports more than one project, tenant, business unit, or customer environment.
• You may be at elevated risk if Feast authentication is disabled, especially where the default configuration permits unauthenticated access to relevant services.
• You should investigate if users, automated pipelines, or external systems can write to the Feast registry or submit user-defined functions.
• You may be affected even when authentication is enabled, because Red Hat reports that an authenticated principal can bypass authorization checks during registry-server deserialization.
• You should not assume that a scanner result alone is conclusive, because vendor backports can make package-version-only checks inaccurate. Confirm against the relevant Red Hat advisory and installed package metadata.

Key Takeaways

• CVE-2026-18948 is a Critical Feast vulnerability with a reported CVSS score of 9.9, making it a high-priority issue for organizations operating affected AI feature-store environments.
• The vulnerability can enable unauthorized code execution and may expose data, disrupt machine learning-dependent operations, and create opportunities for movement into connected systems.
• Shared AI platforms require particular attention because a compromised feature-serving component may create cross-tenant or cross-project risk.
• You should identify Feast and Red Hat OpenShift AI deployments, verify actual package and advisory status, and review who can write to the registry.
• Vendor remediation should be your first choice, with stronger authentication and deny-by-default registry-write controls used immediately where patching cannot occur at once.

Call to Action

CVE-2026-18948 is a reminder that AI infrastructure requires the same disciplined security validation as your customer-facing applications and core cloud services. IntegSec can help you identify exposed Feast services, validate access-control boundaries, test realistic attack paths, and prioritize remediation based on your business risk. A focused penetration test can reveal whether a configuration weakness becomes a practical route to data exposure or platform compromise. Contact IntegSec to strengthen your AI environment and reduce cybersecurity risk with evidence-based testing.

Technical Appendix

A — Technical Analysis

CVE-2026-18948 is an unsafe deserialization flaw in Feast’s handling of registry-stored Python user-defined functions. Feast serializes user-defined functions with the dill library and consumers deserialize the stored function bodies with dill.loads(). Because dill extends Python pickle semantics, deserializing attacker-controlled content can invoke attacker-controlled behavior, including through Python’s __reduce__ mechanism.

The affected code paths include transformations associated with pandas, Python, Substrait, Ray, stream feature views, and profiling functionality. Red Hat describes two primary paths: unauthenticated remote code execution on the feature-server pod under default configurations, and code execution on the registry-server pod by an authenticated principal when deserialization occurs before authorization enforcement.

The assigned CVSS v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, corresponding to network reachability, low attack complexity, low privileges, no user interaction, changed scope, and high confidentiality, integrity, and availability impacts. The NVD references CWE-502, Deserialization of Untrusted Data.

B — Detection & Verification

Package and deployment enumeration: Engineers should inventory Feast deployments, associated feature-server and registry-server workloads, and Red Hat OpenShift AI installations. In Kubernetes and OpenShift environments, begin with commands such as:

Configuration review: Verify the effective Feast configuration, including whether auth.type: kubernetes is enforced and whether registry writes are denied by default. Review deployment manifests, ConfigMaps, Helm values, and operator-generated resources rather than relying only on repository defaults. Red Hat specifically recommends Kubernetes authentication and deny-by-default registry writes as mitigation.

Log indicators: Review feature-server and registry-server logs for unexpected registry updates, unusual user-defined function processing, failed authorization events near registry changes, and unexpected process execution or outbound connections from service pods.

Behavioral anomalies: Investigators should prioritize sudden workload restarts, unknown processes in Feast containers, new Kubernetes API activity from Feast service accounts, unusual secret access, or unexpected network connections from feature-serving infrastructure.

Network indicators: Monitor ingress requests and internal traffic to Feast application programming interfaces for unexpected registry-write operations, unusually large serialized payloads, or calls from unfamiliar identities. Correlate these events with subsequent feature-server refreshes or online-feature requests.

C — Mitigation & Remediation

1. Immediate (0–24h): Identify all Feast and Red Hat OpenShift AI deployments, then apply the official vendor patch or updated supported package as soon as change-control procedures permit. Prioritize internet-accessible, shared, production, and data-sensitive environments. Restrict external exposure to feature-server and registry-server interfaces, and rotate potentially exposed secrets if there are signs of compromise.
2. Short-term (1–7d): Enforce auth.type: kubernetes through the operator-generated Feast configuration and deny registry writes by default, as recommended by Red Hat. Limit registry-write permissions to narrowly scoped, trusted deployment identities. Remove broad developer, service-account, and pipeline permissions; verify that registry operations are logged; and segment feature-store workloads from sensitive data stores and cloud control-plane services.
3. Long-term (ongoing): Replace unsafe serialized-function patterns where practical. The reported remediation direction includes using source-string handling with restricted execution or Substrait-only transformation modes rather than deserializing arbitrary dill objects. Ensure authorization checks occur before processing untrusted registry content, and establish a secure review process for feature definitions and transformation code.
4. Interim controls when patching is delayed: Block or tightly restrict registry writes, disable unneeded on-demand feature views and user-defined function workflows, require authenticated access, isolate Feast pods with network policies, and apply least-privilege service accounts. These actions reduce exposure but do not replace vendor remediation. Validate controls with authenticated testing before declaring the environment safe.

D — Best Practices

• Treat registry-write access as code-execution-equivalent access because a stored user-defined function can be processed by Feast services.
• Do not deserialize untrusted Python objects with dill, pickle-compatible libraries, or similar mechanisms in production control paths.
• Enforce authentication and least-privilege authorization for feature-store administration, deployment pipelines, and registry modification.
• Separate tenants, projects, and service accounts so that one compromised workload cannot easily access another workload’s data or platform permissions.
• Monitor registry changes, service-account activity, process launches, and egress from AI platform pods, then test detection logic through controlled security exercises