CVE-2020-15205: TensorFlow: heap overflow in StringNGrams, ASLR bypass

CRITICALPoC AVAILABLE

Published September 25, 2020

CISO Take

Any TensorFlow deployment processing user-controlled text through StringNGrams is exposed to remote heap overflow and memory disclosure that can defeat ASLR — enabling full system compromise. Patch to TF 1.15.4/2.0.3/2.1.2/2.2.1/2.3.1+ immediately; treat unpatched model-serving endpoints as critical-risk. If immediate patching is not possible, isolate TF inference endpoints from untrusted input sources as a stopgap.

What is the risk?

CVSS 9.8 with network vector, zero authentication, and zero user interaction makes this trivially reachable against any exposed TF serving deployment. The combination of heap overflow (code execution path) and memory stack disclosure (ASLR bypass) gives a capable attacker a reliable exploitation chain. Risk is highest for organizations running TF model-serving APIs that accept externally-supplied text data without prior sanitization.

What systems are affected?

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

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

1.0%

chance of exploitation in 30 days

Higher than 64% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

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

CHigh

IHigh

AHigh

What should I do?

5 steps

Patch: upgrade to TF 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1+.
Isolate: restrict network access to TF serving endpoints; enforce strict input validation before user data reaches raw ops.
Detect: scan container registries, pip environments, and model-serving infra for TF versions below patched thresholds.
Monitor: alert on anomalous process crashes or unexpected memory-related errors in TF serving processes (heap corruption indicators).
Verify: confirm patched version via pip show tensorflow or container image manifests before marking remediated.

How is it classified?

Code ExecutionData LeakageFrameworkInferenceAML.T0010.001- AI Software AML.T0025- Exfiltration via Cyber Means 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.10.4-AI system security testing

NIST AI RMF

MANAGE-2.2-Risks associated with third-party entities

OWASP LLM Top 10

LLM05-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2020-15205?

Is CVE-2020-15205 actively exploited?

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

How to fix CVE-2020-15205?

1. Patch: upgrade to TF 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1+. 2. Isolate: restrict network access to TF serving endpoints; enforce strict input validation before user data reaches raw ops. 3. Detect: scan container registries, pip environments, and model-serving infra for TF versions below patched thresholds. 4. Monitor: alert on anomalous process crashes or unexpected memory-related errors in TF serving processes (heap corruption indicators). 5. Verify: confirm patched version via `pip show tensorflow` or container image manifests before marking remediated.

What systems are affected by CVE-2020-15205?

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

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

CVE-2020-15205 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 1.03%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesNLP preprocessing pipelines

MITRE ATLAS Techniques

AML.T0010.001AI Software

AML.T0025Exfiltration via Cyber Means

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.10.4

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

In Tensorflow before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, the `data_splits` argument of `tf.raw_ops.StringNGrams` lacks validation. This allows a user to pass values that can cause heap overflow errors and even leak contents of memory In the linked code snippet, all the binary strings after `ee ff` are contents from the memory stack. Since these can contain return addresses, this data leak can be used to defeat ASLR. The issue is patched in commit 0462de5b544ed4731aa2fb23946ac22c01856b80, and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.

Exploitation Scenario

An adversary targeting an NLP model API sends a crafted inference request with malformed data_splits values to tf.raw_ops.StringNGrams. The absent validation causes a heap buffer overflow, corrupting adjacent memory structures. By reading leaked stack contents embedded in the error response or via timing side-channels, the adversary recovers return addresses to break ASLR. With ASLR defeated, they chain a follow-up memory corruption payload to achieve RCE inside the model-serving process — gaining access to model weights, in-memory training data, API credentials, and a foothold on the underlying host.

Weaknesses (CWE)

CWE-787Out-of-bounds WritePrimary CWE-119Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-122Heap-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.