CVE-2019-16778: TensorFlow heap overflow

Q: Is CVE-2019-16778 actively exploited?

No confirmed active exploitation of CVE-2019-16778 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2019-16778?

1. Upgrade tensorflow, tensorflow-cpu, or tensorflow-gpu to ≥ 1.15.0 or any 2.x release via pip. 2. Audit running workloads for legacy TF versions using 'pip list' or SBOM scanning of container images in CI/CD. 3. If immediate upgrade is blocked, restrict network access to TF serving endpoints and enforce input shape validation before operations reach UnsortedSegmentSum. 4. Detection: add TF version checks to pipeline gates and container base image scanning policies; alert on any tensorflow <1.15 in production.

Q: What systems are affected by CVE-2019-16778?

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

Q: What is the CVSS score for CVE-2019-16778?

CVE-2019-16778 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.78%.

CISO Take

Despite the critical CVSS 9.8, TensorFlow itself characterized this as 'unlikely to be exploitable' — EPSS (0.325%) confirms negligible real-world exploitation after 5+ years. Any deployment still running TensorFlow < 1.15 should upgrade as a hygiene action, not an emergency. Organizations on TF 1.15+ or any 2.x release are already patched.

What is the risk?

Headline risk (CVSS 9.8, network-accessible, no auth required) is materially overstated relative to practical exploitability. Triggering the vulnerability requires crafting inputs to UnsortedSegmentSum that induce int64→int32 truncation producing negative segment counts — a non-trivial precondition. The EPSS score (0.325%) and absence from CISA KEV confirm near-zero real-world exploitation over 5+ years. Primary residual risk is legacy TF (<1.15) deployments in network-exposed ML serving infrastructure.

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 →
TensorFlow	pip	< 1.15.0	`1.15.0`
195.8K OpenSSF 7.1 3.7K dependents Pushed 2d ago 4% patched ~1372d to patch Full package profile →
TensorFlow	pip	< 1.15.0	`1.15.0`
195.8K OpenSSF 7.1 3.7K dependents Pushed 2d ago 4% patched ~1372d to patch Full package profile →
TensorFlow	pip	< 1.15.0	`1.15.0`
195.8K OpenSSF 7.1 3.7K dependents Pushed 2d ago 4% patched ~1372d to patch Full package profile →

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.8%

chance of exploitation in 30 days

Higher than 51% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

4 steps

Upgrade tensorflow, tensorflow-cpu, or tensorflow-gpu to ≥ 1.15.0 or any 2.x release via pip.
Audit running workloads for legacy TF versions using 'pip list' or SBOM scanning of container images in CI/CD.
If immediate upgrade is blocked, restrict network access to TF serving endpoints and enforce input shape validation before operations reach UnsortedSegmentSum.
Detection: add TF version checks to pipeline gates and container base image scanning policies; alert on any tensorflow <1.15 in production.

How is it classified?

Code Execution Supply Chain Framework Inference AML.T0010.001 - AI Software AML.T0043 - Craft Adversarial Data AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 9 - Risk management system

ISO 42001

8.4 - AI system supply chain management

NIST AI RMF

MANAGE 2.4 - Residual risks from third-party AI components are managed

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2019-16778?

Despite the critical CVSS 9.8, TensorFlow itself characterized this as 'unlikely to be exploitable' — EPSS (0.325%) confirms negligible real-world exploitation after 5+ years. Any deployment still running TensorFlow < 1.15 should upgrade as a hygiene action, not an emergency. Organizations on TF 1.15+ or any 2.x release are already patched.

Is CVE-2019-16778 actively exploited?

No confirmed active exploitation of CVE-2019-16778 has been reported, but organizations should still patch proactively.

How to fix CVE-2019-16778?

1. Upgrade tensorflow, tensorflow-cpu, or tensorflow-gpu to ≥ 1.15.0 or any 2.x release via pip. 2. Audit running workloads for legacy TF versions using 'pip list' or SBOM scanning of container images in CI/CD. 3. If immediate upgrade is blocked, restrict network access to TF serving endpoints and enforce input shape validation before operations reach UnsortedSegmentSum. 4. Detection: add TF version checks to pipeline gates and container base image scanning policies; alert on any tensorflow <1.15 in production.

What systems are affected by CVE-2019-16778?

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

What is the CVSS score for CVE-2019-16778?

CVE-2019-16778 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.78%.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingML inference APIs

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0043 Craft Adversarial Data

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 9

ISO 42001: 8.4

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

In TensorFlow before 1.15, a heap buffer overflow in UnsortedSegmentSum can be produced when the Index template argument is int32. In this case data_size and num_segments fields are truncated from int64 to int32 and can produce negative numbers, resulting in accessing out of bounds heap memory. This is unlikely to be exploitable and was detected and fixed internally in TensorFlow 1.15 and 2.0.

Exploitation Scenario

An adversary with access to a TF-backed REST inference endpoint (e.g., TensorFlow Serving exposing a SavedModel) submits crafted input tensors with values designed to overflow int32 bounds when passed to UnsortedSegmentSum. The truncated negative num_segments value causes an out-of-bounds write into heap memory. With knowledge of the heap layout of the serving process, this can be weaponized for remote code execution — granting the attacker a foothold on the ML serving host with access to model weights, API keys for downstream services, and training data repositories connected to that infrastructure.

Weaknesses (CWE)

CWE-122 Heap-based Buffer Overflow Primary CWE-681 Incorrect Conversion between Numeric Types Primary CWE-681 Incorrect Conversion between Numeric Types Primary CWE-122 Heap-based Buffer Overflow

CWE-122 — Heap-based Buffer Overflow: A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().

Pre-design: Use a language or compiler that performs automatic bounds checking.
[Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.

Source: MITRE CWE corpus.