CVE-2022-23569: TensorFlow: DoS via reachable assertions in ML ops

MEDIUM

Published February 3, 2022

CISO Take

Any authenticated user with low privileges can crash TensorFlow-based inference services by sending crafted inputs that trigger CHECK assertion failures across multiple operations. This is a multi-tenant risk: a single bad actor or compromised account can take down shared ML serving infrastructure. Patch immediately to TF 2.8.0 (or backports 2.7.1/2.6.3/2.5.3) and restrict inference endpoint access to trusted principals.

What is the risk?

Medium-High in production ML serving contexts despite the 6.5 CVSS score. Network-accessible with low complexity and only low privileges required makes this easily exploitable from within any multi-tenant environment or by any API consumer. The availability-only impact (A:H, C:N, I:N) limits blast radius to service disruption, but repeated crashes of TF Serving nodes can cause SLA failures, failed batch jobs, and cascading outages in real-time inference pipelines. No active exploitation reported; no CISA KEV entry.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
TensorFlow	pip	—	No patch
201.3KOpenSSF 7.63.4K dependentsPushed 5d ago4% patched~1372d to patchFull package profile →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 40% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

6 steps

Upgrade TensorFlow to 2.8.0 or apply official backports: 2.7.1, 2.6.3, 2.5.3.
Audit all TF Serving and training endpoints for network exposure; restrict to authenticated and authorized principals only.
Implement input validation and schema enforcement before TF operations to reject malformed inputs at the API boundary.
Add rate limiting and circuit breakers on inference endpoints to limit crash frequency.
Monitor TF Serving process restarts and unexpected crashes as a detection signal.
If immediate patching is not possible, run TF Serving in isolated containers with auto-restart policies to minimize downtime per crash.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSFrameworkInferenceAML.T0029- Denial of AI Service AML.T0034- Cost Harvesting AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.9.4-AI system availability and resilience

NIST AI RMF

MANAGE-2.2-Mechanisms for emergency response and recoveryMAP-5.1-Likelihood and magnitude of risks from AI system operation

Frequently Asked Questions

What is CVE-2022-23569?

Is CVE-2022-23569 actively exploited?

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

How to fix CVE-2022-23569?

1. Upgrade TensorFlow to 2.8.0 or apply official backports: 2.7.1, 2.6.3, 2.5.3. 2. Audit all TF Serving and training endpoints for network exposure; restrict to authenticated and authorized principals only. 3. Implement input validation and schema enforcement before TF operations to reject malformed inputs at the API boundary. 4. Add rate limiting and circuit breakers on inference endpoints to limit crash frequency. 5. Monitor TF Serving process restarts and unexpected crashes as a detection signal. 6. If immediate patching is not possible, run TF Serving in isolated containers with auto-restart policies to minimize downtime per crash.

What systems are affected by CVE-2022-23569?

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

What is the CVSS score for CVE-2022-23569?

CVE-2022-23569 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.46%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesinference APIsmulti-tenant ML platforms

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034Cost Harvesting

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.9.4

NIST AI RMF: MANAGE-2.2, MAP-5.1

What are the technical details?

Original Advisory

Tensorflow is an Open Source Machine Learning Framework. Multiple operations in TensorFlow can be used to trigger a denial of service via `CHECK`-fails (i.e., assertion failures). This is similar to TFSA-2021-198 and has similar fixes. We have patched the reported issues in multiple GitHub commits. It is possible that other similar instances exist in TensorFlow, we will issue fixes as these are discovered. The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range.

Exploitation Scenario

An adversary with a low-privilege API key to a TF Serving endpoint (e.g., a shared ML platform tenant or a compromised service account) iterates over exposed model operations, sending edge-case inputs—malformed tensors, unexpected dtypes, or out-of-range values—that trigger internal CHECK assertion failures. Each crafted request immediately crashes the TF Serving process. With no rate limiting, the adversary can sustain a continuous DoS: as the process restarts, another crafted request immediately re-triggers the crash, effectively keeping the service unavailable for all users of the endpoint.

Weaknesses (CWE)

CWE-617Reachable AssertionPrimary CWE-617Reachable Assertion

CWE-617 — Reachable Assertion: The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

[Implementation] If the assertion statement is required (e.g., for security or reliability), change the invoking code to avoid the conditions that trigger the assertion.
[Implementation] Consider changing the assertion to some other less "fatal" error. This might not be easy to implement, since other code may be needed to handle the error.

Source: MITRE CWE corpus.