CVE-2021-29599 — HIGH (CVSS 7.8) AI Security Vulnerability

Q: Is CVE-2021-29599 actively exploited?

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

Q: How to fix CVE-2021-29599?

1. Patch: Upgrade to TensorFlow 2.5.0 immediately. Backports available for supported branches: 2.4.2, 2.3.3, 2.2.3, 2.1.4. 2. Model provenance: Enforce cryptographic signing and hash verification for all TFLite model artifacts before loading — treat model files as untrusted code. 3. Input validation: Add pre-load model validation that checks Split operator parameters; reject models with num_splits <= 0. 4. Sandboxing: Run TFLite inference in isolated processes/containers with minimal privileges to contain blast radius if exploitation occurs. 5. Detection: Monitor for segfaults or abnormal crashes in TFLite inference processes; anomalous model files from external sources warrant investigation. 6. Supply chain audit: Inventory all TFLite models in use, verify sources, and re-validate any models acquired from third parties or public repositories.

Q: What systems are affected by CVE-2021-29599?

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

Q: What is the CVSS score for CVE-2021-29599?

CVE-2021-29599 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.04%.

CISO Take

Any system that loads TFLite models from untrusted sources is at risk: an attacker crafts a model with num_splits=0 to trigger a division-by-zero crash, potentially enabling code execution given the CVSS C:H/I:H/A:H scoring. Patch immediately to TF 2.5.0 (or backport releases 2.4.2/2.3.3/2.2.3/2.1.4) and enforce strict model provenance controls. The real exposure vector is your ML supply chain — if you pull TFLite models from model hubs, third parties, or allow user-uploaded models, this is higher priority than the local-vector CVSS implies.

Risk Assessment

CVSS 7.8 HIGH with local attack vector understates real-world risk for AI/ML pipelines. The local-vector classification assumes attacker already has system access, but in ML contexts 'loading a model file' is a routine operation that pipelines perform against externally-sourced artifacts. Low attack complexity and low privileges required mean any actor who can supply a malicious TFLite model can trigger the vulnerability. The C:H/I:H/A:H impact triad suggests potential code execution beyond simple DoS, making this a meaningful threat for model-serving infrastructure. Not in CISA KEV; no evidence of active exploitation as of publication date.

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 →

Do you use tensorflow? You're affected.

Severity & Risk

CVSS 3.1

7.8 / 10

EPSS

0.0%

chance of exploitation in 30 days

Higher than 12% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, CISA SSVC, EPSS, trickest/cve, and Nuclei templates.

Attack Surface

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

Recommended Action

6 steps

Patch: Upgrade to TensorFlow 2.5.0 immediately. Backports available for supported branches: 2.4.2, 2.3.3, 2.2.3, 2.1.4.
Model provenance: Enforce cryptographic signing and hash verification for all TFLite model artifacts before loading — treat model files as untrusted code.
Input validation: Add pre-load model validation that checks Split operator parameters; reject models with num_splits <= 0.
Sandboxing: Run TFLite inference in isolated processes/containers with minimal privileges to contain blast radius if exploitation occurs.
Detection: Monitor for segfaults or abnormal crashes in TFLite inference processes; anomalous model files from external sources warrant investigation.
Supply chain audit: Inventory all TFLite models in use, verify sources, and re-validate any models acquired from third parties or public repositories.

Classification

DoS Code Execution Supply Chain Framework Inference AML.T0010.001 - AI Software AML.T0011.000 - Unsafe AI Artifacts AML.T0049 - Exploit Public-Facing Application

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness, and cybersecurity Article 9 - Risk management system

ISO 42001

A.8.2 - AI system risk management during design and development A.9.1 - Monitoring and measurement of AI system performance

NIST AI RMF

GOVERN-6.2 - Policies and procedures for AI risk management across the organization MANAGE-2.2 - Mechanisms to sustain oversight of AI risks from third-party entities

Frequently Asked Questions

What is CVE-2021-29599?

Any system that loads TFLite models from untrusted sources is at risk: an attacker crafts a model with num_splits=0 to trigger a division-by-zero crash, potentially enabling code execution given the CVSS C:H/I:H/A:H scoring. Patch immediately to TF 2.5.0 (or backport releases 2.4.2/2.3.3/2.2.3/2.1.4) and enforce strict model provenance controls. The real exposure vector is your ML supply chain — if you pull TFLite models from model hubs, third parties, or allow user-uploaded models, this is higher priority than the local-vector CVSS implies.

Is CVE-2021-29599 actively exploited?

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

How to fix CVE-2021-29599?

1. Patch: Upgrade to TensorFlow 2.5.0 immediately. Backports available for supported branches: 2.4.2, 2.3.3, 2.2.3, 2.1.4. 2. Model provenance: Enforce cryptographic signing and hash verification for all TFLite model artifacts before loading — treat model files as untrusted code. 3. Input validation: Add pre-load model validation that checks Split operator parameters; reject models with num_splits <= 0. 4. Sandboxing: Run TFLite inference in isolated processes/containers with minimal privileges to contain blast radius if exploitation occurs. 5. Detection: Monitor for segfaults or abnormal crashes in TFLite inference processes; anomalous model files from external sources warrant investigation. 6. Supply chain audit: Inventory all TFLite models in use, verify sources, and re-validate any models acquired from third parties or public repositories.

What systems are affected by CVE-2021-29599?

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

What is the CVSS score for CVE-2021-29599?

CVE-2021-29599 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.04%.

Technical Details

NVD Description

TensorFlow is an end-to-end open source platform for machine learning. The implementation of the `Split` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/e2752089ef7ce9bcf3db0ec618ebd23ea119d0c7/tensorflow/lite/kernels/split.cc#L63-L65). An attacker can craft a model such that `num_splits` would be 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.

Exploitation Scenario

An adversary targets an MLOps pipeline at an organization using TFLite for edge model deployment. They identify that the pipeline auto-validates submitted community models before publishing to an internal model registry. The attacker crafts a TFLite flatbuffer with a Split operation node where num_splits is set to 0. They submit this model through the public submission portal. When the CI/CD pipeline's validation worker loads and runs the model for benchmarking, the TFLite runtime executes the Split kernel, hits the division by zero at split.cc:63-65, and crashes the worker process. With the C:H/I:H/A:H CVSS impact, a more sophisticated variant could target the divide-by-zero to trigger exploitable memory corruption, achieving code execution in the context of the model validation service.