CVE-2020-15192: TensorFlow memory leak

Q: Is CVE-2020-15192 actively exploited?

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

Q: How to fix CVE-2020-15192?

1. PATCH: Upgrade TensorFlow to 2.2.1 or 2.3.1 (or any later version). This is the only fix — no workaround short of disabling DLPack. 2. DETECT: Monitor TensorFlow process RSS memory for anomalous growth; alert on OOM kills in inference containers. 3. ISOLATE: If immediate patching is not possible, restrict network access to TensorFlow serving endpoints to authenticated internal users only; enforce strict input validation at the API gateway layer to reject non-tensor payloads. 4. AUDIT: Scan your ML dependency inventory for TensorFlow < 2.2.1 or < 2.3.1 — use 'pip show tensorflow' or lock-file audit. 5. OPENSSL patch check: Verify the openSUSE Leap advisory (SUSE-SU-2020:3165) if running on SLES/openSUSE.

Q: What systems are affected by CVE-2020-15192?

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

Q: What is the CVSS score for CVE-2020-15192?

CVE-2020-15192 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.68%.

CISO Take

This is a low-urgency, patched memory leak in TensorFlow's DLPack interface that allows authenticated users to slowly exhaust memory in serving or training environments. Upgrade to TensorFlow 2.2.1+ or 2.3.1+ immediately if still on affected versions — given this is a 2020 CVE, any unpatched instance is a significant hygiene failure. No active exploitation evidence; primary risk is availability degradation in multi-tenant inference endpoints.

What is the risk?

Low-to-moderate operational risk. CVSS 4.3 reflects realistic impact accurately: network-accessible, low-privilege required, no confidentiality or integrity impact, only availability. In single-tenant environments the blast radius is limited to self-inflicted DoS. In multi-tenant model serving platforms (e.g., shared GPU clusters, SageMaker-like endpoints) the risk increases as a low-privileged user could degrade service for all tenants. Not in CISA KEV and no public exploitation reported. The 5+ year age of this CVE means any exposure now is an unacceptable patch hygiene failure.

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 →
leap	—	—	No patch

How severe is it?

CVSS 3.1

4.3 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 48% 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?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A Low

What should I do?

5 steps

PATCH

Upgrade TensorFlow to 2.2.1 or 2.3.1 (or any later version). This is the only fix — no workaround short of disabling DLPack.
DETECT

Monitor TensorFlow process RSS memory for anomalous growth; alert on OOM kills in inference containers.
ISOLATE

If immediate patching is not possible, restrict network access to TensorFlow serving endpoints to authenticated internal users only; enforce strict input validation at the API gateway layer to reject non-tensor payloads.
AUDIT

Scan your ML dependency inventory for TensorFlow < 2.2.1 or < 2.3.1 — use 'pip show tensorflow' or lock-file audit.
OPENSSL patch check: Verify the openSUSE Leap advisory (SUSE-SU-2020:3165) if running on SLES/openSUSE.

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 9 - Risk management system

ISO 42001

6.1.2 - AI risk assessment 8.4 - AI system operation and monitoring

NIST AI RMF

GOVERN-1.7 - Processes and procedures are in place for decommissioning or patching AI systems MANAGE-2.2 - Mechanisms to sustain the deployment of trustworthy AI

Frequently Asked Questions

What is CVE-2020-15192?

This is a low-urgency, patched memory leak in TensorFlow's DLPack interface that allows authenticated users to slowly exhaust memory in serving or training environments. Upgrade to TensorFlow 2.2.1+ or 2.3.1+ immediately if still on affected versions — given this is a 2020 CVE, any unpatched instance is a significant hygiene failure. No active exploitation evidence; primary risk is availability degradation in multi-tenant inference endpoints.

Is CVE-2020-15192 actively exploited?

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

How to fix CVE-2020-15192?

1. PATCH: Upgrade TensorFlow to 2.2.1 or 2.3.1 (or any later version). This is the only fix — no workaround short of disabling DLPack. 2. DETECT: Monitor TensorFlow process RSS memory for anomalous growth; alert on OOM kills in inference containers. 3. ISOLATE: If immediate patching is not possible, restrict network access to TensorFlow serving endpoints to authenticated internal users only; enforce strict input validation at the API gateway layer to reject non-tensor payloads. 4. AUDIT: Scan your ML dependency inventory for TensorFlow < 2.2.1 or < 2.3.1 — use 'pip show tensorflow' or lock-file audit. 5. OPENSSL patch check: Verify the openSUSE Leap advisory (SUSE-SU-2020:3165) if running on SLES/openSUSE.

What systems are affected by CVE-2020-15192?

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

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

CVE-2020-15192 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.68%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesmulti-framework inference

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 9

ISO 42001: 6.1.2, 8.4

NIST AI RMF: GOVERN-1.7, MANAGE-2.2

What are the technical details?

Original Advisory

In Tensorflow before versions 2.2.1 and 2.3.1, if a user passes a list of strings to `dlpack.to_dlpack` there is a memory leak following an expected validation failure. The issue occurs because the `status` argument during validation failures is not properly checked. Since each of the above methods can return an error status, the `status` value must be checked before continuing. The issue is patched in commit 22e07fb204386768e5bcbea563641ea11f96ceb8 and is released in TensorFlow versions 2.2.1, or 2.3.1.

Exploitation Scenario

An adversary with low-privilege API access to a TensorFlow Serving endpoint — such as a data scientist account or a compromised ML pipeline service account — crafts repeated inference requests passing a Python list of strings to dlpack.to_dlpack. Each request triggers a validation failure but leaks memory before cleanup. By automating this at moderate request rate (e.g., 10-50 req/s), the adversary slowly exhausts the serving container's memory over minutes-to-hours, ultimately causing an OOM crash. In a Kubernetes-hosted inference deployment, this restarts the pod and causes transient service unavailability. In a training cluster with shared GPU memory via DLPack, a malicious insider could disrupt a competitor's training run.

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.