CVE-2021-41201 — HIGH (CVSS 7.8) AI Security Vulnerability

Q: Is CVE-2021-41201 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2021-41201, increasing the risk of exploitation.

Q: How to fix CVE-2021-41201?

1. Patch: Upgrade to TensorFlow 2.7.0, 2.6.1, 2.5.2, or 2.4.4 immediately—all are available. 2. Inventory: Identify all systems running TF versions < 2.4.4, 2.5.x < 2.5.2, 2.6.x < 2.6.1 using dependency scanners or SBOM tooling. 3. Compensating control: Restrict local access to ML compute nodes; enforce least-privilege on training infrastructure accounts. 4. Container hardening: For containerized TF workloads, enforce seccomp profiles and user namespace isolation to limit privilege escalation paths. 5. Detection: Monitor for anomalous process spawning or memory access violations originating from TensorFlow processes on ML infrastructure.

Q: What systems are affected by CVE-2021-41201?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, ML development environments, shared compute infrastructure.

Q: What is the CVSS score for CVE-2021-41201?

CVE-2021-41201 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.02%.

CISO Take

An uninitialized variable access in TensorFlow's Einsum operation can be triggered by any low-privileged local user, enabling potential code execution with full confidentiality, integrity, and availability impact (CVSS 7.8). ML teams running shared TensorFlow infrastructure—JupyterHub, training clusters, or notebook platforms—should patch to TF 2.7.0, 2.6.1, 2.5.2, or 2.4.4 immediately. No workaround exists beyond patching; restrict local access to ML compute nodes as a compensating control.

Risk Assessment

CVSS 7.8 High with local attack vector, low complexity, and no user interaction makes this readily exploitable by any user with shell or notebook access on the affected host. In shared ML environments—research clusters, data science platforms, multi-tenant Jupyter deployments—the blast radius expands significantly: one compromised low-privilege account can escalate to full process control. Not in CISA KEV and no weaponized exploit publicly reported, but CWE-824 (uninitialized pointer access) is a well-understood exploit class that lowers the bar for skilled attackers.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
tensorflow	pip	—	No patch
195.0K OpenSSF 7.2 3.7K dependents Pushed 6d ago 4% patched ~1372d to patch Full package profile →

Do you use tensorflow? You're affected.

Severity & Risk

CVSS 3.1

7.8 / 10

EPSS

0.0%

chance of exploitation in 30 days

Higher than 6% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, CISA SSVC, EPSS, trickest/cve, and Nuclei templates.

Attack Surface

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

Recommended Action

5 steps

Patch: Upgrade to TensorFlow 2.7.0, 2.6.1, 2.5.2, or 2.4.4 immediately—all are available.
Inventory: Identify all systems running TF versions < 2.4.4, 2.5.x < 2.5.2, 2.6.x < 2.6.1 using dependency scanners or SBOM tooling.
Compensating control: Restrict local access to ML compute nodes; enforce least-privilege on training infrastructure accounts.
Container hardening: For containerized TF workloads, enforce seccomp profiles and user namespace isolation to limit privilege escalation paths.
Detection: Monitor for anomalous process spawning or memory access violations originating from TensorFlow processes on ML infrastructure.

Classification

Code Execution Framework Inference AML.T0010.001 - AI Software AML.T0044 - Full AI Model Access AML.T0049 - Exploit Public-Facing Application

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.8.5 - AI System Security and Resilience

NIST AI RMF

MANAGE 2.7 - Risk Treatment — Vulnerability Management

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2021-41201?

An uninitialized variable access in TensorFlow's Einsum operation can be triggered by any low-privileged local user, enabling potential code execution with full confidentiality, integrity, and availability impact (CVSS 7.8). ML teams running shared TensorFlow infrastructure—JupyterHub, training clusters, or notebook platforms—should patch to TF 2.7.0, 2.6.1, 2.5.2, or 2.4.4 immediately. No workaround exists beyond patching; restrict local access to ML compute nodes as a compensating control.

Is CVE-2021-41201 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2021-41201, increasing the risk of exploitation.

How to fix CVE-2021-41201?

1. Patch: Upgrade to TensorFlow 2.7.0, 2.6.1, 2.5.2, or 2.4.4 immediately—all are available. 2. Inventory: Identify all systems running TF versions < 2.4.4, 2.5.x < 2.5.2, 2.6.x < 2.6.1 using dependency scanners or SBOM tooling. 3. Compensating control: Restrict local access to ML compute nodes; enforce least-privilege on training infrastructure accounts. 4. Container hardening: For containerized TF workloads, enforce seccomp profiles and user namespace isolation to limit privilege escalation paths. 5. Detection: Monitor for anomalous process spawning or memory access violations originating from TensorFlow processes on ML infrastructure.

What systems are affected by CVE-2021-41201?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, ML development environments, shared compute infrastructure.

What is the CVSS score for CVE-2021-41201?

CVE-2021-41201 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.02%.

Technical Details

NVD Description

TensorFlow is an open source platform for machine learning. In affeced versions during execution, `EinsumHelper::ParseEquation()` is supposed to set the flags in `input_has_ellipsis` vector and `*output_has_ellipsis` boolean to indicate whether there is ellipsis in the corresponding inputs and output. However, the code only changes these flags to `true` and never assigns `false`. This results in unitialized variable access if callers assume that `EinsumHelper::ParseEquation()` always sets these flags. The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.

Exploitation Scenario

An adversary with low-privileged access to a shared ML training cluster—compromised data scientist account, malicious insider, or hijacked notebook session—submits a specially crafted Einsum operation that exercises the uninitialized boolean flags in EinsumHelper::ParseEquation(). Because downstream callers assume the flags are always properly set, the undefined state propagates through the computation, triggering memory corruption in the TF C++ runtime. The attacker leverages this to achieve code execution within the TensorFlow process context, then pivots to access co-located model weights, training datasets, or GPU memory containing sensitive computations from other users on the shared node.