CVE-2022-23569: TensorFlow DoS — MEDIUM

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

6.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A High

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?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

DoS Framework Inference AML.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 recovery MAP-5.1 - Likelihood and magnitude of risks from AI system operation

Frequently Asked Questions

What is CVE-2022-23569?

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.

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

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesinference APIsmulti-tenant ML platforms

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0034 Cost Harvesting

AML.T0049 Exploit 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-617 Reachable Assertion Primary CWE-617 Reachable 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] Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)
[Implementation] Perform input validation on user data.

Source: MITRE CWE corpus.