CVE-2022-29210: TensorFlow heap OOB

CISO Take

TensorFlow 2.8.0 has a heap buffer overflow in its TensorKey hash function that crashes the process when triggered locally. Patch to 2.8.1 or 2.9.0 immediately—particularly on shared ML compute clusters where multiple users have local access. No known active exploitation, but AI/ML environments frequently expose local access to many internal users.

What is the risk?

Medium operational risk despite medium CVSS. Local-only exploitation with no confidentiality or integrity impact limits external threat surface. However, in enterprise AI environments, shared GPU clusters and multi-tenant ML platforms mean local access is commonplace. A crash during training loses compute-hours and potentially corrupts model checkpoints, translating to real business impact beyond the technical CVSS score.

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

I None

A High

What should I do?

5 steps

Upgrade TensorFlow to 2.8.1 or 2.9.0 (patch available, commit 1b85a28d).
If upgrade is blocked, audit codebases for TensorKey usage with constant int32_t tensors.
Enforce process isolation on shared ML clusters to contain blast radius from crashes.
Pin ML pipeline dependencies to verified patched versions in requirements.txt/Pipfile.
Monitor for anomalous TensorFlow process crashes as a detection signal—especially in multi-tenant environments.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Framework 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

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3 - AI system robustness and reliability

NIST AI RMF

GOVERN-1.1 - Policies, processes, procedures for AI risk governance MANAGE-2.2 - Risks and benefits of the AI system are managed

Frequently Asked Questions

What is CVE-2022-29210?

TensorFlow 2.8.0 has a heap buffer overflow in its TensorKey hash function that crashes the process when triggered locally. Patch to 2.8.1 or 2.9.0 immediately—particularly on shared ML compute clusters where multiple users have local access. No known active exploitation, but AI/ML environments frequently expose local access to many internal users.

Is CVE-2022-29210 actively exploited?

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

How to fix CVE-2022-29210?

1. Upgrade TensorFlow to 2.8.1 or 2.9.0 (patch available, commit 1b85a28d). 2. If upgrade is blocked, audit codebases for TensorKey usage with constant int32_t tensors. 3. Enforce process isolation on shared ML clusters to contain blast radius from crashes. 4. Pin ML pipeline dependencies to verified patched versions in requirements.txt/Pipfile. 5. Monitor for anomalous TensorFlow process crashes as a detection signal—especially in multi-tenant environments.

What systems are affected by CVE-2022-29210?

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

What is the CVSS score for CVE-2022-29210?

CVE-2022-29210 has a CVSS v3.1 base score of 5.5 (MEDIUM). The EPSS exploitation probability is 0.22%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servinginference infrastructureML development environments

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: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: GOVERN-1.1, MANAGE-2.2

What are the technical details?

Original Advisory

TensorFlow is an open source platform for machine learning. In version 2.8.0, the `TensorKey` hash function used total estimated `AllocatedBytes()`, which (a) is an estimate per tensor, and (b) is a very poor hash function for constants (e.g. `int32_t`). It also tried to access individual tensor bytes through `tensor.data()` of size `AllocatedBytes()`. This led to ASAN failures because the `AllocatedBytes()` is an estimate of total bytes allocated by a tensor, including any pointed-to constructs (e.g. strings), and does not refer to contiguous bytes in the `.data()` buffer. The discoverers could not use this byte vector anyway because types such as `tstring` include pointers, whereas they needed to hash the string values themselves. This issue is patched in Tensorflow versions 2.9.0 and 2.8.1.

Exploitation Scenario

An attacker with local access to a shared ML compute node (common in enterprise AI teams using shared GPU clusters) crafts a TensorFlow graph using int32_t constant tensors that triggers the TensorKey hash function. The function calls tensor.data() with AllocatedBytes() as the size—an overestimate that includes pointed-to heap constructs. This triggers a heap out-of-bounds read/write (CWE-122/787), crashing the TensorFlow process. On a shared training cluster, this disrupts colocated training runs and may corrupt in-progress model checkpoints, causing loss of hours of expensive GPU compute.

Weaknesses (CWE)

CWE-787 Out-of-bounds Write Primary CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-122 Heap-based Buffer Overflow

CWE-787 — Out-of-bounds Write: The product writes data past the end, or before the beginning, of the intended buffer.

[Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

Source: MITRE CWE corpus.