CVE-2021-37647 — MEDIUM (CVSS 5.5) AI Security Vulnerability

Q: Is CVE-2021-37647 actively exploited?

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

Q: How to fix CVE-2021-37647?

1. PATCH: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (all contain commit 02cc160e). 2. VALIDATE: Add input validation at API/service boundaries before sparse tensor data reaches tf.raw_ops — check that indices and values are either both empty or both non-empty. 3. ISOLATE: Run TF inference workers in separate processes with restart policies (Kubernetes liveness probes, systemd RestartOnFailure) to auto-recover from crashes. 4. SCAN: Audit any publicly-exposed endpoints that accept sparse tensor inputs for the affected TF version range (< 2.3.4, 2.4.x < 2.4.3, 2.5.x < 2.5.1).

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

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

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

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

CISO Take

This medium-severity local DoS affects TensorFlow's sparse tensor data pipeline operations. Any TF-based inference or training system that accepts externally-supplied sparse tensor inputs without input validation is vulnerable to process crashes. Patch immediately to TF 2.6.0 (or 2.5.1/2.4.3/2.3.4 backports) and add boundary validation on sparse tensor inputs before they reach raw ops.

Risk Assessment

Overall risk is LOW-MEDIUM. The local attack vector and low privileges required limit the exploitability to scenarios where an adversary can influence tensor inputs — either directly via a local process or indirectly through a model-serving endpoint that accepts user-supplied sparse tensors. There is zero confidentiality or integrity impact (availability-only). The risk elevates to MEDIUM in multi-tenant ML serving environments or Jupyter notebook hubs where untrusted users can submit arbitrary tensor data.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
tensorflow	pip	—	No patch
195.0K OpenSSF 7.2 3.7K dependents Pushed today 4% patched ~1372d to patch Full package profile →

Do you use tensorflow? You're affected.

Severity & Risk

CVSS 3.1

5.5 / 10

EPSS

0.0%

chance of exploitation in 30 days

Higher than 14% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

Attack Surface

AV Local

AC Low

PR Low

UI None

S Unchanged

C None

I None

A High

Recommended Action

4 steps

PATCH

Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (all contain commit 02cc160e).
VALIDATE

Add input validation at API/service boundaries before sparse tensor data reaches tf.raw_ops — check that indices and values are either both empty or both non-empty.
ISOLATE

Run TF inference workers in separate processes with restart policies (Kubernetes liveness probes, systemd RestartOnFailure) to auto-recover from crashes.
SCAN

Audit any publicly-exposed endpoints that accept sparse tensor inputs for the affected TF version range (< 2.3.4, 2.4.x < 2.4.3, 2.5.x < 2.5.1).

Classification

DoS Framework Inference AML.T0010.001 - AI Software AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Compliance Impact

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity

ISO 42001

8.4 - AI system risk management

NIST AI RMF

GOVERN-1.1 - Policies and procedures for AI risk management MANAGE-2.2 - Mechanisms to sustain AI system performance

Frequently Asked Questions

What is CVE-2021-37647?

This medium-severity local DoS affects TensorFlow's sparse tensor data pipeline operations. Any TF-based inference or training system that accepts externally-supplied sparse tensor inputs without input validation is vulnerable to process crashes. Patch immediately to TF 2.6.0 (or 2.5.1/2.4.3/2.3.4 backports) and add boundary validation on sparse tensor inputs before they reach raw ops.

Is CVE-2021-37647 actively exploited?

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

How to fix CVE-2021-37647?

1. PATCH: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (all contain commit 02cc160e). 2. VALIDATE: Add input validation at API/service boundaries before sparse tensor data reaches tf.raw_ops — check that indices and values are either both empty or both non-empty. 3. ISOLATE: Run TF inference workers in separate processes with restart policies (Kubernetes liveness probes, systemd RestartOnFailure) to auto-recover from crashes. 4. SCAN: Audit any publicly-exposed endpoints that accept sparse tensor inputs for the affected TF version range (< 2.3.4, 2.4.x < 2.4.3, 2.5.x < 2.5.1).

What systems are affected by CVE-2021-37647?

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

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

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

Technical Details

NVD Description

TensorFlow is an end-to-end open source platform for machine learning. When a user does not supply arguments that determine a valid sparse tensor, `tf.raw_ops.SparseTensorSliceDataset` implementation can be made to dereference a null pointer. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/data/sparse_tensor_slice_dataset_op.cc#L240-L251) has some argument validation but fails to consider the case when either `indices` or `values` are provided for an empty sparse tensor when the other is not. If `indices` is empty, then [code that performs validation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/data/sparse_tensor_slice_dataset_op.cc#L260-L261) (i.e., checking that the indices are monotonically increasing) results in a null pointer dereference. If `indices` as provided by the user is empty, then `indices` in the C++ code above is backed by an empty `std::vector`, hence calling `indices->dim_size(0)` results in null pointer dereferencing (same as calling `std::vector::at()` on an empty vector). We have patched the issue in GitHub commit 02cc160e29d20631de3859c6653184e3f876b9d7. 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 targeting a recommendation engine or sparse-feature NLP service built on TensorFlow constructs a crafted REST payload where the SparseTensor indices field is an empty array while values contains data (or vice versa). Sending this to the serving endpoint triggers the null pointer dereference in SparseTensorSliceDataset, crashing the TF serving process. In a Kubernetes environment without proper liveness probes, this could take the service offline until manually restarted. In a multi-tenant ML platform (e.g., SageMaker-style notebook hub), a low-privileged user executes tf.raw_ops.SparseTensorSliceDataset with malformed arguments to crash the shared kernel, causing denial of service for other users.