Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
24 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A vulnerability in PyTorch's `weights_only` unpickler allows an attacker to craft a malicious checkpoint file (`.pth`) that, when loaded with `torch.load(..., weights_only=True)`, can corrupt memory and potentially lead to arbitrary code execution. Vulnerability Details The `weights_only=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
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in pytorch v2.7.0 can lead to a Denial of Service (DoS) when a PyTorch model consists of torch.Tensor.to_sparse() and torch.Tensor.to_dense() and is compiled by Inductor.
Recommended action: Upgrade to 2.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A buffer overflow occurs in pytorch v2.7.0 when a PyTorch model consists of torch.nn.Conv2d, torch.nn.functional.hardshrink, and torch.Tensor.view-torch.mv() and is compiled by Inductor, leading to a Denial of Service (DoS).
Recommended action: Upgrade to 2.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Name Error occurs in pytorch v2.7.0 when a PyTorch model consists of torch.cummin and is compiled by Inductor, leading to a Denial of Service (DoS).
Recommended action: Upgrade to 2.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pytorch v2.8.0 was discovered to contain an integer overflow in the component torch.nan_to_num-.long().
Recommended action: Upgrade to 2.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A syntax error in the component proxy_tensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS).
Recommended action: Upgrade to 2.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randn_like are used together.
Recommended action: Upgrade to 2.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PyTorch before 3.7.0 has a bernoulli_p decompose function in decompositions.py even though it lacks full consistency with the eager CPU implementation, negatively affecting nn.Dropout1d, nn.Dropout2d, and nn.Dropout3d for fallback_random=True.
Recommended action: Upgrade to 2.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch before 2.7.0, bitwise_right_shift produces incorrect output for certain out-of-bounds values of the "other" argument.
Recommended action: Upgrade to 2.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch before 2.7.0, when torch.compile is used, FractionalMaxPool2d has inconsistent results.
Recommended action: Upgrade to 2.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch before 2.7.0, when inductor is used, nn.Fold has an assertion error.
Recommended action: Upgrade to 2.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch through 2.6.0, when eager is used, nn.PairwiseDistance(p=2) produces incorrect results.
Recommended action: Upgrade to 2.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. 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.
Recommended action: Upgrade to 2.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. A patch is available through commit 999d94b.
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability classified as critical has been found in PyTorch 2.6.0. This affects the function torch.jit.script. The manipulation leads to memory corruption. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.
Recommended action: Upgrade to 2.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 patch is available through commit 4945180.
Recommended action: Upgrade to 2.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.7.1rc1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch <=2.4.1, the RemoteModule has Deserialization RCE. NOTE: this is disputed by multiple parties because this is intended behavior in PyTorch distributed computing.
Recommended action: Upgrade to 2.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Pytorch before v2.2.0 has an Out-of-bounds Read vulnerability via the component torch/csrc/jit/mobile/flatbuffer_loader.cpp.
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Pytorch before version v2.2.0 was discovered to contain a use-after-free vulnerability in torch/csrc/jit/mobile/interpreter.cpp.
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In PyTorch before trunk/89695, torch.jit.annotations.parsetypeline can cause arbitrary code execution because eval is used unsafely. The fix for this issue is available in version 1.13.1. There is a release checker in issue #89855.
Recommended action: Upgrade to 1.13.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.