CVE-2021-37641: TensorFlow RaggedGather OOB read -

Q: Is CVE-2021-37641 actively exploited?

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

Q: How to fix CVE-2021-37641?

1. PATCH: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (commit a2b743f6). 2. VALIDATE: Add rank and non-empty checks on all tensor inputs before invoking RaggedGather ops — reject scalar tensors (rank < 1) and empty params_nested_splits lists. 3. ISOLATE: Run TF inference workers in per-tenant isolated containers or processes on shared platforms; prevent cross-tenant memory disclosure. 4. AUDIT: Search pipeline code and SavedModel graphs for direct use of tf.raw_ops.RaggedGather with unvalidated inputs. 5. DETECT: Alert on unexpected SIGABRT/SIGSEGV or process restarts in TF serving deployments — these may indicate exploitation attempts.

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

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

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

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

CISO Take

TensorFlow versions before 2.6.0/2.5.1/2.4.3/2.3.4 contain a heap out-of-bounds read in the RaggedGather op that any low-privileged user can trigger with malformed tensor inputs. Impact includes heap memory disclosure (potential exposure of model weights, in-flight data, or pipeline secrets) and process crash causing inference DoS. Patch all TF deployments immediately — the fix has been public since August 2021, making unpatched systems trivially exploitable by anyone who reads the advisory.

What is the risk?

CVSS 7.1 High with local/low-privilege access and low attack complexity — no user interaction required. Risk is materially elevated in shared ML platforms (Kubeflow, SageMaker Studio, JupyterHub) where multiple users or pipelines submit TensorFlow computations to shared infrastructure. A malicious insider or compromised notebook account can trigger heap reads from adjacent memory regions and crash inference workers. No active exploitation recorded in CISA KEV, but the public patch commit and GitHub advisory make reverse-engineering the exploit trivial for any motivated attacker.

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

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 High

What should I do?

5 steps

PATCH

Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (commit a2b743f6).
VALIDATE

Add rank and non-empty checks on all tensor inputs before invoking RaggedGather ops — reject scalar tensors (rank < 1) and empty params_nested_splits lists.
ISOLATE

Run TF inference workers in per-tenant isolated containers or processes on shared platforms; prevent cross-tenant memory disclosure.
AUDIT

Search pipeline code and SavedModel graphs for direct use of tf.raw_ops.RaggedGather with unvalidated inputs.
DETECT

Alert on unexpected SIGABRT/SIGSEGV or process restarts in TF serving deployments — these may indicate exploitation attempts.

How is it classified?

Data Leakage DoS Supply Chain Framework Inference AML.T0001 - Search Open AI Vulnerability Analysis AML.T0010.001 - AI Software AML.T0029 - Denial of AI Service AML.T0043 - Craft Adversarial Data

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.3 - AI risk treatment

NIST AI RMF

MANAGE 2.2 - Mechanisms to respond to, recover from, and otherwise manage identified AI risks MAP 5.1 - Likelihood of AI risks

Frequently Asked Questions

What is CVE-2021-37641?

TensorFlow versions before 2.6.0/2.5.1/2.4.3/2.3.4 contain a heap out-of-bounds read in the RaggedGather op that any low-privileged user can trigger with malformed tensor inputs. Impact includes heap memory disclosure (potential exposure of model weights, in-flight data, or pipeline secrets) and process crash causing inference DoS. Patch all TF deployments immediately — the fix has been public since August 2021, making unpatched systems trivially exploitable by anyone who reads the advisory.

Is CVE-2021-37641 actively exploited?

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

How to fix CVE-2021-37641?

1. PATCH: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (commit a2b743f6). 2. VALIDATE: Add rank and non-empty checks on all tensor inputs before invoking RaggedGather ops — reject scalar tensors (rank < 1) and empty params_nested_splits lists. 3. ISOLATE: Run TF inference workers in per-tenant isolated containers or processes on shared platforms; prevent cross-tenant memory disclosure. 4. AUDIT: Search pipeline code and SavedModel graphs for direct use of tf.raw_ops.RaggedGather with unvalidated inputs. 5. DETECT: Alert on unexpected SIGABRT/SIGSEGV or process restarts in TF serving deployments — these may indicate exploitation attempts.

What systems are affected by CVE-2021-37641?

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

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

CVE-2021-37641 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 pipelinesmodel servingshared ML platforms

MITRE ATLAS Techniques

AML.T0001 Search Open AI Vulnerability Analysis

AML.T0010.001 AI Software

AML.T0029 Denial of AI Service

AML.T0043 Craft Adversarial Data

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.1.3

NIST AI RMF: MANAGE 2.2, MAP 5.1

What are the technical details?

Original Advisory

TensorFlow is an end-to-end open source platform for machine learning. In affected versions if the arguments to `tf.raw_ops.RaggedGather` don't determine a valid ragged tensor code can trigger a read from outside of bounds of heap allocated buffers. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/ragged_gather_op.cc#L70) directly reads the first dimension of a tensor shape before checking that said tensor has rank of at least 1 (i.e., it is not a scalar). Furthermore, the implementation does not check that the list given by `params_nested_splits` is not an empty list of tensors. We have patched the issue in GitHub commit a2b743f6017d7b97af1fe49087ae15f0ac634373. 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-privileged account on a shared ML platform (e.g., JupyterHub, SageMaker Studio, Vertex AI Workbench) submits a notebook or training job containing tf.raw_ops.RaggedGather with a rank-0 scalar tensor as params. TensorFlow reads the first dimension from an invalid heap address, triggering the OOB read. On a multi-tenant inference server, this leaks heap contents from the current or adjacent process allocation — potentially exposing another tenant's model weights, inference batch data, or API tokens held in memory. A second invocation with an empty params_nested_splits list crashes the serving worker, causing an outage for all tenants sharing that process.

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.