GHSA-xf83-q765-xm6m

What it actually does

The vulnerability is a denial-of-service flaw in TensorFlow's `TensorListScatter` and `TensorListScatterV2` operations when executed in eager mode. A specially crafted input can trigger an internal `CHECK` failure, causing the TensorFlow process to abort rather than returning a handled exception. The impact is process termination and loss of availability for the application, worker, notebook kernel, model-serving component, or data-processing job using the vulnerable TensorFlow package.

Why it matters to the business

Applications and ML workloads that accept untrusted or user-controlled tensor inputs may be crashed on demand, causing failed inference requests, interrupted training or data-processing jobs, service instability, and potential operational disruption. This issue is not known to be in CISA KEV, is not associated with ransomware campaigns, and has no reported mature exploit activity in the provided data, but it has been public since 2022 and should be remediated during normal dependency maintenance, especially for exposed ML APIs or shared compute environments.

How an attack unfolds

An attacker needs a code path where they can influence TensorFlow inputs or model execution that reaches `TensorListScatter` or `TensorListScatterV2` in eager mode. The attacker supplies crafted tensor/list/scatter parameters that violate an internal assumption. Instead of safely rejecting the input, vulnerable TensorFlow versions hit a hard `CHECK` condition and abort the process. In a hosted service, this may terminate the worker handling the request; in batch or notebook environments, it may kill the Python process or kernel. Repeated triggering can create sustained denial of service if process supervisors continuously restart vulnerable workers without input filtering or rate limiting.

How to fix it

Upgrade TensorFlow from PyPI to a fixed version. The provided fixed version is `tensorflow==2.8.4`; where possible, upgrade to the latest supported TensorFlow release that includes this fix and all subsequent security updates. Rebuild and redeploy containers, virtual environments, notebooks, model-serving images, and batch-processing environments that bundle TensorFlow. If immediate upgrade is not possible, reduce exposure by preventing untrusted users from controlling tensor shapes, tensor lists, or operation parameters that can reach `TensorListScatter`/`TensorListScatterV2`, disable or isolate eager execution paths where feasible, enforce request validation, and run ML workloads under process supervisors with rate limits and resource isolation to reduce blast radius.

How to confirm the fix worked

Confirm dependency versions with package inventory and runtime checks such as `python -m pip show tensorflow`, `pip freeze | grep '^tensorflow=='`, or a Python check of `import tensorflow as tf; print(tf.__version__)`. The environment should report `2.8.4` or a later fixed release. Validate all deployed artifacts, including container images, notebook kernels, build caches, CI images, and serverless or batch-job runtimes, not only source repositories. After patching, run regression tests for TensorFlow workloads that use tensor list/scatter functionality and confirm malformed inputs are rejected without process aborts. For exposure assessment, search code and model pipelines for usage of `TensorListScatter`, `TensorListScatterV2`, eager execution, or wrappers that may invoke these operations.

Typical attack path

1. Identify an application, notebook, ML API, or model-serving endpoint using a vulnerable TensorFlow PyPI package.
2. Find or induce a request path that executes TensorFlow eager-mode operations involving `TensorListScatter` or `TensorListScatterV2`.
3. Submit crafted tensor inputs that trigger the vulnerable internal `CHECK` condition.
4. Cause the TensorFlow runtime process to abort, killing the service worker, job, or notebook kernel.
5. Repeat requests, if reachable remotely, to maintain service disruption or exhaust restart capacity.

How to detect it

To determine whether this flaw may already have been exploited, review application logs, model-serving logs, notebook/kernel logs, container runtime logs, job scheduler logs, and crash dumps for TensorFlow process aborts around requests or jobs involving tensor list scatter operations. Look for abrupt Python process exits, `SIGABRT`, core dumps, Kubernetes/container restart loops, notebook kernel restarts, or worker crashes correlated with user-submitted inputs. Search stderr/stdout logs for TensorFlow fatal check failures mentioning `TensorListScatter` or `TensorListScatterV2`. In model-serving environments, correlate 5xx spikes, worker restarts, and request metadata to identify repeated malformed requests from the same client, token, source IP, or job submitter. Because this is a denial-of-service bug rather than a code-execution issue, indicators are primarily crash artifacts and repeated triggering patterns rather than persistent files or malware artifacts.

• TensorListScatter
• TensorListScatterV2
• CHECK failed
• Check failed
• F tensorflow
• SIGABRT
• Aborted (core dumped)
• Fatal Python error
• core dumped
• tensorflow.python.framework.errors_impl
• Process finished with exit code 134
• exit code 134
• Notebook kernel died
• KernelRestarting
• CrashLoopBackOff

What your security team should do

• Inventory all Python environments, containers, notebooks, and ML-serving workloads that include TensorFlow from PyPI.
• Prioritize upgrades for internet-facing ML APIs, multi-tenant notebook platforms, shared training clusters, and services that accept user-supplied tensors or model inputs.
• Upgrade affected TensorFlow installations to `2.8.4` or a later supported fixed release, then rebuild and redeploy dependent artifacts.
• Add dependency scanning gates to CI/CD to prevent reintroduction of vulnerable TensorFlow versions.
• Review application logs and crash telemetry for TensorFlow aborts involving `TensorListScatter`, `TensorListScatterV2`, `CHECK failed`, or `SIGABRT`.
• Apply input validation, request size limits, rate limiting, and workload isolation for ML endpoints that process untrusted input.
• Monitor restart loops, worker crashes, notebook kernel deaths, and abnormal job failure spikes as potential signs of denial-of-service attempts.