GHSA-h6gw-r52c-724r

What it actually does

This vulnerability affects TensorFlow packages on PyPI and involves unsafe handling of invalid or malformed inputs that can trigger a NULL pointer dereference or access to an uninitialized pointer. At a technical level, a crafted tensor, model graph, serialized input, or API call reaching the vulnerable code path can cause the TensorFlow process to crash or enter undefined behavior. The primary security consequence is denial of service against applications, model-serving endpoints, training pipelines, batch processing jobs, or notebooks that process attacker-controlled or untrusted TensorFlow inputs.

Why it matters to the business

Organizations using vulnerable TensorFlow versions may experience crashes or instability in machine learning services, inference APIs, data-processing pipelines, or training workloads. If these systems support customer-facing decisions, automation, fraud detection, recommendations, analytics, or operational workflows, exploitation could cause service disruption, failed jobs, degraded availability, missed SLAs, and incident-response costs. Although this advisory is not listed in CISA KEV and no exploit maturity is reported, the high CVSS score and the broad prevalence of TensorFlow in ML ecosystems make remediation important, especially where untrusted models, tensors, or user-supplied ML inputs are accepted.

How an attack unfolds

An attacker first identifies an application, API, notebook, model-serving platform, or batch pipeline that uses a vulnerable TensorFlow package and accepts externally influenced ML data. The attacker then crafts input that exercises the vulnerable TensorFlow code path, such as malformed tensor content, unexpected shapes, invalid serialized model structures, or API parameters that lead TensorFlow to dereference a NULL pointer or use an uninitialized pointer. When the application processes the payload, the underlying TensorFlow runtime crashes or behaves unpredictably. In exposed services, the attacker can repeat requests to keep workers unavailable, exhaust restart capacity, or disrupt dependent workflows. In asynchronous pipelines, the malicious input may cause repeated job failures until the input is quarantined and the vulnerable package is upgraded.

How to fix it

Upgrade TensorFlow from PyPI to a fixed version. Based on the provided package data, tensorflow is fixed in version 2.5.3; deploy 2.5.3 or a later supported TensorFlow release. Rebuild and redeploy containers, virtual environments, notebooks, model-serving images, CI images, and batch worker images that bundle vulnerable TensorFlow versions. Remove or update pinned dependency constraints that force an affected version. Where immediate upgrade is not possible, reduce exposure by rejecting untrusted serialized models or tensors, enforcing strict input validation for tensor shapes and types, isolating model execution in sandboxed workers, applying request/job size limits, using worker restart throttling, and segregating untrusted ML processing from production services.

How to confirm the fix worked

Confirm that all runtime environments resolve TensorFlow to a fixed version by checking package inventories, lockfiles, container images, and active Python environments. Use commands such as `python -c "import tensorflow as tf; print(tf.__version__)"`, `pip show tensorflow`, `pip freeze | grep -i '^tensorflow=='`, and software composition analysis scans to verify that tensorflow is version 2.5.3 or later. Validate that deployed services were rebuilt after dependency updates rather than only updating source repositories. Review SBOMs, image layers, notebook kernels, scheduled jobs, and model-serving workers for stale vulnerable copies. After patching, run regression tests against representative malformed or boundary-case ML inputs and confirm that the service handles invalid input safely without crashing.

Typical attack path

1. Identify an externally reachable or semi-trusted workflow that uses TensorFlow, such as an inference endpoint, model upload service, data-science platform, or batch ML pipeline.
2. Determine whether the workflow accepts attacker-controlled tensors, serialized model artifacts, input arrays, or parameters that are passed into TensorFlow operations.
3. Craft malformed or edge-case input intended to trigger the vulnerable NULL pointer dereference or uninitialized pointer access.
4. Submit the payload to the TensorFlow-backed service or pipeline.
5. Cause the TensorFlow process, worker, notebook kernel, or job runner to crash or terminate abnormally.
6. Repeat submissions or leave the malicious artifact in a processing queue to sustain denial of service until the affected component is patched or the input is blocked.

How to detect it

To assess prior exploitation, review logs from model-serving endpoints, application gateways, API services, notebook platforms, batch workers, orchestration systems, and container runtimes for abnormal TensorFlow process crashes after processing user-supplied inputs or model artifacts. Look for repeated segmentation faults, core dumps, container restarts, worker exits, Python kernel deaths, failed inference requests, or batch job failures clustered around the same requester, uploaded model, dataset, tensor shape, or input file. Examine system logs such as journald, syslog, Kubernetes pod events, container runtime logs, crash-loop telemetry, and application exception logs. If core dumps are available, inspect stack traces for TensorFlow C++ or Python symbols and evidence of NULL pointer dereference or uninitialized memory access. In environments using sanitizers or hardened runtimes, search for AddressSanitizer, UndefinedBehaviorSanitizer, or memory-safety reports involving TensorFlow. Correlate crashes with recent uploads, API requests, queue messages, or dataset ingestion events to identify malicious or malformed trigger inputs. Because there are no public KEV or named threat-actor indicators in the provided data, detection should focus on behavioral crash evidence rather than actor-specific infrastructure.

• Segmentation fault
• Segmentation fault (core dumped)
• Aborted (core dumped)
• core dumped
• CrashLoopBackOff
• OOMKilled
• AddressSanitizer: SEGV
• AddressSanitizer:DEADLYSIGNAL
• runtime error: load of null pointer
• runtime error: member access within null pointer
• use-of-uninitialized-value
• MemorySanitizer: use-of-uninitialized-value
• UndefinedBehaviorSanitizer
• Null pointer dereference
• NULL pointer dereference
• tensorflow/core
• libtensorflow_framework
• tensorflow.python.framework.errors_impl
• Python kernel died
• worker exited unexpectedly

What your security team should do

• Inventory all uses of TensorFlow from PyPI across applications, containers, notebooks, CI/CD images, model-serving platforms, and batch-processing environments.
• Prioritize upgrades for internet-facing inference APIs, model upload workflows, shared data-science platforms, and any pipeline that processes untrusted or third-party ML inputs.
• Upgrade tensorflow to 2.5.3 or a later supported version, then rebuild and redeploy all affected artifacts.
• Add dependency governance controls to prevent reintroduction of vulnerable TensorFlow versions through lockfiles, transitive image layers, or archived notebook environments.
• Restrict acceptance of untrusted serialized models and validate tensor shapes, data types, dimensions, and payload sizes before passing data to TensorFlow.
• Run TensorFlow workloads that process untrusted input in isolated, least-privileged, resource-limited workers to reduce the operational effect of crashes.
• Monitor for repeated TensorFlow worker crashes, segmentation faults, abnormal container restarts, and failed ML jobs that correlate with specific submitted inputs or model artifacts.
• Preserve crash dumps, application logs, request metadata, and submitted ML artifacts when suspicious failures occur so responders can distinguish exploitation from ordinary software defects.