CVE-2020-15192 — MEDIUM (CVSS 4.3) AI Security Vulnerability

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.23%.

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.

Risk Assessment

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.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
tensorflow	pip	—	No patch
195.0K OpenSSF 7.2 3.7K dependents Pushed 6d ago 4% patched ~1372d to patch Full package profile →
leap	—	—	No patch

Severity & Risk

CVSS 3.1

4.3 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 45% 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, CISA SSVC, EPSS, trickest/cve, and Nuclei templates.

Attack Surface

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A Low

Recommended Action

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.

Classification

DoS Framework Inference AML.T0029 - Denial of AI Service AML.T0034 - Cost Harvesting AML.T0049 - Exploit Public-Facing Application

Compliance Impact

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.23%.

Technical Details

NVD Description

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.