GHSA-wcv5-vrvr-3rx2

What it actually does

The vulnerability is an integer overflow/wraparound in TensorFlow caused by insufficient validation of numeric values such as tensor dimensions, sizes, offsets, or counts before arithmetic is performed. In vulnerable versions, a crafted model, graph, tensor, or input payload can cause calculations to wrap to an unexpected value, which may lead to process crashes, memory access errors, incorrect allocation sizing, or other denial-of-service conditions in applications that load or process attacker-controlled TensorFlow content.

Why it matters to the business

Organizations using vulnerable TensorFlow versions in ML training, inference, data-processing, or model-validation workflows may experience service crashes or job failures if untrusted or malformed ML content is processed. The most likely business consequence is disruption to ML-backed services or pipelines rather than broad system compromise. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported exploit maturity in the provided data, but it has been public for a long time, so vulnerable deployments should still be upgraded as part of dependency hygiene.

How an attack unfolds

An attacker first identifies an application, service, notebook environment, batch pipeline, or API endpoint that uses a vulnerable TensorFlow package and accepts externally influenced models, serialized graphs, tensor data, or files that are parsed by TensorFlow. The attacker crafts input with abnormal numeric values, such as dimensions or size fields that cause an arithmetic operation inside TensorFlow to exceed the representable integer range and wrap around. When the application loads or processes that content, TensorFlow may allocate the wrong amount of memory, compute an invalid offset, or hit an internal error condition. The practical result is most likely a crash or failed ML job, causing denial of service for the affected process or workflow. There is no indication from the provided data that this issue is being actively exploited in the wild or used by named threat actors.

How to fix it

Upgrade TensorFlow from PyPI to a fixed version. The provided fixed version is tensorflow 2.5.3; use 2.5.3 or a later supported non-vulnerable TensorFlow release. Update dependency lockfiles, container images, notebooks, CI runners, model-serving images, and batch-processing environments that bundle TensorFlow. Remove stale vulnerable wheels from build caches and artifact repositories where possible. If immediate upgrade is not possible, reduce exposure by rejecting untrusted TensorFlow models or serialized graphs, validating tensor shapes and file formats before processing, sandboxing model ingestion and conversion workflows, applying CPU and memory limits, and isolating ML parsing jobs from production control-plane services.

How to confirm the fix worked

Confirm that all runtime and build environments use a fixed TensorFlow package by checking dependency inventories, SBOMs, lockfiles, and running package queries such as `pip show tensorflow`, `pip freeze`, or equivalent environment-specific tooling. Verify at runtime with `python -c "import tensorflow as tf; print(tf.__version__)"` and ensure the result is 2.5.3 or later, or another vendor-confirmed non-vulnerable release. Rebuild and redeploy containers after upgrading; do not rely only on source repository changes. Run software composition analysis tools such as pip-audit, Safety, Snyk, Dependabot, or similar scanners to confirm the advisory no longer appears. For services that process external ML content, perform negative testing with malformed or oversized tensor/model inputs in a controlled environment to ensure the service fails safely without crashing the production worker process.

Typical attack path

1. Find an exposed application, API, batch job, or ML workflow that processes user-supplied or third-party TensorFlow models, graphs, tensors, or data files.
2. Determine or infer that the target uses a vulnerable TensorFlow PyPI package version prior to the fixed release.
3. Create malformed ML content containing numeric fields that can trigger integer overflow or wraparound during TensorFlow parsing or execution.
4. Submit or cause the vulnerable service to load the crafted content.
5. Trigger TensorFlow processing of the malformed object, causing a crash, memory error, failed job, or service interruption.
6. Optionally repeat submissions to maintain denial of service against the affected ML workflow or service.

How to detect it

There are no reliable public, vulnerability-specific indicators of compromise for this advisory from the provided data. Detection should focus on evidence of suspicious crashes or repeated processing failures in services that use TensorFlow and accept untrusted models or tensor-like inputs. Review application logs, container logs, job scheduler logs, notebook execution logs, model-serving logs, API gateway logs, and crash/core-dump telemetry for TensorFlow stack traces, abnormal termination, segmentation faults, allocation failures, or process restarts shortly after ingesting external ML artifacts. Correlate failures with upload events, model conversion requests, inference requests containing unusual tensor shapes, large or negative dimension-like values, unexpected file formats, or repeated submissions from the same source. If memory-safety instrumentation is enabled, search sanitizer output for integer overflow, invalid allocation size, heap-buffer-overflow, or out-of-bounds access involving TensorFlow libraries. Absence of these artifacts does not prove non-exploitation because exploitation may only cause transient worker crashes without durable forensic traces.

What your security team should do

• Inventory all systems, containers, notebooks, CI jobs, model-serving platforms, and batch pipelines that include the TensorFlow PyPI package.
• Prioritize upgrades where TensorFlow processes user-uploaded files, third-party models, externally sourced datasets, or automated model-conversion jobs.
• Upgrade TensorFlow to 2.5.3 or later and rebuild dependent images and lockfiles.
• Add dependency scanning gates to prevent vulnerable TensorFlow versions from being reintroduced.
• Restrict or sandbox processing of untrusted TensorFlow models, graphs, and serialized data.
• Apply memory, CPU, timeout, and worker-restart controls around ML parsing and inference services to limit denial-of-service impact.
• Review recent crashes or abnormal ML job failures for evidence of malformed input, especially on internet-facing or user-facing ML ingestion paths.
• Because this is not KEV-listed and has no known exploit maturity in the provided data, handle as a controlled remediation item unless the vulnerable component is exposed to untrusted input, in which case treat it as higher priority.