CVE-2020-26270: TensorFlow DoS — LOW

CISO Take

Low-severity local denial-of-service in TensorFlow's CUDA backend: a zero-length input to LSTM/GRU layers triggers a CHECK failure that crashes the process. If your ML inference infrastructure exposes LSTM/GRU models to user-controlled inputs on GPU hardware, upgrade to a patched version immediately. No data exposure, no remote vector—priority is availability of GPU-backed inference endpoints.

What is the risk?

Overall risk is low. The local attack vector (AV:L) significantly constrains exploitability to scenarios where an adversary already has local access or can inject inputs into a running inference pipeline. CVSS 3.3 with only availability impact (low). Not in CISA KEV, no public exploitation reported. Risk escalates meaningfully only in multi-tenant or shared inference environments where end-users can submit raw tensor inputs to CUDA-backed models.

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

3.3 / 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 None

I None

A Low

What should I do?

5 steps

Upgrade TensorFlow to patched versions: 1.15.5, 2.0.4, 2.1.3, 2.2.2, 2.3.2, or 2.4.0+.
Workaround if immediate patching is not feasible: add input validation at the serving layer to reject zero-length sequences before they reach the model.
In model serving frameworks (TF Serving, Triton), add shape validation middleware that enforces minimum sequence length > 0.
Monitor CUDA backend crashes and TF process restarts as anomaly signals.
Audit shared inference endpoints that accept raw tensor inputs from untrusted users.

How is it classified?

DoS Framework Inference AML.T0029 - Denial of AI Service AML.T0034 - Cost Harvesting 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.1.3 - AI system operational robustness

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain effectiveness of AI risk management MAP 5.1 - Likelihood and magnitude of potential impacts identified

Frequently Asked Questions

What is CVE-2020-26270?

Low-severity local denial-of-service in TensorFlow's CUDA backend: a zero-length input to LSTM/GRU layers triggers a CHECK failure that crashes the process. If your ML inference infrastructure exposes LSTM/GRU models to user-controlled inputs on GPU hardware, upgrade to a patched version immediately. No data exposure, no remote vector—priority is availability of GPU-backed inference endpoints.

Is CVE-2020-26270 actively exploited?

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

How to fix CVE-2020-26270?

1. Upgrade TensorFlow to patched versions: 1.15.5, 2.0.4, 2.1.3, 2.2.2, 2.3.2, or 2.4.0+. 2. Workaround if immediate patching is not feasible: add input validation at the serving layer to reject zero-length sequences before they reach the model. 3. In model serving frameworks (TF Serving, Triton), add shape validation middleware that enforces minimum sequence length > 0. 4. Monitor CUDA backend crashes and TF process restarts as anomaly signals. 5. Audit shared inference endpoints that accept raw tensor inputs from untrusted users.

What systems are affected by CVE-2020-26270?

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

What is the CVSS score for CVE-2020-26270?

CVE-2020-26270 has a CVSS v3.1 base score of 3.3 (LOW). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesinference infrastructure

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0034 Cost Harvesting

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1.3

NIST AI RMF: MANAGE 2.2, MAP 5.1

What are the technical details?

Original Advisory

In affected versions of TensorFlow running an LSTM/GRU model where the LSTM/GRU layer receives an input with zero-length results in a CHECK failure when using the CUDA backend. This can result in a query-of-death vulnerability, via denial of service, if users can control the input to the layer. This is fixed in versions 1.15.5, 2.0.4, 2.1.3, 2.2.2, 2.3.2, and 2.4.0.

Exploitation Scenario

An adversary with access to a shared GPU-backed inference endpoint (e.g., an internal ML platform or a public API wrapping a sequence model) submits a prediction request with a zero-length sequence tensor to an LSTM or GRU layer. The CUDA backend hits a CHECK failure and crashes the TensorFlow process. In a production inference server without process supervision or health-check recovery, this results in service outage. In a shared multi-tenant ML platform, a low-privileged user could repeatedly crash the GPU inference worker, causing a sustained denial of service for all tenants.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary 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.