CVE-2021-37672: TensorFlow heap OOB read

CISO Take

TensorFlow versions prior to 2.6.0 allow local attackers to read out-of-bounds heap memory via malformed arguments to SdcaOptimizerV2, potentially exposing training data or model internals at runtime. Patch immediately to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 — risk is materially higher in shared ML training environments (JupyterHub, SageMaker, internal MLOps platforms) where untrusted users can submit jobs. Not actively exploited in the wild, but the technique is trivial post-disclosure.

What is the risk?

Rated medium (CVSS 5.5) with high confidentiality impact but limited reach due to local access requirement. Risk escalates in multi-tenant ML platforms, shared training clusters, or CI/CD pipelines where multiple users execute TensorFlow code. No CISA KEV entry and no public exploits reported as of patch date, but the vulnerability is well-documented and exploitable with minimal effort once local access is obtained.

What systems are affected?

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

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

5.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I None

A None

What should I do?

5 steps

Upgrade TensorFlow to 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (patch: commit a4e138660270e7599793fa438cd7b2fc2ce215a6).
Audit all TensorFlow deployments for version compliance — include transitive dependencies in ML pipelines.
In shared environments, enforce input validation and tensor shape checks before raw ops reach the execution layer.
Apply least privilege: restrict direct access to tf.raw_ops in production training infrastructure.
Monitor training logs for anomalous tensor shape mismatches as a detection signal.

How is it classified?

Data Extraction Privacy Violation Framework Training Data AML.T0010.001 - AI Software AML.T0025 - Exfiltration via Cyber Means AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2 - AI system risk management

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain the value of deployed AI are managed

OWASP LLM Top 10

LLM03:2025 - Supply Chain

Frequently Asked Questions

What is CVE-2021-37672?

TensorFlow versions prior to 2.6.0 allow local attackers to read out-of-bounds heap memory via malformed arguments to SdcaOptimizerV2, potentially exposing training data or model internals at runtime. Patch immediately to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 — risk is materially higher in shared ML training environments (JupyterHub, SageMaker, internal MLOps platforms) where untrusted users can submit jobs. Not actively exploited in the wild, but the technique is trivial post-disclosure.

Is CVE-2021-37672 actively exploited?

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

How to fix CVE-2021-37672?

1. Upgrade TensorFlow to 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (patch: commit a4e138660270e7599793fa438cd7b2fc2ce215a6). 2. Audit all TensorFlow deployments for version compliance — include transitive dependencies in ML pipelines. 3. In shared environments, enforce input validation and tensor shape checks before raw ops reach the execution layer. 4. Apply least privilege: restrict direct access to tf.raw_ops in production training infrastructure. 5. Monitor training logs for anomalous tensor shape mismatches as a detection signal.

What systems are affected by CVE-2021-37672?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, shared ML platforms, model serving.

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

CVE-2021-37672 has a CVSS v3.1 base score of 5.5 (MEDIUM). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

training pipelinesshared ML platformsmodel serving

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0025 Exfiltration via Cyber Means

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM03:2025

What are the technical details?

Original Advisory

TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can read from outside of bounds of heap allocated data by sending specially crafted illegal arguments to `tf.raw_ops.SdcaOptimizerV2`. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/sdca_internal.cc#L320-L353) does not check that the length of `example_labels` is the same as the number of examples. We have patched the issue in GitHub commit a4e138660270e7599793fa438cd7b2fc2ce215a6. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.

Exploitation Scenario

An attacker with code execution in a shared ML training environment (JupyterHub instance, corporate ML platform, or notebook server) calls tf.raw_ops.SdcaOptimizerV2 with an example_labels tensor deliberately shorter than the declared number of examples. TensorFlow's SDCA implementation reads beyond the allocated buffer boundary, leaking adjacent heap contents. In a multi-tenant setup, leaked memory may include training data batches, encoded feature vectors, or model parameters loaded by other concurrent training jobs — enabling cross-tenant data exfiltration without any elevated privileges.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read

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.