GHSA-43q8-3fv7-pr5x

What it actually does

This vulnerability is an integrity-validation weakness in the TensorFlow PyPI package. Affected versions do not properly validate an integrity check value, which can allow tampered or malformed TensorFlow-related content to be accepted when it should be rejected. In practical terms, the flaw can undermine assumptions that a model, checkpoint, serialized tensor, or other TensorFlow artifact has not been modified. Depending on how TensorFlow is used, successful exploitation may lead to corrupted model behavior, failed processing, denial of service, or unsafe handling of untrusted ML artifacts. The issue is fixed in tensorflow 2.5.3.

Why it matters to the business

Organizations using vulnerable TensorFlow versions may unknowingly process altered or malicious machine-learning artifacts, which can affect model reliability, data-processing correctness, and service availability. For businesses that rely on ML outputs for automation, fraud detection, recommendations, safety decisions, or analytics, this can translate into incorrect decisions, degraded customer-facing services, incident response costs, and loss of trust in model integrity. This issue is not listed in CISA KEV and no exploit maturity is reported in the provided data, but it is long-published and should be treated as a hygiene gap if still present.

How an attack unfolds

An attacker first identifies an application, pipeline, notebook, batch job, or service that uses a vulnerable TensorFlow package and accepts TensorFlow artifacts from an untrusted or weakly controlled source. The attacker then prepares a tampered artifact whose integrity check value is invalid, incomplete, or otherwise crafted so that the vulnerable validation logic does not reject it. The artifact is delivered through a model registry, shared storage location, data pipeline, user upload, dependency bundle, CI/CD artifact, or other ingestion path. When the vulnerable TensorFlow runtime processes the artifact, the expected integrity boundary is bypassed, allowing the modified content to influence downstream TensorFlow behavior. The visible result may be incorrect inference or training results, unexpected exceptions, pipeline failure, or abnormal model behavior rather than a classic interactive compromise. There are no named threat actors or known active exploitation signals in the provided data.

How to fix it

Upgrade the TensorFlow PyPI package to a fixed version. Based on the provided affected-product data, upgrade tensorflow to version 2.5.3 or later. Rebuild and redeploy containers, virtual environments, notebooks, batch images, and ML runtime images that vendor or pin TensorFlow. Remove stale dependency lockfiles or base images that continue to pull vulnerable TensorFlow builds. If immediate upgrade is not possible, restrict TensorFlow artifact ingestion to trusted sources only, enforce independent cryptographic verification of model and checkpoint artifacts, require signed artifacts from model registries, block anonymous or unauthenticated artifact uploads, and isolate workloads that process untrusted ML content.

How to confirm the fix worked

Confirm the installed TensorFlow version is fixed by checking package inventory, lockfiles, container SBOMs, and runtime environments for tensorflow versions older than 2.5.3. Validate with commands such as `python -c "import tensorflow as tf; print(tf.__version__)"` and `pip show tensorflow` inside the actual deployed runtime image or virtual environment, not only in source repositories. Rebuild containers and rerun dependency scans after remediation. For ML pipelines, confirm that model and checkpoint ingestion paths enforce artifact provenance, signature or digest verification, and access controls. Where feasible, test that tampered artifacts are rejected by the surrounding pipeline controls even if TensorFlow internals are not directly observable.

Typical attack path

1. Identify a TensorFlow-based application, ML pipeline, or analysis workflow running an affected tensorflow PyPI version.
2. Find an ingestion path where TensorFlow artifacts, models, checkpoints, or serialized data can be supplied or modified.
3. Craft or tamper with an artifact so its integrity check value should fail validation but is accepted by the vulnerable code path.
4. Deliver the artifact through a model registry, object store, shared filesystem, upload feature, CI/CD process, or third-party artifact source.
5. Wait for the vulnerable TensorFlow runtime to load or process the artifact.
6. Cause corrupted model behavior, unreliable outputs, processing errors, or service disruption depending on how the artifact is used.

How to detect it

There are no specific public exploitation indicators in the provided data. To assess whether this was already exploited, review logs and artifacts around TensorFlow model, checkpoint, and data ingestion. Focus on model registry audit logs, object storage access logs, CI/CD artifact publication logs, notebook execution history, container build logs, application logs from TensorFlow-serving or TensorFlow-based workloads, and filesystem metadata for model directories. Look for unexpected artifact replacements, uploads by unusual users or service accounts, digest changes without corresponding change records, model rollbacks or hotfixes, repeated TensorFlow load or deserialization errors, abnormal inference drift after an artifact update, and TensorFlow jobs that began failing immediately after a model or checkpoint change. Compare current model and checkpoint hashes against known-good build records or registry digests. If untrusted artifacts were processed while a vulnerable version was deployed, treat the affected artifacts and derived outputs as suspect until revalidated.

What your security team should do

• Prioritize identifying all deployed Python environments, containers, notebooks, and ML platforms using tensorflow versions older than 2.5.3.
• Upgrade tensorflow to 2.5.3 or later and rebuild all dependent runtime images and lockfiles.
• Review model, checkpoint, and TensorFlow artifact supply chains for unsigned, unauthenticated, or externally writable sources.
• Require signed or digest-pinned ML artifacts in model registries and CI/CD pipelines.
• Restrict who can publish or replace TensorFlow artifacts consumed by production or decision-support systems.
• Add dependency scanning and SBOM checks for TensorFlow to CI/CD and container registry workflows.
• Monitor for unusual model artifact changes, unexpected inference drift, repeated TensorFlow processing failures, and unplanned model replacements.
• If vulnerable versions processed untrusted artifacts, review the integrity and provenance of those artifacts before trusting downstream outputs.