CVE-2022-23565: TensorFlow: DoS via malicious SavedModel AttrDef duplication

MEDIUM

Published February 4, 2022

CISO Take

Any TensorFlow deployment that loads SavedModels from untrusted or externally-supplied sources is vulnerable to availability disruption. An attacker with write access to the model storage path can craft a malicious SavedModel that crashes the TF runtime on load. Patch immediately to TF 2.8.0+ (or cherrypick releases 2.5.3/2.6.3/2.7.1) and enforce strict integrity controls on SavedModel artifacts at rest.

What is the risk?

Medium-severity DoS with low attack complexity once an adversary achieves write access to the model artifact. The network-accessible vector (AV:N) is misleading here — the realistic path requires the attacker to first compromise or manipulate model storage (S3 bucket, shared filesystem, model registry). Impact is availability-only with no confidentiality or integrity exposure, limiting blast radius to service outages. Deployments exposing dynamic model loading from user-controlled paths elevate this to high operational risk.

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 41% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

5 steps

Patch: Upgrade to TensorFlow 2.8.0 or apply cherrypick to 2.5.3, 2.6.3, or 2.7.1.
Immediate workaround: Restrict write access to SavedModel directories to CI/CD service accounts only — no user-facing or external write paths.
Implement cryptographic integrity checks (hash + signature) on SavedModel files before loading in production.
Validate SavedModel structure in staging/pre-prod before deploying to serving infrastructure.
Detection: Monitor for unexpected TF process crashes correlated with model loads — repeated crashes signal active exploitation attempts.

How is it classified?

DoSSupply ChainFrameworkModelAML.T0010.003- Model AML.T0011.000- Unsafe AI Artifacts AML.T0018- Manipulate AI Model AML.T0018.001- Modify AI Model Architecture AML.T0029- Denial of AI Service

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.4-AI risk treatmentA.9.3-Security of AI system operations

NIST AI RMF

MANAGE-4.2-Risk treatment mechanisms are applied to identified AI risksMEASURE-2.5-AI system to be deployed is demonstrated to be valid and reliable

OWASP LLM Top 10

LLM05:2023-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2022-23565?

Is CVE-2022-23565 actively exploited?

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

How to fix CVE-2022-23565?

1. Patch: Upgrade to TensorFlow 2.8.0 or apply cherrypick to 2.5.3, 2.6.3, or 2.7.1. 2. Immediate workaround: Restrict write access to SavedModel directories to CI/CD service accounts only — no user-facing or external write paths. 3. Implement cryptographic integrity checks (hash + signature) on SavedModel files before loading in production. 4. Validate SavedModel structure in staging/pre-prod before deploying to serving infrastructure. 5. Detection: Monitor for unexpected TF process crashes correlated with model loads — repeated crashes signal active exploitation attempts.

What systems are affected by CVE-2022-23565?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, ML inference APIs, MLOps deployment pipelines.

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

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

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesML inference APIsMLOps deployment pipelines

MITRE ATLAS Techniques

AML.T0010.003Model

AML.T0011.000Unsafe AI Artifacts

AML.T0018Manipulate AI Model

AML.T0018.001Modify AI Model Architecture

AML.T0029Denial of AI Service

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.2.4, A.9.3

NIST AI RMF: MANAGE-4.2, MEASURE-2.5

OWASP LLM Top 10: LLM05:2023

What are the technical details?

Original Advisory

Tensorflow is an Open Source Machine Learning Framework. An attacker can trigger denial of service via assertion failure by altering a `SavedModel` on disk such that `AttrDef`s of some operation are duplicated. 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 write access to a shared model registry (e.g., compromised MLOps service account, misconfigured S3 bucket ACL, or insider threat) uploads a crafted SavedModel with duplicate operation AttrDefs. When the model serving tier performs a scheduled model hot-reload or a deployment pipeline promotes the artifact to production, the TF runtime hits the reachable assertion, crashes the serving process, and the ML inference endpoint goes offline. In auto-scaling environments, new instances will also crash on startup until the malicious artifact is removed, causing a sustained outage. This is an effective technique for sabotaging AI-powered services while leaving minimal forensic trace.

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.