CVE-2020-26269: TensorFlow: OOB read in glob path matching causes DoS

HIGHPoC AVAILABLE

Published December 10, 2020

CISO Take

This vulnerability in TensorFlow 2.4 release candidates allows unauthenticated remote attackers to crash TensorFlow processes via malformed filesystem glob patterns, resulting in denial of service. The final 2.4.0 release is patched — if any team ran RC builds in production (a bad practice itself), upgrade immediately. Risk is low for most organizations since RC versions should never reach production AI pipelines.

What is the risk?

Despite CVSS 7.5 HIGH rating, practical risk is limited: the vulnerability exclusively affects TensorFlow 2.4.0 release candidate versions and was resolved before the stable release. Network-reachable, no authentication required, and trivially triggerable make it dangerous in theory — but the narrow exposure window (RC builds only) significantly reduces real-world blast radius. No confidentiality or integrity impact; only availability. No evidence of active exploitation. Organizations using stable TensorFlow builds are unaffected.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
TensorFlow	pip	—	No patch
201.3KOpenSSF 7.63.4K dependentsPushed 6d ago4% patched~1372d to patchFull package profile →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 53% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

5 steps

PATCH
Upgrade all TensorFlow installations to 2.4.0 stable or later — this is the only fix.
AUDIT
Scan your environment for any deployment using tensorflow==2.4.0rc* versions (pip list | grep tensorflow).
POLICY
Enforce policy that release candidate versions of ML frameworks are never deployed to production or staging environments.
DETECT
Monitor for unusual TensorFlow process crashes or OOM errors in ML workloads — could indicate exploitation attempts.
COMPENSATE
If patching is delayed, restrict network access to any service accepting user-controlled file path inputs to TensorFlow.

How is it classified?

DoSFrameworkAML.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

8.2-AI risk assessment

NIST AI RMF

GOVERN-1.2-Policies and procedures for AI risk managementMANAGE-2.2-Mechanisms to sustain the value of deployed AI systems

Frequently Asked Questions

What is CVE-2020-26269?

Is CVE-2020-26269 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2020-26269, increasing the risk of exploitation.

How to fix CVE-2020-26269?

1. PATCH: Upgrade all TensorFlow installations to 2.4.0 stable or later — this is the only fix. 2. AUDIT: Scan your environment for any deployment using tensorflow==2.4.0rc* versions (pip list | grep tensorflow). 3. POLICY: Enforce policy that release candidate versions of ML frameworks are never deployed to production or staging environments. 4. DETECT: Monitor for unusual TensorFlow process crashes or OOM errors in ML workloads — could indicate exploitation attempts. 5. COMPENSATE: If patching is delayed, restrict network access to any service accepting user-controlled file path inputs to TensorFlow.

What systems are affected by CVE-2020-26269?

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

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

CVE-2020-26269 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.70%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingdata preprocessing pipelinesbatch inference

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0029Denial of AI Service

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art.9

ISO 42001: 8.2

NIST AI RMF: GOVERN-1.2, MANAGE-2.2

What are the technical details?

Original Advisory

In TensorFlow release candidate versions 2.4.0rc*, the general implementation for matching filesystem paths to globbing pattern is vulnerable to an access out of bounds of the array holding the directories. There are multiple invariants and preconditions that are assumed by the parallel implementation of GetMatchingPaths but are not verified by the PRs introducing it (#40861 and #44310). Thus, we are completely rewriting the implementation to fully specify and validate these. This is patched in version 2.4.0. This issue only impacts master branch and the release candidates for TF version 2.4. The final release of the 2.4 release will be patched.

Exploitation Scenario

An adversary targeting an ML inference API that accepts file path inputs (e.g., a model serving endpoint that loads user-specified dataset files) crafts a malformed glob pattern designed to trigger the out-of-bounds read in GetMatchingPaths. On a TF 2.4.0rc* backend, the parallel path matching routine processes the crafted path, violates unverified array invariants, and crashes the TensorFlow process. In a CI/CD context, an attacker with access to a training pipeline configuration could inject a malicious data path into a config file, causing the training job to crash repeatedly and preventing model updates — a targeted disruption of ML operations.

Weaknesses (CWE)

CWE-125Out-of-bounds ReadPrimary CWE-125Out-of-bounds Read

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.