CVE-2026-18941: TensorFlow no-auth default enables

CISO Take

Feast, the open-source feature store used in ML pipelines and shipped as part of Red Hat OpenShift AI (RHOAI), defaults to "no_auth" across its feature-server, registry-server, and offline-server components, meaning any network-reachable deployment accepts unauthenticated requests out of the box. An attacker with mere network access (AC:L, PR:L, UI:N) can register a malicious User-Defined Function on the feature-server to achieve remote code execution, force re-materialization of every tenant's features to cause a denial of service, or read feature data across tenant boundaries — a serious concern for any shared ML platform. CISA's SSVC decision is TRACK (no urgent action signaled) and EPSS places this in only the 55th percentile with no public exploit or Nuclei template observed yet, but the published CVSS 7.7 (C:H/I:N/A:N) understates real exposure since it scores only the confidentiality path even though the same missing-auth flaw also enables RCE and DoS through legitimate product functionality. With 3,744 downstream dependents and this being a default misconfiguration rather than a patchable code bug, teams running Feast or RHOAI feature-server components should immediately verify an authentication/security manager is explicitly configured before any network exposure, firewall these ports to trusted networks in the interim, and track Red Hat's RHSA-2026:53261/53262/53263 for confirmed fixed builds.

Sources: NVD EPSS CISA KEV OpenSSF ATLAS access.redhat.com

What is the risk?

Rated HIGH severity (CVSS 7.7) but the vector as published only captures the confidentiality (cross-tenant data read) impact; the RCE and DoS paths described in the advisory are not reflected in I:N/A:N, so the practical blast radius is broader than the score suggests. Exploitability is favorable to attackers: no authentication or user interaction is required, complexity is low, and the flaw is a default configuration rather than requiring a code-level exploit chain — any exposed instance is vulnerable out of the box. Offsetting factors: EPSS is moderate (top 55th percentile, not top-tier), there is no CISA KEV listing, no public PoC or Nuclei template exists yet, and CISA SSVC lands at TRACK (lowest urgency tier), suggesting exploitation-in-the-wild has not been observed. The package itself has a respectable OpenSSF Scorecard (7.4/10) and 3,744 downstream dependents, indicating broad reach but also an actively maintained project (last push 2026-08-16) likely to ship a fix quickly. Net assessment: high potential impact, currently low observed exploitation — treat as urgent-to-remediate but not yet a breaking incident.

How does the attack unfold?

Initial Access

Attacker identifies a network-reachable Feast feature-server, registry-server, or offline-server running the default no_auth configuration.

AML.T0049

Malicious UDF Registration

Attacker sends an unauthenticated request to store a malicious User-Defined Function on the feature-server.

AML.T0050

Execution and Disruption

The malicious UDF executes to achieve remote code execution, or the attacker forces repeated re-materialization of all tenant features to cause denial of service.

AML.T0029

Cross-Tenant Data Access

Attacker queries the registry-server or offline-server to read feature data and definitions belonging to other tenants.

AML.T0036

Initial Access

Attacker identifies a network-reachable Feast feature-server, registry-server, or offline-server running the default no_auth configuration.

AML.T0049

Malicious UDF Registration

Attacker sends an unauthenticated request to store a malicious User-Defined Function on the feature-server.

AML.T0050

Execution and Disruption

The malicious UDF executes to achieve remote code execution, or the attacker forces repeated re-materialization of all tenant features to cause denial of service.

AML.T0029

Cross-Tenant Data Access

Attacker queries the registry-server or offline-server to read feature data and definitions belonging to other tenants.

AML.T0036

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
TensorFlow	pip	—	No patch
200.5K OpenSSF 7.5 3.4K dependents Pushed 5d ago 4% patched ~1372d to patch Full package profile →
TensorFlow	pip	—	No patch
200.5K OpenSSF 7.5 3.4K dependents Pushed 5d ago 4% patched ~1372d to patch Full package profile →
TensorFlow	pip	—	No patch
200.5K OpenSSF 7.5 3.4K dependents Pushed 5d ago 4% patched ~1372d to patch Full package profile →
TensorFlow	pip	—	No patch
200.5K OpenSSF 7.5 3.4K dependents Pushed 5d ago 4% patched ~1372d to patch Full 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

7.7 / 10

EPSS

0.8%

chance of exploitation in 30 days

Higher than 56% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I None

A None

What should I do?

1 step

1) Explicitly configure Feast's authentication/authorization (security manager) on feature-server, registry-server, and offline-server — do not rely on defaults. 2) Restrict network access to these endpoints to trusted internal networks/VPCs only; they should never be directly internet-facing. 3) Apply Red Hat's patched builds once available (track RHSA-2026:53261, RHSA-2026:53262, RHSA-2026:53263) and monitor access.redhat.com/security/cve/CVE-2026-18941 for updates. 4) Audit existing UDF registrations on feature-servers for unrecognized or suspicious functions. 5) Monitor for anomalous re-materialization job triggers and unexpected cross-tenant registry queries as detection signals. 6) For RHOAI deployments, inventory which odh-* container images (workbench/pipeline-runtime) are in use and prioritize patching those with network-exposed Feast components.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Code Execution DoS Framework API Training Data AML.T0029 - Denial of AI Service AML.T0036 - Data from Information Repositories AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 - AI system operation and monitoring

NIST AI RMF

GOVERN-1.5 - Policies and procedures for access control of AI system components

Frequently Asked Questions

What is CVE-2026-18941?

Feast, the open-source feature store used in ML pipelines and shipped as part of Red Hat OpenShift AI (RHOAI), defaults to "no_auth" across its feature-server, registry-server, and offline-server components, meaning any network-reachable deployment accepts unauthenticated requests out of the box. An attacker with mere network access (AC:L, PR:L, UI:N) can register a malicious User-Defined Function on the feature-server to achieve remote code execution, force re-materialization of every tenant's features to cause a denial of service, or read feature data across tenant boundaries — a serious concern for any shared ML platform. CISA's SSVC decision is TRACK (no urgent action signaled) and EPSS places this in only the 55th percentile with no public exploit or Nuclei template observed yet, but the published CVSS 7.7 (C:H/I:N/A:N) understates real exposure since it scores only the confidentiality path even though the same missing-auth flaw also enables RCE and DoS through legitimate product functionality. With 3,744 downstream dependents and this being a default misconfiguration rather than a patchable code bug, teams running Feast or RHOAI feature-server components should immediately verify an authentication/security manager is explicitly configured before any network exposure, firewall these ports to trusted networks in the interim, and track Red Hat's RHSA-2026:53261/53262/53263 for confirmed fixed builds.

Is CVE-2026-18941 actively exploited?

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

How to fix CVE-2026-18941?

1) Explicitly configure Feast's authentication/authorization (security manager) on feature-server, registry-server, and offline-server — do not rely on defaults. 2) Restrict network access to these endpoints to trusted internal networks/VPCs only; they should never be directly internet-facing. 3) Apply Red Hat's patched builds once available (track RHSA-2026:53261, RHSA-2026:53262, RHSA-2026:53263) and monitor access.redhat.com/security/cve/CVE-2026-18941 for updates. 4) Audit existing UDF registrations on feature-servers for unrecognized or suspicious functions. 5) Monitor for anomalous re-materialization job triggers and unexpected cross-tenant registry queries as detection signals. 6) For RHOAI deployments, inventory which odh-* container images (workbench/pipeline-runtime) are in use and prioritize patching those with network-exposed Feast components.

What systems are affected by CVE-2026-18941?

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

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

CVE-2026-18941 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.83%.

What is the AI security impact?

Affected AI Architectures

feature storesMLOps pipelinesmulti-tenant ML platformsmodel serving infrastructure

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0036 Data from Information Repositories

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6

NIST AI RMF: GOVERN-1.5

What are the technical details?

Original Advisory

A flaw was found in Feast and feast-operator. The default configuration for both the Feast SDK and the feast-operator is "no_auth," meaning no security manager is installed. This default allows unauthenticated and unauthorized access to feature-server, registry-server, and offline-server endpoints. A remote attacker, by exploiting this missing authentication, could achieve remote code execution (RCE) by storing a malicious User-Defined Function (UDF) on the feature-server, trigger a denial of service (DoS) by forcing re-materialization of all tenant features, and gain unauthorized access to cross-tenant data.

Exploitation Scenario

An attacker scans for internet- or intranet-reachable Feast feature-server instances left in the default no_auth state. Finding one, they send an unauthenticated request to register a malicious User-Defined Function; when the UDF is invoked during normal feature computation, it executes attacker-controlled code on the feature-server host, giving the attacker a foothold in the ML platform. From there, the attacker abuses the same lack of authorization on the offline-server to trigger full re-materialization of all tenants' features repeatedly, exhausting compute resources and degrading or denying feature availability for every tenant sharing the deployment. Separately, the attacker queries the registry-server to enumerate and read feature definitions and values belonging to other tenants, exfiltrating proprietary ML feature data across a supposed tenant isolation boundary.

Weaknesses (CWE)

CWE-306 Missing Authentication for Critical Function

CWE-306 — Missing Authentication for Critical Function: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

[Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.