GHSA-cqvq-fvhr-v6hc

What it actually does

This vulnerability is an improper input validation flaw in TensorFlow's SobolSample operation. A crafted call, graph, model, or workload can provide invalid input that reaches an internal CHECK assertion instead of being rejected safely. In vulnerable versions, that assertion failure can terminate the TensorFlow process, causing a denial of service for the application, job, notebook kernel, model-serving process, or pipeline using the affected TensorFlow package.

Why it matters to the business

The primary risk is service disruption rather than data theft or code execution. Systems that accept untrusted models, user-supplied tensors, notebooks, ML jobs, or API requests that can influence TensorFlow operations could be crashed repeatedly, affecting model serving, batch analytics, experimentation platforms, and dependent business workflows. This issue is not listed in CISA KEV, has no known exploit maturity in the supplied data, and was published in 2022, so remediation should be handled through normal dependency hygiene unless the affected TensorFlow functionality is exposed to untrusted users.

How an attack unfolds

An attacker first needs a way to cause an application to execute TensorFlow code that invokes the SobolSample operation, such as by submitting a crafted model, graph, notebook, ML job, or request that controls relevant operation inputs. The attacker supplies malformed or out-of-range input that is not validated before the operation reaches an internal CHECK condition. Instead of returning a controlled validation error, the vulnerable TensorFlow runtime aborts the process. If the service automatically restarts, the attacker can repeat the request or resubmit the workload to create a sustained denial-of-service condition.

How to fix it

Upgrade the TensorFlow PyPI package to a fixed version. Based on the supplied fixed-version data, use tensorflow 2.8.4 or later. Rebuild containers, virtual environments, notebook images, model-serving images, and CI/CD artifacts that pin or vendor an older TensorFlow version. If immediate upgrade is not possible, restrict untrusted users from submitting arbitrary TensorFlow graphs, SavedModels, notebooks, or jobs; validate model inputs and operation parameters before execution; isolate user-submitted ML workloads in separate worker processes; and configure supervisors to limit crash-loop impact.

How to confirm the fix worked

Confirm the installed TensorFlow package version is 2.8.4 or later using package inventory, lockfiles, container SBOMs, or commands such as `pip show tensorflow` and `python -c "import tensorflow as tf; print(tf.__version__)"`. Verify that deployed runtime images and notebook kernels use the rebuilt environment, not only the source repository. Review dependency lockfiles for older transitive or pinned TensorFlow versions. Where safe, test that malformed SobolSample inputs are rejected without terminating the hosting process. Also verify that services accepting user-supplied models or ML jobs have isolation and restart controls in place.

Typical attack path

1. Identify an application, ML platform, notebook environment, model-serving endpoint, or batch pipeline running a vulnerable TensorFlow PyPI package.
2. Find a path to influence TensorFlow execution, such as uploading a model, submitting a graph, running a notebook/job, or sending API input that reaches TensorFlow operations.
3. Craft input that invokes SobolSample with invalid parameters that trigger the missing validation path.
4. Submit the crafted workload and cause the TensorFlow process to hit a CHECK failure and abort.
5. Repeat the submission to crash restarted workers or disrupt queued ML workloads.

How to detect it

Look for evidence of prior denial-of-service activity rather than compromise of confidentiality or persistence. Review application logs, ML job logs, notebook kernel logs, model-serving logs, container stdout/stderr, orchestration events, systemd logs, crash reports, and core dump records for TensorFlow processes that aborted after executing or loading workloads involving SobolSample. Correlate crashes with user-submitted models, notebooks, batch jobs, API requests, or uploaded artifacts around the same time. Search model repositories, SavedModel metadata, serialized graphs, notebooks, and job definitions for SobolSample usage, especially when followed by abnormal process exits, restart loops, failed health checks, or SIGABRT/core-dump events. There are no known threat actors or KEV exploitation reports in the supplied data, so detection should focus on anomalous crashes and abuse of exposed ML execution paths.

• SobolSample
• tf.raw_ops.SobolSample
• CHECK failure in SobolSample
• Check failed
• CHECK failed
• SIGABRT
• Aborted (core dumped)
• core dumped
• tensorflow.python.framework.errors_impl
• tensorflow/core

What your security team should do

• Inventory all Python environments, containers, notebooks, model-serving images, and batch ML workers that include the TensorFlow PyPI package.
• Prioritize upgrades to tensorflow 2.8.4 or later for internet-facing, multi-tenant, or user-extensible ML systems where untrusted users can submit models, graphs, notebooks, or jobs.
• Rebuild and redeploy runtime images after updating dependencies; do not rely solely on updating development lockfiles.
• Restrict arbitrary model or graph execution from untrusted users where practical, and run untrusted ML workloads in isolated worker processes with resource and restart limits.
• Add monitoring for repeated TensorFlow worker crashes, SIGABRT events, and log entries mentioning SobolSample or CHECK failures.
• Because this issue is not KEV-listed and no exploit maturity is reported, handle lower-exposure internal-only deployments through routine patch cycles while still removing stale vulnerable TensorFlow versions.