CVE-2021-37673: TensorFlow MapStage CHECK-fail

CISO Take

A local attacker can crash TensorFlow processes by passing an empty key tensor to tf.raw_ops.MapStage, disrupting training jobs and inference services. Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 immediately if running affected versions. Risk is elevated in shared or multi-tenant ML platforms where untrusted users can submit workloads.

What is the risk?

Medium risk overall, but contextually higher in multi-tenant ML environments. CVSS 5.5 reflects local access requirement, which limits broad exploitation. However, low attack complexity means any authenticated user in a shared Jupyter/Kubeflow/ML platform can trivially trigger it. No confidentiality or integrity impact — pure availability disruption. Not in CISA KEV and no known active exploitation in the wild as of patch date.

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 5% 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 None

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 (all contain commit d7de677).
Workaround: If immediate upgrade is not possible, add input validation to reject empty or zero-dimensional tensors before passing to MapStage.
Isolation: Restrict access to raw TF op execution in multi-tenant environments via resource quotas and sandboxing (e.g., gVisor for Kubernetes ML workloads).
Detection: Monitor for unexpected TF process crashes or CHECK-failure stack traces in application logs containing 'map_stage_op.cc'.
Audit: Inventory all TensorFlow versions in use across training and serving infrastructure.

How is it classified?

DoS Framework Training Data Inference AML.T0010.001 - AI Software AML.T0029 - Denial of AI Service AML.T0034 - Cost Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

A.9.7 - AI system availability and resilience

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place to sustain value of deployed AI systems

OWASP LLM Top 10

LLM09:2025 - Misinformation / System Availability

Frequently Asked Questions

What is CVE-2021-37673?

A local attacker can crash TensorFlow processes by passing an empty key tensor to tf.raw_ops.MapStage, disrupting training jobs and inference services. Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 immediately if running affected versions. Risk is elevated in shared or multi-tenant ML platforms where untrusted users can submit workloads.

Is CVE-2021-37673 actively exploited?

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

How to fix CVE-2021-37673?

1. Patch: Upgrade to TensorFlow 2.6.0, 2.5.1, 2.4.3, or 2.3.4 (all contain commit d7de677). 2. Workaround: If immediate upgrade is not possible, add input validation to reject empty or zero-dimensional tensors before passing to MapStage. 3. Isolation: Restrict access to raw TF op execution in multi-tenant environments via resource quotas and sandboxing (e.g., gVisor for Kubernetes ML workloads). 4. Detection: Monitor for unexpected TF process crashes or CHECK-failure stack traces in application logs containing 'map_stage_op.cc'. 5. Audit: Inventory all TensorFlow versions in use across training and serving infrastructure.

What systems are affected by CVE-2021-37673?

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

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

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

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingdistributed training

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0029 Denial of AI Service

AML.T0034 Cost Harvesting

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.7

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM09: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 denial of service via a `CHECK`-fail in `tf.raw_ops.MapStage`. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/map_stage_op.cc#L513) does not check that the `key` input is a valid non-empty tensor. We have patched the issue in GitHub commit d7de67733925de196ec8863a33445b73f9562d1d. 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 local access to a shared ML platform (e.g., a Jupyter notebook environment or Kubeflow pipeline runner) imports TensorFlow and calls tf.raw_ops.MapStage with a zero-element or empty key tensor. TensorFlow's internal CHECK assertion fires, raising an unhandled C++ exception that terminates the TF runtime process. In a multi-user training cluster, this disrupts co-located training jobs and may trigger cascading failures in distributed training coordination. The exploit requires no special knowledge — a one-liner is sufficient once the attacker knows the target runs a vulnerable TF version.

Weaknesses (CWE)

CWE-20 Improper Input Validation

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.