Skip to content

Update dependency torch [SECURITY]#52

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-torch-vulnerability
Open

Update dependency torch [SECURITY]#52
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-torch-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 7, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
torch ==2.8.0+cu126 → ==2.13.0+cu126 age adoption passing confidence
torch ==2.6.0 → ==2.13.0 age adoption passing confidence
torch ==2.5.1 → ==2.13.0 age adoption passing confidence
torch ==2.8.0 → ==2.13.0 age adoption passing confidence

BIT-pytorch-2025-55551 / CVE-2025-55551 / PYSEC-2025-203

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55552 / CVE-2025-55552 / PYSEC-2025-204

More information

Details

pytorch v2.8.0 was discovered to display unexpected behavior when the components torch.rot90 and torch.randn_like are used together.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55554 / CVE-2025-55554 / PYSEC-2025-206

More information

Details

pytorch v2.8.0 was discovered to contain an integer overflow in the component torch.nan_to_num-.long().

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

PyTorch is vulnerable to memory corruption through its unpack_sequence function

BIT-pytorch-2025-2999 / CVE-2025-2999 / GHSA-vgrw-7cvw-pwgx / PYSEC-2025-193

More information

Details

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.unpack_sequence. 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.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

PyTorch is vulnerable to memory corruption through its torch.lstm_cell function

BIT-pytorch-2025-3001 / CVE-2025-3001 / GHSA-qfhq-4f3w-5fph / PYSEC-2025-195

More information

Details

A vulnerability classified as critical was found in PyTorch 2.6.0. This vulnerability affects the function torch.lstm_cell. 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.

Severity

  • CVSS Score: 1.9 / 10 (Low)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

BIT-pytorch-2026-4538 / CVE-2026-4538 / PYSEC-2026-139

More information

Details

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.

Severity

  • CVSS Score: 7.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2026-24747 / CVE-2026-24747 / GHSA-63cw-57p8-fm3p / PYSEC-2026-1856 / PYSEC-2026-2286

More information

Details

PyTorch is a Python package that provides tensor computation. Prior to version 2.10.0, 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. Version 2.10.0 fixes the issue.

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

PyTorch is vulnerable to memory corruption through its torch.jit.script function

BIT-pytorch-2025-3000 / CVE-2025-3000 / GHSA-rrmf-rvhw-rf47 / PYSEC-2025-194

More information

Details

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.

Severity

  • CVSS Score: 1.9 / 10 (Low)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

PyTorch Tuple Handler is Vulnerable to Memory Corruption through Manipulation of None Argument

BIT-pytorch-2025-2148 / CVE-2025-2148 / GHSA-c678-jfcj-6jmf / PYSEC-2025-189

More information

Details

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._call_end_callbacks_on_jit_fut 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.

Severity

  • CVSS Score: 2.3 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

PyTorch is Vulnerable to Memory Consumption through pad_packed_sequence Function

BIT-pytorch-2025-2998 / CVE-2025-2998 / GHSA-f4hp-rmr7-r7v8 / PYSEC-2025-192

More information

Details

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.pad_packed_sequence. 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.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

PyTorch: Manipulation of the argument scale/zero_point leads to improper initialization via Quantized Sigmoid Module

BIT-pytorch-2025-2149 / CVE-2025-2149 / GHSA-x3gm-94wq-g975 / PYSEC-2025-190

More information

Details

A vulnerability was found in PyTorch 2.6.0+cu124. It has been rated as problematic. Affected by this issue is the function nnq_Sigmoid of the component Quantized Sigmoid Module. The manipulation of the argument scale/zero_point 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.

Severity

  • CVSS Score: 2.0 / 10 (Low)
  • Vector String: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-2953 / CVE-2025-2953 / GHSA-3749-ghw9-m3mg / PYSEC-2025-191

More information

Details

A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnn_max_pool2d. 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 real existence of this vulnerability is still doubted at the moment. The security policy of the project warns to use unknown models which might establish malicious effects.

Severity

  • CVSS Score: 5.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-46148 / CVE-2025-46148 / PYSEC-2025-198

More information

Details

In PyTorch through 2.6.0, when eager is used, nn.PairwiseDistance(p=2) produces incorrect results.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-46149 / CVE-2025-46149 / PYSEC-2025-199

More information

Details

In PyTorch before 2.7.0, when inductor is used, nn.Fold has an assertion error.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-46150 / CVE-2025-46150 / PYSEC-2025-200

More information

Details

In PyTorch before 2.7.0, when torch.compile is used, FractionalMaxPool2d has inconsistent results.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-46152 / CVE-2025-46152 / PYSEC-2025-201

More information

Details

In PyTorch before 2.7.0, bitwise_right_shift produces incorrect output for certain out-of-bounds values of the "other" argument.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-46153 / CVE-2025-46153 / PYSEC-2025-202

More information

Details

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.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

PyTorch susceptible to local Denial of Service

BIT-pytorch-2025-2953 / CVE-2025-2953 / GHSA-3749-ghw9-m3mg / PYSEC-2025-191

More information

Details

A vulnerability, which was classified as problematic, has been found in PyTorch 2.6.0+cu124. Affected by this issue is the function torch.mkldnn_max_pool2d. 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.

Severity

  • CVSS Score: 1.9 / 10 (Low)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55553 / CVE-2025-55553 / PYSEC-2025-205

More information

Details

A syntax error in the component proxy_tensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS).

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55557 / CVE-2025-55557 / PYSEC-2025-207

More information

Details

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).

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55558 / CVE-2025-55558 / PYSEC-2025-208

More information

Details

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).

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-55560 / CVE-2025-55560 / PYSEC-2025-209

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

PyTorch Improper Resource Shutdown or Release vulnerability

BIT-pytorch-2025-3730 / CVE-2025-3730 / GHSA-887c-mr87-cxwp / PYSEC-2026-1970

More information

Details

A vulnerability, which was classified as problematic, was found in PyTorch 2.6.0. Affected is the function torch.nn.functional.ctc_loss 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.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

PyTorch Improper Resource Shutdown or Release vulnerability

BIT-pytorch-2025-3730 / CVE-2025-3730 / GHSA-887c-mr87-cxwp / PYSEC-2026-1970

More information

Details

A vulnerability, which was classified as problematic, was found in PyTorch 2.6.0. Affected is the function torch.nn.functional.ctc_loss 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.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

PyTorch: torch.load with weights_only=True leads to remote code execution

BIT-pytorch-2025-32434 / CVE-2025-32434 / GHSA-53q9-r3pm-6pq6 / PYSEC-2025-41

More information

Details

Description

I found a Remote Command Execution (RCE) vulnerability in PyTorch. When loading model using torch.load with weights_only=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 weights_only=True to be safe.
image
Since everyone knows that weights_only=False is unsafe, so they will use the weights_only=True to mitigate the seucirty issue.
But now, I just proved that even if you use weights_only=True, it can still achieve RCE.

Credit

This vulnerability was found by Ji'an Zhou.

Severity

  • CVSS Score: 9.3 / 10 (Critical)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

BIT-pytorch-2025-32434 / CVE-2025-32434 / GHSA-53q9-r3pm-6pq6 / PYSEC-2025-41

More information

Details

PyTorch is a Python package that provides tensor computation with strong GPU acceleration and deep neural networks built on a tape-based autograd system. In version 2.5.1 and prior, a Remote Command Execution (RCE) vulnerability exists in PyTorch when loading a model using torch.load with weights_only=True. This issue has been patched in version 2.6.0.

Severity

  • CVSS Score: 9.8 / 10 (Critical)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

Release Notes

pytorch/pytorch (torch)

v2.13.0: PyTorch 2.13.0 Release

Compare Source

PyTorch 2.13.0 Release Notes

Highlights

FlexAttention lands on Apple Silicon (MPS), with up to ~12x speedup over SDPA on sparse patterns, and gains a deterministic backward path on CUDA for reproducible gradient computation.
CuTeDSL "Native DSL" backend gives Inductor a second high-performance code path (alongside Triton) for key GPU operations, with faster compilation. [Prototype]
nn.LinearCrossEntropyLoss combines the final prediction and loss computation to cut peak GPU memory by up to 4x for large-vocabulary language model training.
torchcomms, a new communications backend for PyTorch Distributed, improves fault tolerance, scalability, and debuggability for large-cluster training.
FSDP2 now overlaps reduce-scatter and all-gather communications via a dedicated process group (opt-in), increasing distributed training throughput.
Python 3.15 wheel support for PyTorch on Linux via the pytorch repository index, including builds compatible with free-threaded 3.15t.
Broader platform support: ROCm gains AOTriton 0.12b with native HIP CMake, Arm adds Armv9-A torch.compile targeting, and Intel XPU exposes new device telemetry APIs.

For more details about these highlighted features, you can look at the release blogpost. Below are the full release notes for this release.

Tracked Regressions

ROCm wheels break torch.compile on CPU in environments without a GPU

Running a torch==2.13.0+rocm7.2 wheel in an environment where no GPU is available (torch.cuda.is_available() is False) breaks torch.compile on the CPU path: the first compile raises RuntimeError: Can't detect vectorized ISA for CPU (#​189194). This is a regression from torch==2.12.1+rocm7.2, which compiles CPU code fine (detecting e.g. VecAVX2) in the same setup. The 2.13 ROCm wheel appears to rely on something present in the ROCm builder image to detect the CPU vectorized ISA, so it works when run on a ROCm image but fails on a plain CPU-only image.

Workaround: run the +rocm wheel on a ROCm image, or install a standard CPU/CUDA build for GPU-less environments.

Backwards Incompatible Changes

  • Stop building CPython 3.13t (free-threaded) binaries (#​182951)

    Upstream pypa/manylinux removed CPython 3.13t (free-threaded) on 2026-05-07, because 3.13t
    was experimental and has been superseded by the now-non-experimental CPython 3.14t. As a result,
    PyTorch 2.13 no longer ships cp313t wheels (Linux, Triton, and related artifacts). Users on the
    free-threaded interpreter should move to Python 3.14t.

    PyTorch 2.12:

    # cp313t (free-threaded 3.13) wheels were available
python3.13t -m pip install torch

    PyTorch 2.13:

    # Use free-threaded Python 3.14t instead
python3.14t -m pip install torch

  • Bare PyObject is no longer allowed in operator schemas (#​184209)

    Bare PyObject was accidentally accepted in operator schema strings in
    PyTorch 2.12. This was undocumented and is now rejected, since torch.compile
    does not support arbitrary PyObject inputs to custom ops. If
    you parse or register a schema with a bare PyObject argument or return type,
    you will now get a schema parse error.

    PyTorch 2.12:

    >>> from torch._C import parse_schema
>>> parse_schema("foo(PyObject x) -> ()")  # accepted

    PyTorch 2.13:

    >>> from torch._C import parse_schema
>>> parse_schema("foo(PyObject x) -> ()")  # raises a schema parse error

  • Remove Bazel build support (#​180883)

    The Bazel build was never broadly adopted and still depended on the antiquated Bazel 6,
    while the wider ecosystem has since moved to Bazel 9. All Bazel build files and CI jobs have
    been removed. Users building PyTorch with Bazel should migrate to the supported CMake/pip install
    build flow.

    PyTorch 2.12:

    # Build PyTorch with Bazel
bazel build //:torch

    PyTorch 2.13:

    # Bazel build files have been removed; build from source with pip instead
pip install --no-build-isolation -e .

  • Enforce C++20 minimum in header guards (#​178150). In PyTorch 2.13, C++20 is now required to import PyTorch headers.

  • StorageImpl's built-in copy-on-write (COW) materialization is replaced by a pluggable materializer hook (#​179063)

    StorageImpl no longer knows about COW directly. Its internal COW entry points
    StorageImpl::is_cow(), StorageImpl::maybe_materialize_cow(), and the friend
    cow::materialize_cow_storage() have been removed in favor of a single pluggable
    MaterializeFn hook (void(*)(StorageImpl*)) that a backend registers to run once,
    on the first mutable data-pointer access. COW is now just one consumer of this hook
    (c10::impl::cow::materialize_cow), and all COW behavior (lazy clone, refcounted
    shared data, copy-on-write) is unchanged. This also gives accelerator backends and
    eager-mode graph compilers a zero-fast-path-cost place to commit deferred allocations
    or materialize symbolic buffers on first mutation.

    This is a C++-only change. It affects out-of-tree backends/extensions that called the
    removed StorageImpl COW symbols directly; they will fail to compile against 2.13
    with errors such as no member named 'is_cow' in 'c10::StorageImpl'. Migrate to the
    new hook API (set_materializer() / has_materializer() / clear_materializer()).

    PyTorch 2.12:

    // Detect a COW storage and force it to materialize.
if (storage.is_cow()) {
  storage.maybe_materialize_cow();
}

    PyTorch 2.13:

    // Register a one-shot materializer; it runs on the next mutable-data access
// and then clears itself. COW registers c10::impl::cow::materialize_cow this way.
storage.set_materializer(&my_backend_materialize);  // void(StorageImpl*)

// `has_materializer()` replaces `is_cow()` for "is a deferred materialization pending?"
if (storage.has_materializer()) { /* ... */ }

  • Convert shared_ptr<Node> to intrusive_ptr<Node> (#​181139). This changes the signature of Tensor::grad_fn. Accesses to Tensor.grad_fn() should change from std::shared_ptr<Node> to c10::intrusive_ptr<Node>. Similarly, construction of a C++ autograd function should change:

    PyTorch 2.12:

    std::shared_ptr<CustomCppNode> node(new CustomCppNode(), torch::autograd::deleteNode);

    PyTorch 2.13:

    auto node = c10::make_intrusive<CustomCppNode>();

  • The minimum supported NCCL version when building from source is now 2.23 (#​186292)

    PyTorch now requires NCCL >= 2.23 at compile time, and the preprocessor/runtime gates that guarded NCCL features introduced in 2.23 or earlier have been removed. Users who build PyTorch from source against a system NCCL older than 2.23 will hit compile errors against the dropped gates. Upgrade the NCCL installation to >= 2.23 to build. The prebuilt PyTorch wheels already bundle a compatible NCCL, so pip/conda users are unaffected.

  • Remove named tensors (#​173895)

    The named tensor feature (a long-deprecated prototype) has been fully removed to reduce overhead and code bloat. All associated Python and C++ APIs are gone, including Tensor.names, Tensor.rename(), Tensor.refine_names(), Tensor.align_to(), Tensor.align_as(), torch.align_tensors(), the names= keyword on factory functions (e.g. torch.zeros, torch.empty, torch.ones), and the C++ Dimname / DimnameList APIs. Code that previously relied on named dimensions must track dimension order positionally and avoid usage of any of these now-removed APIs or op overloads.

  • The onednn::qconv2d_pointwise.binary and .binary_tensor operators no longer alias their input but rather return fresh tensors. Previously these ops mutated the qaccum input buffer and returned it directly, violating the PyTorch invariant that custom operator outputs must not alias inputs. This silently bypassed aliasing checks via the old -> Tensor(a!) schema and would become a hard error in a future PyTorch version (as mentioned in #​182063), so the schema and implementation were corrected to return a fresh output. Most users are unaffected, only code that calls these ops directly and relies on the in-place mutation of qaccum must now read the returned tensor instead. (#​177171)

Deprecations

  • Custom operators that return an output aliasing one of their inputs are deprecated (#​182063)

    When a custom operator returns an output that is the same tensor as (or otherwise aliases) one of its inputs under torch.compile, PyTorch now emits a UserWarning stating that this is deprecated and will become an error in a future version of PyTorch. Previously the warning stated the change would land in PyTorch 2.12; that timeline has been pushed back. To update your code, return a clone of the offending output instead of the input, or refactor the operator so it does not return the aliased tensor.

    Deprecated:

    @&#8203;torch.library.custom_op("mylib::foo", mutates_args=())
def foo(x: torch.Tensor) -> torch.Tensor:
    return x  # output aliases the input -- deprecated

    Updated:

    @&#8203;torch.library.custom_op("mylib::foo", mutates_args=())
def foo(x: torch.Tensor) -> torch.Tensor:
    return x.clone()  # return a clone instead

  • Creating tensors with the quantized dtypes quint8, qint8, and qint32 is now deprecated and emits a warning. This covers both Python and C++ call sites; see #​184982 for migration guidance (#​184984)

    PyTorch 2.12:

    >>> x = torch.quantize_per_tensor(torch.randn(3), 0.1, 0, torch.quint8)

    PyTorch 2.13:

    >>> x = torch.quantize_per_tensor(torch.randn(3), 0.1, 0, torch.quint8)
UserWarning: Creating tensors with quantized dtypes (quint8, qint8, qint32) is deprecated

  • Rename distributed collective ops to the _single naming scheme and deprecate the old names (#​186123, #​186124, #​186125, #​186134, #​186135, #​186144)

    To align the public torch.distributed collective APIs with the naming used by torchcomms' TorchCommBackend, all_gather_into_tensor is renamed to all_gather_single and reduce_scatter_tensor to reduce_scatter_single. The previous names continue to work as thin wrappers that delegate to the new functions, but now emit a FutureWarning.

    PyTorch 2.12:

    dist.all_gather_into_tensor(output, input)
dist.reduce_scatter_tensor(output, input)

    PyTorch 2.13:

    dist.all_gather_single(output, input)
dist.reduce_scatter_single(output, input)

New Features

Python Frontend

  • Add two new operator tags, torch.Tag.inplace and torch.Tag.out, that let an operator declare how it writes its result: inplace means it mutates a tensor in place, and out means it writes into a caller-provided output tensor. Native PyTorch operators are tagged automatically, and custom operators defined with torch.library can opt in by adding the tag. To be tagged inplace, an operator must take the tensor it mutates as its first positional argument (declared as Tensor(a!), and the only mutable argument) and return that same tensor. Tagging a custom operator this way improves its behavior under torch.compile: inplace ops now go through auto_functionalize, so the reinplacing pass can analyze clones and skip unnecessary copies, and both inplace and out ops get their fake/meta kernels generated for free. See the [Python custom operators tutorial](https://docs.pytorch.o

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone America/Toronto)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from a team as a code owner August 7, 2025 03:03
@renovate renovate Bot added the renovatebot label Sep 15, 2025
@renovate
renovate Bot force-pushed the renovate/pypi-torch-vulnerability branch from 71e3625 to 44ade71 Compare September 25, 2025 21:25
@renovate
renovate Bot force-pushed the renovate/pypi-torch-vulnerability branch from 44ade71 to 4345a71 Compare December 15, 2025 19:48
@renovate
renovate Bot force-pushed the renovate/pypi-torch-vulnerability branch from 4345a71 to 420fb32 Compare May 21, 2026 20:18
@renovate renovate Bot changed the title Update dependency torch to v2.8.0 [SECURITY] Update dependency torch [SECURITY] May 21, 2026
@renovate

renovate Bot commented May 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: model-servers/vllm/0.11.0/Pipfile.lock
Command failed: pipenv lock
Creating a virtualenv for this project
Pipfile: 
/tmp/renovate/repos/github/redhat-ai-dev/developer-images/model-servers/vllm/0.1
1.0/Pipfile
Using /usr/local/bin/python 3.11.15 to create virtualenv...
created virtual environment CPython3.11.15.final.0-64-x86_64 in 1078ms
  creator CPython3Posix(dest=/runner/cache/others/virtualenvs/0.11.0-aiUPqbIp, 
clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, via=copy, 
app_data_dir=/tmp/containerbase/cache/.cache/virtualenv)
    added seed packages: pip==26.1.2, setuptools==83.0.0
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator
,PythonActivator,XonshActivator

✔ Successfully created virtual environment!
Virtualenv location: /runner/cache/others/virtualenvs/0.11.0-aiUPqbIp
Locking  dependencies...
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Cannot 
install -r /tmp/pipenv-gloqgaum-requirements/pipenv-vi6n__ej-constraints.txt 
(line 30) and torch==2.13.0+cu126 because these package versions have 
conflicting dependencies.
CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:
The conflict is caused by:
    The user requested torch==2.13.0+cu126
    xformers 0.0.32.post1 depends on torch==2.8.0
Additionally, some packages in these conflicts have no matching distributions 
available for your environment:
    torch
To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip to attempt to solve the dependency 
conflict
Your dependencies could not be resolved. You likely have a mismatch in your 
sub-dependencies.
You can use $ pipenv run pip install <requirement_name> to bypass this 
mechanism, then run $ pipenv graph to inspect the versions actually installed in
the virtualenv.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
Hint: try $ pipenv lock --verbose to see the full dependency resolution output.
ERROR: ResolutionImpossible: for help visit 
https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-depende
ncy-conflicts
The conflict is caused by:
    The user requested torch==2.13.0+cu126
    xformers 0.0.32.post1 depends on torch==2.8.0

Hint: Re-run with --verbose to see the full dependency resolution output and 
identify which packages are in conflict.
Traceback (most recent call last):
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/routines/lock.py", line 94, in do_lock
    venv_resolve_deps(
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1467, in venv_resolve_deps
    c = resolve(cmd, st, project=project)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File 
"/opt/containerbase/tools/pipenv/2026.6.2/3.11.15/lib/python3.11/site-packages/p
ipenv/utils/resolver.py", line 1240, in resolve
    raise ResolutionFailure("Failed to lock Pipfile.lock!")
pipenv.exceptions.ResolutionFailure: ERROR: Failed to lock Pipfile.lock!

@renovate renovate Bot changed the title Update dependency torch [SECURITY] Update dependency torch [SECURITY] - autoclosed Jun 14, 2026
@renovate renovate Bot closed this Jun 14, 2026
@renovate
renovate Bot deleted the renovate/pypi-torch-vulnerability branch June 14, 2026 07:23
@renovate renovate Bot changed the title Update dependency torch [SECURITY] - autoclosed Update dependency torch to v2.12.1+cu126 [SECURITY] Jun 17, 2026
@renovate renovate Bot reopened this Jun 17, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-torch-vulnerability branch 3 times, most recently from 7979fad to 3cce415 Compare June 18, 2026 01:40
@renovate renovate Bot changed the title Update dependency torch to v2.12.1+cu126 [SECURITY] Update dependency torch [SECURITY] Jun 18, 2026
@renovate
Update dependency torch [SECURITY]
1228907 
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate
renovate Bot force-pushed the renovate/pypi-torch-vulnerability branch from 3cce415 to 1228907 Compare July 18, 2026 19:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

renovatebot

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants