CVE-2021-37655: TensorFlow: OOB heap read in ResourceScatterUpdate

HIGH

Published August 12, 2021

CISO Take

TensorFlow versions before 2.6.0 allow any low-privileged local user to trigger an out-of-bounds heap read via malformed tensor shapes in ResourceScatterUpdate, with high confidentiality impact. Patch immediately to TF 2.6.0, 2.5.1, 2.4.3, or 2.3.4—especially on shared ML compute environments like JupyterHub or Kubeflow. No workaround exists; patching is the only remediation.

What is the risk?

CVSS 7.3 High with local attack vector limits direct internet exposure, but the risk escalates significantly in multi-tenant ML platforms where multiple users share a single TF runtime. Low complexity and low privilege requirements mean any authenticated researcher or data scientist on a shared GPU cluster can trigger this. Confidentiality impact is rated High (C:H), meaning sensitive heap data—including model weights or in-memory credentials—could be exposed. Not in CISA KEV and no active exploitation observed, reducing urgency for air-gapped environments but not for shared SaaS ML infrastructure.

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.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 6% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I Low

A High

What should I do?

1 step

1) Upgrade TensorFlow to ≥2.6.0 or apply cherry-picked patches for supported branches (2.5.1, 2.4.3, 2.3.4). 2) Audit shared ML platforms (JupyterHub, SageMaker Studio, Vertex AI Workbench) for outdated TF versions—these are the highest-risk surfaces. 3) Enforce strict namespace and process isolation between tenant workloads on shared GPU infrastructure. 4) If patching is blocked, restrict access to tf.raw_ops namespace via OPA/policy controls in notebook environments. 5) For detection: grep codebases for tf.raw_ops.ResourceScatterUpdate usage; monitor TF process crashes or SIGSEGV signals as potential exploitation indicators.

How is it classified?

Data Extraction Code Execution Framework Training Data AML.T0010.001 - AI Software AML.T0037 - Data from Local System AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity of high-risk AI systems

ISO 42001

A.6.2 - AI system security controls

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place to inventory AI risks and prioritize based on impact

OWASP LLM Top 10

LLM03:2025 - Supply Chain

Frequently Asked Questions

What is CVE-2021-37655?

Is CVE-2021-37655 actively exploited?

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

How to fix CVE-2021-37655?

1) Upgrade TensorFlow to ≥2.6.0 or apply cherry-picked patches for supported branches (2.5.1, 2.4.3, 2.3.4). 2) Audit shared ML platforms (JupyterHub, SageMaker Studio, Vertex AI Workbench) for outdated TF versions—these are the highest-risk surfaces. 3) Enforce strict namespace and process isolation between tenant workloads on shared GPU infrastructure. 4) If patching is blocked, restrict access to tf.raw_ops namespace via OPA/policy controls in notebook environments. 5) For detection: grep codebases for tf.raw_ops.ResourceScatterUpdate usage; monitor TF process crashes or SIGSEGV signals as potential exploitation indicators.

What systems are affected by CVE-2021-37655?

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

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

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

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingnotebook environmentsshared ML compute

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0037 Data from Local System

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 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 trigger a read from outside of bounds of heap allocated data by sending invalid arguments to `tf.raw_ops.ResourceScatterUpdate`. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L919-L923) has an incomplete validation of the relationship between the shapes of `indices` and `updates`: instead of checking that the shape of `indices` is a prefix of the shape of `updates` (so that broadcasting can happen), code only checks that the number of elements in these two tensors are in a divisibility relationship. We have patched the issue in GitHub commit 01cff3f986259d661103412a20745928c727326f. 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 adversary with a low-privilege account on a shared JupyterHub instance (e.g., a compromised intern account at an ML research org) opens a notebook and crafts a call to tf.raw_ops.ResourceScatterUpdate with indices and updates tensors whose total element counts have a divisibility relationship but whose shapes are incompatible for broadcasting. TensorFlow's validation passes the divisibility check and proceeds, causing the C++ kernel to read beyond the bounds of the heap-allocated updates buffer. The attacker iterates shapes to read adjacent heap regions, potentially extracting fragments of model weights, training data, or in-process API tokens cached by a co-running LLM fine-tuning job on the same host.

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.