CVE-2018-10055: TensorFlow heap overflow

CISO Take

A crafted XLA compiler configuration file can crash TensorFlow processes or leak adjacent memory contents in versions before 1.7.1. If your ML pipelines accept configuration from any external or untrusted source, this is an information disclosure and stability risk. Upgrade to TensorFlow 1.7.1+ immediately; any deployment still on TF 1.x should be treated as end-of-life and migrated.

What is the risk?

Risk is LOW-MODERATE in modern environments given TensorFlow 1.x is effectively EOL and the attack requires the ability to supply a crafted configuration file to the XLA compiler — typically a privileged operation. However, in shared ML infrastructure (e.g., JupyterHub, MLflow experiment servers, multi-tenant training clusters) where users can submit arbitrary configs, the attack surface widens. The memory read primitive could leak sensitive artifacts from training jobs in collocated environments.

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 →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 35% 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 should I do?

6 steps

Upgrade TensorFlow to 1.7.1 or later (prefer 2.x LTS).
If on TF 1.x for legacy reasons, disable XLA JIT compilation unless strictly required.
Validate and whitelist XLA configuration files — reject configs from untrusted sources.
Run training workloads in isolated processes/containers to limit blast radius of memory exposure.
Audit ML infrastructure for any exposure of TF config endpoints to non-admin users.
Detection: monitor for abnormal TF process crashes (SIGSEGV/SIGABRT) correlated with config file ingestion.

How is it classified?

Code Execution DoS Framework Training Data AML.T0010.001 - AI Software AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity for high-risk AI systems

ISO 42001

8.4 - AI System Risk Assessment

NIST AI RMF

MANAGE 2.2 - Mechanisms are in place to inventory AI systems and manage associated risks

OWASP LLM Top 10

LLM05:2025 - Improper Output Handling / Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2018-10055?

A crafted XLA compiler configuration file can crash TensorFlow processes or leak adjacent memory contents in versions before 1.7.1. If your ML pipelines accept configuration from any external or untrusted source, this is an information disclosure and stability risk. Upgrade to TensorFlow 1.7.1+ immediately; any deployment still on TF 1.x should be treated as end-of-life and migrated.

Is CVE-2018-10055 actively exploited?

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

How to fix CVE-2018-10055?

1. Upgrade TensorFlow to 1.7.1 or later (prefer 2.x LTS). 2. If on TF 1.x for legacy reasons, disable XLA JIT compilation unless strictly required. 3. Validate and whitelist XLA configuration files — reject configs from untrusted sources. 4. Run training workloads in isolated processes/containers to limit blast radius of memory exposure. 5. Audit ML infrastructure for any exposure of TF config endpoints to non-admin users. 6. Detection: monitor for abnormal TF process crashes (SIGSEGV/SIGABRT) correlated with config file ingestion.

What systems are affected by CVE-2018-10055?

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

What is the CVSS score for CVE-2018-10055?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelinesmodel servingML infrastructure

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM05:2025

What are the technical details?

Original Advisory

Invalid memory access and/or a heap buffer overflow in the TensorFlow XLA compiler in Google TensorFlow before 1.7.1 could cause a crash or read from other parts of process memory via a crafted configuration file.

Exploitation Scenario

An adversary with access to a shared ML training platform (e.g., via compromised researcher credentials or a multi-tenant JupyterHub) submits a crafted TensorFlow XLA configuration file targeting a co-located training job. The malformed config triggers a heap buffer overflow in the XLA compiler, either crashing the victim's training run (sabotage) or reading adjacent heap memory — potentially capturing model checkpoint data, API keys loaded as environment variables, or fragments of the training dataset in memory.

Weaknesses (CWE)

CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer Primary

CWE-119 — Improper Restriction of Operations within the Bounds of a Memory Buffer: The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

[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.