CVE-2022-41910: TensorFlow Grappler: OOB read crashes or leaks memory

Q: Is CVE-2022-41910 actively exploited?

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

Q: How to fix CVE-2022-41910?

1. PATCH: Upgrade TensorFlow to 2.11.0 (preferred), or cherrypick fix to 2.10.1, 2.9.3, or 2.8.4 from commit a65411a1d. 2. ISOLATE: If patching is not immediately possible, restrict TensorFlow Serving endpoints to authenticated internal clients only — eliminate unauthenticated network exposure. 3. INPUT VALIDATION: Sanitize and validate graph inputs before passing to Grappler; reject models from untrusted sources. 4. DETECT: Monitor TF Serving pods/processes for unexpected crashes (OOM kills, segfaults) or memory anomalies; correlate with unusual model upload activity. 5. SCAN: Audit all environments running TF < 2.8.4 / 2.9.3 / 2.10.1 / 2.11.0 and prioritize those with public-facing inference APIs.

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

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

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

CVE-2022-41910 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.40%.

CRITICAL

Published December 6, 2022

CISO Take

A network-accessible, zero-auth out-of-bounds read in TensorFlow's Grappler optimizer (CVSS 9.1) allows attackers to crash inference services or leak memory contents by submitting crafted computation graphs. Any TensorFlow serving endpoint accepting external model inputs is exposed. Patch immediately to TF 2.11.0, 2.10.1, 2.9.3, or 2.8.4 — no workaround short of network isolation.

What is the risk?

Severity is high in practice: CVSS 9.1 with no authentication, no user interaction, and network accessibility creates a low-barrier attack surface. Confidentiality impact is rated HIGH due to potential memory disclosure from out-of-bounds reads, which could expose model weights, intermediate tensors, or runtime secrets. Availability impact is also HIGH given crash potential. Not yet in CISA KEV, suggesting limited confirmed in-the-wild exploitation as of publication date, but the trivial exploit conditions make weaponization straightforward. Organizations running TensorFlow Serving or similar inference APIs exposed to untrusted inputs face immediate risk.

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

9.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 32% 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 High

I None

A High

What should I do?

5 steps

PATCH

Upgrade TensorFlow to 2.11.0 (preferred), or cherrypick fix to 2.10.1, 2.9.3, or 2.8.4 from commit a65411a1d.
ISOLATE

If patching is not immediately possible, restrict TensorFlow Serving endpoints to authenticated internal clients only — eliminate unauthenticated network exposure.
INPUT VALIDATION

Sanitize and validate graph inputs before passing to Grappler; reject models from untrusted sources.
DETECT

Monitor TF Serving pods/processes for unexpected crashes (OOM kills, segfaults) or memory anomalies; correlate with unusual model upload activity.
SCAN

Audit all environments running TF < 2.8.4 / 2.9.3 / 2.10.1 / 2.11.0 and prioritize those with public-facing inference APIs.

How is it classified?

Code Execution DoS Data Extraction Framework Inference Training Data AML.T0010.001 - AI Software AML.T0043 - Craft Adversarial Data AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.7 - AI system security and resilience

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain management of AI risk MAP 5.1 - Likelihood and magnitude of each risk are estimated

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2022-41910?

Is CVE-2022-41910 actively exploited?

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

How to fix CVE-2022-41910?

1. PATCH: Upgrade TensorFlow to 2.11.0 (preferred), or cherrypick fix to 2.10.1, 2.9.3, or 2.8.4 from commit a65411a1d. 2. ISOLATE: If patching is not immediately possible, restrict TensorFlow Serving endpoints to authenticated internal clients only — eliminate unauthenticated network exposure. 3. INPUT VALIDATION: Sanitize and validate graph inputs before passing to Grappler; reject models from untrusted sources. 4. DETECT: Monitor TF Serving pods/processes for unexpected crashes (OOM kills, segfaults) or memory anomalies; correlate with unusual model upload activity. 5. SCAN: Audit all environments running TF < 2.8.4 / 2.9.3 / 2.10.1 / 2.11.0 and prioritize those with public-facing inference APIs.

What systems are affected by CVE-2022-41910?

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

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

CVE-2022-41910 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.40%.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesinference APIsMLOps pipelines accepting external models

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0043 Craft Adversarial Data

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.6.2.7

NIST AI RMF: MANAGE 2.2, MAP 5.1

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

TensorFlow is an open source platform for machine learning. The function MakeGrapplerFunctionItem takes arguments that determine the sizes of inputs and outputs. If the inputs given are greater than or equal to the sizes of the outputs, an out-of-bounds memory read or a crash is triggered. We have patched the issue in GitHub commit a65411a1d69edfb16b25907ffb8f73556ce36bb7. The fix will be included in TensorFlow 2.11.0. We will also cherrypick this commit on TensorFlow 2.8.4, 2.9.3, and 2.10.1.

Exploitation Scenario

An adversary identifies a publicly accessible TensorFlow Serving endpoint (e.g., via Shodan or API enumeration). They craft a malicious SavedModel or TFLite graph where the MakeGrapplerFunctionItem call receives input tensor descriptors sized greater than or equal to the declared output sizes — a simple integer manipulation in the protobuf graph definition. Submitting this via a standard predict() API call triggers the out-of-bounds read. In a crash scenario, the model server dies and becomes unavailable. In an information disclosure scenario, heap memory contents (potentially including cached model weights, API tokens in memory, or other tenant data in multi-tenant serving) are leaked in error responses or logs. No credentials or AI/ML expertise required — just knowledge of TensorFlow's protobuf schema.

Weaknesses (CWE)

CWE-125 Out-of-bounds Read

CWE-125 — Out-of-bounds Read: The product reads data past the end, or before the beginning, of the intended buffer.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use a language that provides appropriate memory abstractions.

Source: MITRE CWE corpus.