CVE-2020-15214: TensorFlow Lite: OOB write in segment sum, memory corruption risk

HIGH PoC AVAILABLE
Published September 25, 2020
CISO Take

A crafted TFLite model with unsorted segment IDs can trigger an out-of-bounds write, potentially providing a memory corruption write gadget for chained exploits. Any deployment that loads TFLite models from external or untrusted sources is directly exposed. Upgrade to TensorFlow 2.2.1 or 2.3.1 immediately; if static models are used, add a segment-ID sort verifier as a compensating control.

What is the risk?

CVSS 8.1 (High) with network vector and no required privileges elevates theoretical risk, but high attack complexity grounds it. The real danger is in AI inference pipelines that accept externally-supplied or user-uploaded TFLite models — an attacker with model-upload capability can reliably trigger this. The write-gadget potential means this is not a simple crash: a skilled adversary could chain this into arbitrary code execution on the inference host.

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
8.1 / 10
EPSS
0.6%
chance of exploitation in 30 days
Higher than 42% of all CVEs
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 AC PR UI S C I A
AV Network
AC High
PR None
UI None
S Changed
C Low
I Low
A High

What should I do?

6 steps
  1. Patch: Upgrade to TensorFlow 2.2.1 or 2.3.1 (commit 204945b).

  2. Workaround (static models): Implement a custom Verifier at model load time to assert segment_ids tensor is monotonically non-decreasing before inference.

  3. Workaround (runtime-generated segment IDs): Insert a sort-and-validate step between inference steps before feeding segment_ids.

  4. If segment IDs are generated as model outputs during inference, patching is the only option — no workaround exists.

  5. Detection: Monitor inference processes for SIGSEGV/abnormal exits; segment_sum layer crashes are a signal.

  6. Defense-in-depth: Enforce model signing/provenance checks before loading any TFLite model into production.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.1.2 - AI system risk assessment A.9.3 - Corrective action
NIST AI RMF
MANAGE 2.2 - Mechanisms to respond to and recover from AI risks
OWASP LLM Top 10
LLM05 - Vulnerable and Outdated Components

Frequently Asked Questions

What is CVE-2020-15214?

A crafted TFLite model with unsorted segment IDs can trigger an out-of-bounds write, potentially providing a memory corruption write gadget for chained exploits. Any deployment that loads TFLite models from external or untrusted sources is directly exposed. Upgrade to TensorFlow 2.2.1 or 2.3.1 immediately; if static models are used, add a segment-ID sort verifier as a compensating control.

Is CVE-2020-15214 actively exploited?

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

How to fix CVE-2020-15214?

1. Patch: Upgrade to TensorFlow 2.2.1 or 2.3.1 (commit 204945b). 2. Workaround (static models): Implement a custom Verifier at model load time to assert segment_ids tensor is monotonically non-decreasing before inference. 3. Workaround (runtime-generated segment IDs): Insert a sort-and-validate step between inference steps before feeding segment_ids. 4. If segment IDs are generated as model outputs during inference, patching is the only option — no workaround exists. 5. Detection: Monitor inference processes for SIGSEGV/abnormal exits; segment_sum layer crashes are a signal. 6. Defense-in-depth: Enforce model signing/provenance checks before loading any TFLite model into production.

What systems are affected by CVE-2020-15214?

This vulnerability affects the following AI/ML architecture patterns: model serving, edge inference, training pipelines, mobile/IoT AI deployments.

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

CVE-2020-15214 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.56%.

What is the AI security impact?

Affected AI Architectures

model servingedge inferencetraining pipelinesmobile/IoT AI deployments

MITRE ATLAS Techniques

AML.T0010.001 AI Software
AML.T0011.000 Unsafe AI Artifacts
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.1.2, A.9.3
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger a write out bounds / segmentation fault if the segment ids are not sorted. Code assumes that the segment ids are in increasing order, using the last element of the tensor holding them to determine the dimensionality of output tensor. This results in allocating insufficient memory for the output tensor and in a write outside the bounds of the output array. This usually results in a segmentation fault, but depending on runtime conditions it can provide for a write gadget to be used in future memory corruption-based exploits. The issue is patched in commit 204945b19e44b57906c9344c0d00120eeeae178a and is released in TensorFlow versions 2.2.1, or 2.3.1. A potential workaround would be to add a custom `Verifier` to the model loading code to ensure that the segment ids are sorted, although this only handles the case when the segment ids are stored statically in the model. A similar validation could be done if the segment ids are generated at runtime between inference steps. If the segment ids are generated as outputs of a tensor during inference steps, then there are no possible workaround and users are advised to upgrade to patched code.

Exploitation Scenario

An adversary targeting an AI inference API that accepts user-uploaded TFLite models crafts a malicious model containing a segment_sum operation with deliberately unsorted segment IDs. When the victim's inference server loads and executes the model, TFLite reads the last segment ID to determine output tensor size, allocates insufficient memory, then writes beyond the allocation boundary. On most runtimes this causes a segfault and DoS. On a target with known memory layout (e.g., a containerized inference service with predictable ASLR), the write gadget can be leveraged to overwrite adjacent heap structures, potentially escalating to arbitrary code execution on the inference host — giving the adversary a foothold in the ML serving infrastructure.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:H

Timeline

Published
September 25, 2020
Last Modified
November 21, 2024
First Seen
September 25, 2020

Related Vulnerabilities