CVE-2021-41205: TensorFlow: heap OOB read in quantize ops, DoS+leak

HIGH PoC AVAILABLE
Published November 5, 2021
CISO Take

Any TensorFlow deployment using quantized models (INT8, edge/mobile) on versions prior to 2.7.0/2.6.1/2.5.2/2.4.4 is vulnerable to heap out-of-bounds reads via malformed shape inference inputs. In multi-tenant ML platforms or shared Jupyter environments, a low-privileged user can crash the TF process or extract heap memory. Patch immediately; this is a trivial crash for anyone who can submit computation graphs.

What is the risk?

CVSS 7.1 (High) with local attack vector and low privilege requirement makes this high severity for shared ML infrastructure. Single-user local installations carry limited exposure, but multi-tenant training platforms, MLflow/Kubeflow environments, and notebook servers where users submit arbitrary graphs face meaningful risk. Not in CISA KEV and no confirmed in-the-wild exploitation, but the low complexity and no-interaction-required profile make it attractive for insider threat or compromised pipeline scenarios.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
TensorFlow pip No patch
195.8K OpenSSF 7.1 3.7K dependents Pushed 3d ago 4% patched ~1372d to patch Full package profile →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1
7.1 / 10
EPSS
0.1%
chance of exploitation in 30 days
Higher than 4% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Moderate
Exploitation Confidence
medium
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Local
AC Low
PR Low
UI None
S Unchanged
C High
I None
A High

What should I do?

5 steps
  1. Patch: Upgrade TensorFlow to 2.7.0, or apply cherrypick to 2.6.1, 2.5.2, or 2.4.4.

  2. Audit: Identify all environments running QuantizeAndDequantize* ops with untrusted or user-supplied graph inputs.

  3. Isolation: In multi-tenant platforms, sandbox graph execution (separate processes/containers per user) to contain blast radius.

  4. Detection: Monitor for TF process crashes or segfaults originating from shape_inference paths; log inputs to quantize ops for anomaly detection.

  5. Validation: Add shape validation gates before passing tensors to quantization ops as a defense-in-depth measure.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 9 - Risk management system
ISO 42001
A.6.2.6 - AI system vulnerability management
NIST AI RMF
MANAGE-2.2 - Treatment of identified AI risks
OWASP LLM Top 10
LLM05:2025 - Improper Output Handling / Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2021-41205?

Any TensorFlow deployment using quantized models (INT8, edge/mobile) on versions prior to 2.7.0/2.6.1/2.5.2/2.4.4 is vulnerable to heap out-of-bounds reads via malformed shape inference inputs. In multi-tenant ML platforms or shared Jupyter environments, a low-privileged user can crash the TF process or extract heap memory. Patch immediately; this is a trivial crash for anyone who can submit computation graphs.

Is CVE-2021-41205 actively exploited?

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

How to fix CVE-2021-41205?

1. Patch: Upgrade TensorFlow to 2.7.0, or apply cherrypick to 2.6.1, 2.5.2, or 2.4.4. 2. Audit: Identify all environments running QuantizeAndDequantize* ops with untrusted or user-supplied graph inputs. 3. Isolation: In multi-tenant platforms, sandbox graph execution (separate processes/containers per user) to contain blast radius. 4. Detection: Monitor for TF process crashes or segfaults originating from shape_inference paths; log inputs to quantize ops for anomaly detection. 5. Validation: Add shape validation gates before passing tensors to quantization ops as a defense-in-depth measure.

What systems are affected by CVE-2021-41205?

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

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

CVE-2021-41205 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingmodel compression pipelinesmulti-tenant ML platforms

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0025 Exfiltration via Cyber Means
AML.T0029 Denial of AI Service

Compliance Controls Affected

EU AI Act: Article 9
ISO 42001: A.6.2.6
NIST AI RMF: MANAGE-2.2
OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

TensorFlow is an open source platform for machine learning. In affected versions the shape inference functions for the `QuantizeAndDequantizeV*` operations can trigger a read outside of bounds of heap allocated array. 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 attacker with low-privilege access to a shared ML training cluster submits a TensorFlow computation graph containing a QuantizeAndDequantizeV2 op with deliberately malformed shape metadata. During graph execution, the shape inference function reads beyond the allocated heap buffer. In a DoS scenario, this crashes the TF worker process, disrupting training jobs for all users. In an information disclosure scenario, the out-of-bounds read returns heap data from adjacent allocations, potentially leaking model parameters, API keys stored in memory, or other tenant data — relevant in SaaS platforms that process multiple customers' models in shared environments.

Weaknesses (CWE)

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

  • [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
  • [Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
November 5, 2021
Last Modified
November 21, 2024
First Seen
November 5, 2021

Related Vulnerabilities