A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnnmaxpool2d. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used.
Description I found a Remote Command Execution (RCE) vulnerability in PyTorch. When loading model using torch.load with weightsonly=True, it can still achieve RCE.
Background knowledge https://github.com/pytorch/pytorch/security As you can see, the PyTorch official documentation considers using torch.load() with weightsonly=True to be safe. !image Since everyone knows that weightsonly=False is unsafe, so they will use the weightsonly=True to mitigate the seucirty issue. But now, I just proved that even if you use weightsonly=True, it can still achieve RCE.
Credit This vulnerability was found by Ji'an Zhou.
A vulnerability, which was classified as problematic, was found in PyTorch 2.6.0. Affected is the function torch.nn.functional.ctcloss of the file aten/src/ATen/native/LossCTC.cpp. The manipulation leads to denial of service. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The name of the patch is 46fc5d8e360127361211cb237d5f9eef0223e567. It is recommended to apply a patch to fix this issue.
Pytorch before v2.2.0 has an Out-of-bounds Read vulnerability via the component torch/csrc/jit/mobile/flatbufferloader.cpp.
Pytorch before version v2.2.0 was discovered to contain a use-after-free vulnerability in torch/csrc/jit/mobile/interpreter.cpp.
PyTorch before v2.2.0 was discovered to contain a heap buffer overflow vulnerability in the component /runtime/varargfunctions.cpp. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.
Summary
A vulnerability in PyTorch's weightsonly unpickler allows an attacker to craft a malicious checkpoint file (.pth) that, when loaded with torch.load(..., weightsonly=True), can corrupt memory and potentially lead to arbitrary code execution.
Vulnerability Details
The weightsonly=True unpickler failed to properly validate pickle opcodes and storage metadata, allowing:
1. Heap memory corruption via SETITEM/SETITEMS opcodes applied to non-dictionary types 2. Storage size mismatch between declared element count and actual data in the archive
Impact
An attacker who can convince a user to load a malicious checkpoint file may achieve arbitrary code execution in the context of the victim's process.
Credit Ji'an Zhou
An issue was discovered in PyTorch v2.5 and v2.7.1. Omission of profiler.stop() can cause torch.profiler.profile (PythonTracer) to crash or hang during finalization, leading to a Denial of Service (DoS).
pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randnlike are used together.
A vulnerability was identified in PyTorch 2.10.0. The affected element is an unknown function of the component pt2 Loading Handler. The manipulation leads to deserialization. The attack can only be performed from a local environment. The exploit is publicly available and might be used. The project was informed of the problem early through a pull request but has not reacted yet.
A vulnerability was found in PyTorch 2.6.0+cu124. It has been declared as critical. Affected by this vulnerability is the function torch.ops.profiler.callendcallbacksonjitfut of the component Tuple Handler. The manipulation of the argument None leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult.
A vulnerability was found in PyTorch 2.6.0+cu124. It has been rated as problematic. Affected by this issue is the function nnqSigmoid of the component Quantized Sigmoid Module. The manipulation of the argument scale/zeropoint leads to improper initialization. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used.
In PyTorch before trunk/89695, torch.jit.annotations.parsetypeline can cause arbitrary code execution because eval is used unsafely.
A vulnerability was found in PyTorch 2.6.0. It has been declared as critical. Affected by this vulnerability is the function torch.nn.utils.rnn.padpackedsequence. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.
A vulnerability was found in PyTorch 2.6.0. It has been rated as critical. Affected by this issue is the function torch.nn.utils.rnn.unpacksequence. The manipulation leads to memory corruption. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
A vulnerability classified as critical was found in PyTorch 2.6.0. This vulnerability affects the function torch.lstmcell. The manipulation leads to memory corruption. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used.
pytorch v2.8.0 was discovered to contain an integer overflow in the component torch.nantonum-.long().
An issue in the component torch.linalg.lu of pytorch v2.8.0 allows attackers to cause a Denial of Service (DoS) when performing a slice operation.
An issue in pytorch v2.7.0 can lead to a Denial of Service (DoS) when a PyTorch model consists of torch.Tensor.tosparse() and torch.Tensor.todense() and is compiled by Inductor.
In PyTorch before 2.7.0, bitwiserightshift produces incorrect output for certain out-of-bounds values of the "other" argument.