CVE-2019-16778 — CRITICAL (CVSS 9.8) AI Security Vulnerability

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

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.

Risk Assessment

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.

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 →
tensorflow	pip	< 1.15.0	`1.15.0`
195.0K OpenSSF 7.2 3.7K dependents Pushed 6d ago 4% patched ~1372d to patch Full package profile →
tensorflow-cpu	pip	< 1.15.0	`1.15.0`
195.0K OpenSSF 7.2 3.7K dependents Pushed 6d ago 4% patched ~1372d to patch Full package profile →
tensorflow-gpu	pip	< 1.15.0	`1.15.0`
195.0K OpenSSF 7.2 3.7K dependents Pushed 6d ago 4% patched ~1372d to patch Full package profile →

Severity & Risk

CVSS 3.1

9.8 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 55% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

Attack Surface

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

Recommended Action

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.

Classification

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

Compliance Impact

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

Technical Details

NVD Description

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.