CVE-2025-32434

What it actually does

A deserialization vulnerability in PyTorch allows for remote code execution when loading a specially crafted model file using the `torch.load` function. The vulnerability exists even when the `weights_only=True` parameter, which is intended to be a security measure to prevent code execution, is specified. An attacker can embed arbitrary code within a model file that will be executed on the machine that loads it, bypassing this safety mechanism.

Why it matters to the business

Successful exploitation results in the complete compromise of the system running the PyTorch application. This could lead to the theft of sensitive data processed by the machine learning model, intellectual property loss, disruption of AI-powered services, and unauthorized access to the broader corporate network. Given PyTorch's widespread use in production AI/ML systems, a compromise could cause significant operational downtime, financial loss, and reputational damage.

How an attack unfolds

An attacker crafts a malicious PyTorch model file (.pt or .pth) containing a serialized payload designed to execute arbitrary commands. The attacker then distributes this file, typically by publishing it to a public model repository like Hugging Face, or by tricking a developer or MLOps pipeline into using it. When a victim's application loads this malicious model using a vulnerable version of PyTorch, the `torch.load` function improperly deserializes the file. The `weights_only=True` safeguard is bypassed, and the attacker's payload is executed with the privileges of the Python process, leading to remote code execution on the victim's server.

How to fix it

Upgrade PyTorch to a version that includes the fix from commit `1eba9b3aa3c43f86f4a2c807ac8e12c4a7767340` or a later stable release. As a critical security best practice, do not load model files from untrusted or unverified sources. Implement a policy where all third-party models are vetted and stored in a trusted internal registry before being used in production.

How to confirm the fix worked

To confirm remediation, verify that the installed PyTorch version in all relevant environments is patched and includes commit `1eba9b3aa3c43f86f4a2c807ac8e12c4a7767340` or newer. To identify potentially exposed systems, scan codebases for the use of `torch.load` and audit the sources of the model files being loaded. You can test for the vulnerability by attempting to load a proof-of-concept model that performs a harmless action (e.g., creating a file in `/tmp/`) with `weights_only=True` to see if the action is executed.

Typical attack path

1. An attacker creates a malicious PyTorch model file with an embedded command execution payload.
2. The attacker uploads the malicious model to a public repository or otherwise tricks a victim into downloading it.
3. A user or automated system loads the malicious model using `torch.load` with `weights_only=True` in a vulnerable application.
4. The vulnerability is triggered, bypassing the security check and executing the attacker's code.
5. The attacker gains control of the host machine, establishing a foothold for further attacks or data exfiltration.

How to detect it

Monitor for Python processes associated with PyTorch applications spawning unexpected child processes, particularly shells (`sh`, `bash`, `cmd.exe`, `powershell.exe`) or network utilities (`curl`, `wget`, `nc`). Analyze EDR and network traffic logs for unusual outbound connections from ML servers to unknown IP addresses, which could indicate a reverse shell. File integrity monitoring may also detect the creation of unexpected scripts or binaries in temporary directories following a model load event.

• parent_process:python AND process:(sh OR bash OR zsh OR cmd.exe OR powershell.exe)
• parent_process:python AND process:(curl OR wget OR nc OR ncat)
• process:python AND outbound_network_connection_to_uncommon_port

What your security team should do

• Immediately patch all systems with vulnerable PyTorch versions, prioritizing those that load models from external sources.
• Enforce a strict policy against loading machine learning models from untrusted public repositories directly into production or development environments.
• Audit all applications and CI/CD pipelines for usage of `torch.load` to identify and assess all potential model ingestion points.
• Enhance monitoring on machine learning infrastructure to detect anomalous process execution, such as Python processes spawning shells or making unexpected outbound network connections.