CVE-2022-35999: TensorFlow: DoS via empty Conv2DBackpropInput tensors

HIGH

Published September 16, 2022

CISO Take

Any TensorFlow deployment accepting user-controlled inputs to Conv2D-based models is vulnerable to unauthenticated remote crash with CVSS 7.5. Upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 immediately — no workarounds exist. Prioritize model serving endpoints exposed to untrusted traffic (TF Serving, REST wrappers).

What is the risk?

High severity with critical exploitability characteristics: no authentication required, no user interaction, network-exploitable, and low attack complexity — any adversary can trigger it by crafting a tensor with a zero-dimension (e.g., shape [3,1,0,1]). Impact is limited to availability (DoS); no RCE or data exfiltration path exists. Risk is elevated for organizations running public-facing inference endpoints or multi-tenant training APIs built on unpatched TensorFlow. Not in CISA KEV and no known active exploitation, but the trivial exploit path warrants prompt patching.

What systems are affected?

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

Do you use TensorFlow? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 41% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

6 steps

Patch immediately: upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 (cherry-picked fix in all supported branches).
No vendor workaround exists — patching is the only remediation.
Defense-in-depth: add input validation at the application layer to reject tensors with any zero-dimension before reaching TensorFlow ops.
Deploy process supervisors (systemd restart policies, Kubernetes liveness probes) to auto-recover crashed serving instances.
Add monitoring/alerting on abnormal process restarts in ML serving infrastructure.
Inventory all TensorFlow versions across model serving, training, and MLOps tooling using SBOM or dependency scanning.

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

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

8.4-AI system operation and monitoring

NIST AI RMF

MANAGE-2.2-Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM10-Model Denial of Service

Frequently Asked Questions

What is CVE-2022-35999?

Is CVE-2022-35999 actively exploited?

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

How to fix CVE-2022-35999?

1. Patch immediately: upgrade to TensorFlow 2.10.0, 2.9.1, 2.8.1, or 2.7.2 (cherry-picked fix in all supported branches). 2. No vendor workaround exists — patching is the only remediation. 3. Defense-in-depth: add input validation at the application layer to reject tensors with any zero-dimension before reaching TensorFlow ops. 4. Deploy process supervisors (systemd restart policies, Kubernetes liveness probes) to auto-recover crashed serving instances. 5. Add monitoring/alerting on abnormal process restarts in ML serving infrastructure. 6. Inventory all TensorFlow versions across model serving, training, and MLOps tooling using SBOM or dependency scanning.

What systems are affected by CVE-2022-35999?

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

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

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

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinescomputer vision inference

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034Cost Harvesting

AML.T0049Exploit 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: LLM10

What are the technical details?

Original Advisory

TensorFlow is an open source platform for machine learning. When `Conv2DBackpropInput` receives empty `out_backprop` inputs (e.g. `[3, 1, 0, 1]`), the current CPU/GPU kernels `CHECK` fail (one with dnnl, the other with cudnn). This can be used to trigger a denial of service attack. We have patched the issue in GitHub commit 27a65a43cf763897fecfa5cdb5cc653fc5dd0346. 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 adversary discovers a public-facing model API (TensorFlow Serving, Flask/FastAPI wrapper, or Vertex AI endpoint) running a CNN-based computer vision model. They send a POST request with a crafted input tensor of shape [3, 1, 0, 1] — a valid-looking but empty tensor — targeting the Conv2DBackpropInput kernel. The CHECK assertion fires in the dnnl or cudnn kernel, crashing the TensorFlow runtime process. On containerized deployments without restart policies, this causes sustained service unavailability. On multi-tenant inference platforms, a single malicious user can DoS shared serving infrastructure affecting all tenants.

Weaknesses (CWE)

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.