CVE-2022-36002: TensorFlow DoS — HIGH

Q: Is CVE-2022-36002 actively exploited?

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

Q: How to fix CVE-2022-36002?

1. Patch: Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 — apply commit 4419d10d576adefa36b0e0a9425d2569f7c0189f. 2. No workaround exists per the advisory. 3. Interim hardening: add input validation at the API layer to reject nonscalar batch IDs before they reach TF ops. 4. Detection: monitor TF Serving process restarts and HTTP 503 spikes as DoS indicators. 5. Network controls: restrict TensorFlow Serving ports to internal networks only; avoid direct public exposure of TF inference endpoints.

Q: What systems are affected by CVE-2022-36002?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference pipelines, training pipelines, batch processing systems.

Q: What is the CVSS score for CVE-2022-36002?

CVE-2022-36002 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.38%.

CISO Take

A network-accessible denial-of-service in TensorFlow's Unbatch op allows any unauthenticated attacker to crash ML serving infrastructure by sending a nonscalar input ID. If your inference endpoints accept external inputs and run TF < 2.10.0, this is a direct availability risk. Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 immediately — no workaround exists.

What is the risk?

High availability risk for exposed TensorFlow inference endpoints. CVSS 7.5 with AV:N/AC:L/PR:N/UI:N means trivial remote exploitation requiring zero authentication or user interaction. Not in CISA KEV and no public exploit confirmed, but the attack primitive (malformed input to crash a service) is within reach of any attacker who can reach the endpoint. Risk amplifies in multi-tenant ML platforms or APIs serving external customers.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
TensorFlow	pip	—	No patch
195.8K OpenSSF 7.1 3.7K dependents Pushed 3d ago 4% patched ~1372d to patch Full package profile →

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 30% 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 None

UI None

S Unchanged

C None

I None

A High

What should I do?

5 steps

Patch: Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 — apply commit 4419d10d576adefa36b0e0a9425d2569f7c0189f.
No workaround exists per the advisory.
Interim hardening: add input validation at the API layer to reject nonscalar batch IDs before they reach TF ops.
Detection: monitor TF Serving process restarts and HTTP 503 spikes as DoS indicators.
Network controls: restrict TensorFlow Serving ports to internal networks only; avoid direct public exposure of TF inference endpoints.

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

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

8.4 - AI System Operation

NIST AI RMF

MANAGE-2.4 - Residual risks and affected parties

OWASP LLM Top 10

LLM10 - Model Denial of Service

Frequently Asked Questions

What is CVE-2022-36002?

A network-accessible denial-of-service in TensorFlow's Unbatch op allows any unauthenticated attacker to crash ML serving infrastructure by sending a nonscalar input ID. If your inference endpoints accept external inputs and run TF < 2.10.0, this is a direct availability risk. Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 immediately — no workaround exists.

Is CVE-2022-36002 actively exploited?

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

How to fix CVE-2022-36002?

1. Patch: Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 — apply commit 4419d10d576adefa36b0e0a9425d2569f7c0189f. 2. No workaround exists per the advisory. 3. Interim hardening: add input validation at the API layer to reject nonscalar batch IDs before they reach TF ops. 4. Detection: monitor TF Serving process restarts and HTTP 503 spikes as DoS indicators. 5. Network controls: restrict TensorFlow Serving ports to internal networks only; avoid direct public exposure of TF inference endpoints.

What systems are affected by CVE-2022-36002?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference pipelines, training pipelines, batch processing systems.

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

CVE-2022-36002 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.38%.

What is the AI security impact?

Affected AI Architectures

model servinginference pipelinestraining pipelinesbatch processing systems

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: Article 15

ISO 42001: 8.4

NIST AI RMF: MANAGE-2.4

OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

TensorFlow is an open source platform for machine learning. When `Unbatch` receives a nonscalar input `id`, it gives a `CHECK` fail that can trigger a denial of service attack. We have patched the issue in GitHub commit 4419d10d576adefa36b0e0a9425d2569f7c0189f. The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range. There are no known workarounds for this issue.

Exploitation Scenario

An attacker identifies a public-facing model serving API backed by TensorFlow that uses the Unbatch operation (common in sequence-to-batch and batch-to-sequence pipelines). By crafting a REST or gRPC request with a nonscalar tensor as the batch ID field, the attacker triggers a CHECK assertion failure inside the TF runtime. The process terminates immediately. In a Kubernetes deployment, the pod restarts but the attacker repeats the request in a loop, maintaining a persistent DoS against the inference endpoint. No ML expertise required — the attacker needs only to know TensorFlow is in use and the endpoint accepts batched inputs.

Weaknesses (CWE)

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.