CVE-2021-37663: TensorFlow QuantizeV2 heap

CISO Take

This TensorFlow vulnerability allows a local attacker with low privileges to trigger heap out-of-bounds reads or null pointer dereferences via malformed QuantizeV2 inputs — relevant in shared ML training environments, Jupyter hubs, and multi-tenant ML platforms where user-supplied TF graphs execute. Patch to TF 2.6.0, 2.5.1, 2.4.3, or 2.3.4 immediately; audit any environment where untrusted users can submit TensorFlow operations. Risk is amplified in MLaaS platforms and shared GPU clusters where 'local' effectively means any authenticated user.

What is the risk?

CVSS 7.8 High with local attack vector understates operational risk in AI/ML environments. In shared ML infrastructure — Jupyter hubs, Kubeflow, SageMaker Studio, internal ML platforms — the 'local' constraint is trivially satisfied by any authenticated data scientist or researcher. Low complexity and no user interaction required means exploitation is mechanical once local execution is available. The vulnerability is in a quantization kernel, a common operation in model compression and edge deployment pipelines. Not in CISA KEV and patched since August 2021, so active exploitation risk is low for patched systems. Unpatched legacy ML infrastructure running TF 2.3–2.5 remains at material risk.

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

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% 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 High

A High

What should I do?

6 steps

PATCH

Upgrade TensorFlow to 2.6.0+, 2.5.1+, 2.4.3+, or 2.3.4+ per your branch.
DETECTION

Grep codebases and model serving configs for 'QuantizeV2' or 'tf.raw_ops.QuantizeV2' calls with dynamic axis parameters from user input.
ISOLATION

In multi-tenant ML platforms, enforce graph sandboxing or use TF's restricted execution mode to limit available ops for untrusted users.
MONITORING

Alert on TensorFlow process crashes in training/serving infrastructure — repeated crashes may indicate exploitation attempts.
INVENTORY

Audit all TF versions across training nodes, serving infrastructure, and CI/CD ML pipelines; containerized environments often pin old TF versions.
WORKAROUND (if patching is delayed): Validate that min_range and max_range tensors have matching non-zero element counts equal to the axis dimension before calling QuantizeV2.

How is it classified?

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

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 9 - Risk Management System

ISO 42001

A.6.1.4 - Information security in AI system lifecycle

NIST AI RMF

GOVERN 1.1 - Policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks are in place MANAGE 2.2 - Responses to the AI risks deemed high priority are developed, planned, and documented

OWASP LLM Top 10

LLM08 - Excessive Agency / Insecure Plugin Design

Frequently Asked Questions

What is CVE-2021-37663?

This TensorFlow vulnerability allows a local attacker with low privileges to trigger heap out-of-bounds reads or null pointer dereferences via malformed QuantizeV2 inputs — relevant in shared ML training environments, Jupyter hubs, and multi-tenant ML platforms where user-supplied TF graphs execute. Patch to TF 2.6.0, 2.5.1, 2.4.3, or 2.3.4 immediately; audit any environment where untrusted users can submit TensorFlow operations. Risk is amplified in MLaaS platforms and shared GPU clusters where 'local' effectively means any authenticated user.

Is CVE-2021-37663 actively exploited?

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

How to fix CVE-2021-37663?

1. PATCH: Upgrade TensorFlow to 2.6.0+, 2.5.1+, 2.4.3+, or 2.3.4+ per your branch. 2. DETECTION: Grep codebases and model serving configs for 'QuantizeV2' or 'tf.raw_ops.QuantizeV2' calls with dynamic axis parameters from user input. 3. ISOLATION: In multi-tenant ML platforms, enforce graph sandboxing or use TF's restricted execution mode to limit available ops for untrusted users. 4. MONITORING: Alert on TensorFlow process crashes in training/serving infrastructure — repeated crashes may indicate exploitation attempts. 5. INVENTORY: Audit all TF versions across training nodes, serving infrastructure, and CI/CD ML pipelines; containerized environments often pin old TF versions. 6. WORKAROUND (if patching is delayed): Validate that min_range and max_range tensors have matching non-zero element counts equal to the axis dimension before calling QuantizeV2.

What systems are affected by CVE-2021-37663?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, edge/mobile deployment pipelines, shared ML development environments, model optimization/compression pipelines.

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

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

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingedge/mobile deployment pipelinesshared ML development environmentsmodel optimization/compression pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 9

ISO 42001: A.6.1.4

NIST AI RMF: GOVERN 1.1, MANAGE 2.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

TensorFlow is an end-to-end open source platform for machine learning. In affected versions due to incomplete validation in `tf.raw_ops.QuantizeV2`, an attacker can trigger undefined behavior via binding a reference to a null pointer or can access data outside the bounds of heap allocated arrays. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/quantize_op.cc#L59) has some validation but does not check that `min_range` and `max_range` both have the same non-zero number of elements. If `axis` is provided (i.e., not `-1`), then validation should check that it is a value in range for the rank of `input` tensor and then the lengths of `min_range` and `max_range` inputs match the `axis` dimension of the `input` tensor. We have patched the issue in GitHub commit 6da6620efad397c85493b8f8667b821403516708. 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 access to a shared ML training platform (e.g., internal Jupyter hub, Kubeflow Pipelines, or a contractor-accessible MLaaS environment) submits a crafted TensorFlow training job or notebook. The malicious code calls tf.raw_ops.QuantizeV2 with a carefully mismatched axis parameter and min_range/max_range tensors — providing a non-(-1) axis value while supplying element counts that don't match the input tensor's axis dimension. This triggers a null pointer dereference or heap out-of-bounds read in the TF kernel, crashing the training worker process. In a more sophisticated variant, heap spray techniques could turn the OOB access into code execution within the TF serving process, potentially allowing the attacker to exfiltrate model weights, training data, or environment credentials from the compromised ML worker.

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.