CVE-2021-37664: TensorFlow: heap OOB read in BoostedTrees ops

HIGH
Published August 12, 2021
CISO Take

TensorFlow prior to 2.6.0 allows local low-privilege attackers to trigger a heap out-of-bounds read via crafted inputs to BoostedTrees operations, risking training data leakage from heap memory and DoS of training jobs. Patch to TF 2.6.0 or apply cherry-pick fixes for 2.3.4/2.4.3/2.5.1 immediately. Shared ML training infrastructure and multi-tenant data science platforms are the primary exposure surface.

What is the risk?

Moderate risk in practice. The local attack vector limits exposure to insider threats, compromised developer credentials, or shared ML compute environments. In enterprises running multi-tenant GPU clusters or shared Jupyter/ML platforms, the low-privilege requirement means any authenticated user can trigger exploitation. The heap OOB read can leak adjacent memory allocations, potentially exposing fragments of training data or intermediate model state. Not in CISA KEV and no known active exploitation reduces urgency but patching remains straightforward.

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.2%
chance of exploitation in 30 days
Higher than 6% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

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. Upgrade TensorFlow to 2.6.0+, or cherry-pick the patch (commit e84c975) on supported branches: 2.5.1, 2.4.3, 2.3.4.

  2. Before patching, add server-side validation rejecting stats_summary_indices values outside expected range at any API boundary accepting BoostedTrees inputs.

  3. Restrict write access to ML training infrastructure — enforce least privilege on shared GPU/ML servers.

  4. Monitor training processes for anomalous SIGBUS/SIGSEGV crashes as potential exploitation indicators.

  5. Audit current TF version inventory across all training environments, including containerized ML pipelines.

How is it classified?

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 design and implementation
NIST AI RMF
MANAGE-2.2 - Mechanisms to sustain and monitor AI risk treatments
OWASP LLM Top 10
LLM06:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2021-37664?

TensorFlow prior to 2.6.0 allows local low-privilege attackers to trigger a heap out-of-bounds read via crafted inputs to BoostedTrees operations, risking training data leakage from heap memory and DoS of training jobs. Patch to TF 2.6.0 or apply cherry-pick fixes for 2.3.4/2.4.3/2.5.1 immediately. Shared ML training infrastructure and multi-tenant data science platforms are the primary exposure surface.

Is CVE-2021-37664 actively exploited?

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

How to fix CVE-2021-37664?

1. Upgrade TensorFlow to 2.6.0+, or cherry-pick the patch (commit e84c975) on supported branches: 2.5.1, 2.4.3, 2.3.4. 2. Before patching, add server-side validation rejecting stats_summary_indices values outside expected range at any API boundary accepting BoostedTrees inputs. 3. Restrict write access to ML training infrastructure — enforce least privilege on shared GPU/ML servers. 4. Monitor training processes for anomalous SIGBUS/SIGSEGV crashes as potential exploitation indicators. 5. Audit current TF version inventory across all training environments, including containerized ML pipelines.

What systems are affected by CVE-2021-37664?

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

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

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

What is the AI security impact?

Affected AI Architectures

training pipelinesshared ML infrastructuremodel serving

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0025 Exfiltration via Cyber Means
AML.T0029 Denial of AI Service
AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: MANAGE-2.2
OWASP LLM Top 10: LLM06: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 `BoostedTreesSparseCalculateBestFeatureSplit`. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/stats_ops.cc) needs to validate that each value in `stats_summary_indices` is in range. We have patched the issue in GitHub commit e84c975313e8e8e38bb2ea118196369c45c51378. 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 insider threat or attacker who has compromised a data scientist's credentials on a shared ML training server submits a crafted training job containing out-of-range values in stats_summary_indices. The OOB read either crashes the training process outright (DoS, destroying training progress) or, in a targeted scenario, leaks heap memory adjacent to training data structures — potentially exposing proprietary training datasets, feature engineering outputs, or intermediate gradient statistics from other users' concurrent jobs on the same server.

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
August 12, 2021
Last Modified
November 21, 2024
First Seen
August 12, 2021

Related Vulnerabilities