CVE-2020-15196: TensorFlow: heap OOB read in sparse/ragged count ops

CRITICAL PoC AVAILABLE

Published September 25, 2020

CISO Take

TensorFlow 2.3.0 allows an attacker with low-privilege API access to trigger out-of-bounds heap reads by supplying malformed sparse/ragged tensors with mismatched weights — CVSS 9.9 with scope change means cross-boundary impact is possible. Any model serving endpoint accepting external tensor inputs is exposed. Patch to TF 2.3.1 immediately and add input shape validation at API boundaries before tensors reach TF ops.

What is the risk?

Severity is critical (CVSS 9.9) and the attack profile is highly favorable for adversaries: network-accessible, low complexity, low privileges, no user interaction, scope change. ML inference APIs exposed to untrusted clients — common in B2B SaaS, MLaaS platforms, and internal data science portals — are the highest-risk surface. No CISA KEV listing and no public EPSS data, but the ease of exploitation via crafted tensor inputs makes this a real operational risk for any unpatched TF 2.3.0 deployment.

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

9.9 / 10

EPSS

0.9%

chance of exploitation in 30 days

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

AV Network

AC Low

PR Low

UI None

S Changed

C High

I High

A High

What should I do?

5 steps

PATCH

Upgrade all TensorFlow deployments from 2.3.0 to 2.3.1 or later (commit 3cbb917b47).
INPUT VALIDATION

Add explicit shape-matching checks between weights and values tensors before invoking sparse/ragged count ops at the application layer — do not rely solely on TF internal validation.
BLAST RADIUS REDUCTION

Run TF serving processes with minimal OS privileges (non-root, seccomp profiles) to limit what heap leaks can expose.
NETWORK CONTROLS

Restrict access to TF serving endpoints to authenticated clients only — the low-privilege requirement means any API key holder is a potential attacker.
DETECTION

Monitor for abnormal tensor shape inputs (weights count != values count) in API request logs; alert on memory error signals in TF serving logs.

How is it classified?

Code Execution Data Extraction Framework Inference Training Data AML.T0010.001 - AI Software AML.T0024 - Exfiltration via AI Inference API AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system for high-risk AI systems

ISO 42001

8.4 - AI system lifecycle — development and deployment

NIST AI RMF

GOVERN 6.1 - Policies and procedures are in place for AI supply chain risk management MANAGE 2.2 - Mechanisms are in place to sustain treatment of identified AI risks

OWASP LLM Top 10

LLM05:2025 - Improper Output Handling

Frequently Asked Questions

What is CVE-2020-15196?

Is CVE-2020-15196 actively exploited?

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

How to fix CVE-2020-15196?

1. PATCH: Upgrade all TensorFlow deployments from 2.3.0 to 2.3.1 or later (commit 3cbb917b47). 2. INPUT VALIDATION: Add explicit shape-matching checks between weights and values tensors before invoking sparse/ragged count ops at the application layer — do not rely solely on TF internal validation. 3. BLAST RADIUS REDUCTION: Run TF serving processes with minimal OS privileges (non-root, seccomp profiles) to limit what heap leaks can expose. 4. NETWORK CONTROLS: Restrict access to TF serving endpoints to authenticated clients only — the low-privilege requirement means any API key holder is a potential attacker. 5. DETECTION: Monitor for abnormal tensor shape inputs (weights count != values count) in API request logs; alert on memory error signals in TF serving logs.

What systems are affected by CVE-2020-15196?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, inference APIs, feature engineering pipelines, multi-tenant ML platforms.

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

CVE-2020-15196 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 0.90%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesinference APIsfeature engineering pipelinesmulti-tenant ML platforms

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0024 Exfiltration via AI Inference API

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: 8.4

NIST AI RMF: GOVERN 6.1, MANAGE 2.2

OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

In Tensorflow version 2.3.0, the `SparseCountSparseOutput` and `RaggedCountSparseOutput` implementations don't validate that the `weights` tensor has the same shape as the data. The check exists for `DenseCountSparseOutput`, where both tensors are fully specified. In the sparse and ragged count weights are still accessed in parallel with the data. But, since there is no validation, a user passing fewer weights than the values for the tensors can generate a read from outside the bounds of the heap buffer allocated for the weights. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.

Exploitation Scenario

An adversary with a valid API key to a TensorFlow Model Server (or any Flask/FastAPI wrapper around TF ops) submits a crafted inference request using SparseCountSparseOutput with a weights tensor containing N-1 elements for N data values. TF reads past the end of the heap-allocated weights buffer. In a multi-tenant ML platform, this can leak another tenant's in-memory batch data or model parameters. In an internal data science API, this could expose training data containing PII. The attack is repeatable and requires no ML expertise — the adversary only needs to know the TF op signature, which is public documentation.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read Primary CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-122 Heap-based Buffer Overflow

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.