CVE-2025-3730

What it actually does

The flaw is a local denial-of-service condition in PyTorch 2.6.0 affecting torch.nn.functional.ctc_loss, implemented in aten/src/ATen/native/LossCTC.cpp. By supplying malformed or adversarial inputs to the CTC loss calculation, a local user or code path that can execute PyTorch workloads may trigger abnormal resource consumption, assertion failure, process crash, or other interruption of the Python/native runtime. The impact is availability-focused; the available information does not indicate remote code execution, privilege escalation, data theft, or authentication bypass.

Why it matters to the business

Systems that run PyTorch-based machine learning jobs can experience failed training or inference tasks, interrupted pipelines, degraded service availability, and wasted compute capacity if untrusted or poorly validated inputs reach the vulnerable CTC loss function. The risk is reduced by the local attack requirement, low CVSS score of 3.3, low EPSS score of 0.00307, and absence from the CISA KEV catalog, but public disclosure means organizations running exposed multi-user notebooks, shared ML platforms, or automated model-processing services should still patch during normal maintenance. The supplied package list also includes Red Hat JBoss EAP 7.1 EUS packages with fixed versions; those should be treated as vendor remediation metadata and verified against the actual deployed product inventory because they do not align directly with the PyTorch component named in the vulnerability description.

How an attack unfolds

An attacker first needs a way to run local code or submit data that is processed by a vulnerable PyTorch 2.6.0 environment. In a common scenario, this could be a shared machine learning workstation, notebook service, CI job, model-training pipeline, or application feature that computes CTC loss over attacker-controlled tensors. The attacker crafts tensor shapes, lengths, labels, or related parameters that exercise the vulnerable path in torch.nn.functional.ctc_loss. When the workload reaches the native CTC loss implementation in LossCTC.cpp, the process may crash or become unavailable, causing the current job or service worker to fail. Because exploitation is local and availability-only based on the available description, the attacker generally cannot use this flaw alone to take control of the host, but they may be able to repeatedly disrupt workloads if they can resubmit jobs or inputs.

How to fix it

Upgrade PyTorch from version 2.6.0 to a vendor-fixed release or apply the upstream patch identified as commit 46fc5d8e360127361211cb237d5f9eef0223e567 if maintaining a custom build. Where immediate patching is not possible, restrict who can submit PyTorch workloads, isolate ML jobs in containers or separate worker processes, enforce CPU/GPU and memory quotas, validate tensor dimensions and sequence lengths before calling torch.nn.functional.ctc_loss, and prevent untrusted users from executing arbitrary local code in shared ML environments. For the Red Hat JBoss EAP 7.1 EUS packages listed in the input, apply the corresponding vendor-fixed package versions where those packages are present: eap7-jackson-databind 0:2.8.11.6-1.SP1_redhat_00001.1.ep7.el7; eap7-wildfly and eap7-wildfly-modules 0:7.1.8-2.GA_redhat_00002.1.ep7.el7; eap7-apache-cxf, eap7-apache-cxf-rt, eap7-apache-cxf-services, and eap7-apache-cxf-tools 0:3.1.16-3.SP1_redhat_00001.1.ep7.el7; eap7-avro 0:1.7.6-2.redhat_00003.1.ep7.el7; eap7-bouncycastle, eap7-bouncycastle-mail, eap7-bouncycastle-pkix, and eap7-bouncycastle-prov 0:1.68.0-1.redhat_00005.1.ep7.el7; eap7-h2database 0:1.4.197-2.redhat_00005.1.ep7.el7; eap7-jboss-marshalling and eap7-jboss-marshalling-river 0:2.0.15-1.Final_redhat_00001.1.ep7.el7; eap7-jboss-xnio-base 0:3.5.10-1.Final_redhat_00001.1.ep7.el7; and eap7-xalan-j2 0:2.7.1-26.redhat_00015.1.ep7.el7. Validate the applicability of the Red Hat fixes separately from the PyTorch remediation because the affected-product metadata appears inconsistent with the vulnerability description.

How to confirm the fix worked

Confirm whether PyTorch 2.6.0 is installed by checking package inventories, container images, virtual environments, conda environments, requirements files, lockfiles, and runtime package metadata such as python -c "import torch; print(torch.__version__)". Verify that affected environments are upgraded beyond the vulnerable release or include the upstream patch 46fc5d8e360127361211cb237d5f9eef0223e567. For Red Hat package remediation, use package-manager queries such as rpm -q against the listed eap7-* packages and confirm installed versions are equal to or newer than the fixed versions supplied by the vendor. After patching, run regression tests or representative workloads that invoke torch.nn.functional.ctc_loss and confirm they complete without crashes under expected valid input ranges. Also confirm operational controls are in place for shared ML platforms, including workload isolation, resource quotas, and restrictions on untrusted local job execution.

Typical attack path

1. Identify a system, notebook, job runner, or application using PyTorch 2.6.0.
2. Gain local execution capability or access to a workflow that accepts attacker-controlled ML inputs.
3. Submit crafted inputs that cause execution of torch.nn.functional.ctc_loss.
4. Trigger the vulnerable native CTC loss code path in aten/src/ATen/native/LossCTC.cpp.
5. Cause the Python process, worker, training job, or inference task to crash or become unavailable.
6. Repeat submissions to sustain denial of service if rate limits, job isolation, or input validation are absent.

How to detect it

Because this is a local denial-of-service issue, investigation should focus on evidence of repeated crashes or failed ML workloads rather than network intrusion indicators. Review application logs, ML job scheduler logs, notebook server activity, CI runner logs, container stdout/stderr, systemd/journald entries, kernel OOM logs, Python tracebacks, and crash dumps for failures involving torch.nn.functional.ctc_loss, ctc_loss, or LossCTC.cpp. Correlate crash times with local user activity, job submissions, notebook execution history, source-control changes, uploaded datasets, and unusual tensor-processing workloads. Look for repeated failures from the same user, project, container image, notebook, or job template. On Linux hosts, examine core dumps and process termination records for python, python3, torchrun, Jupyter kernels, training workers, or inference workers that terminated unexpectedly while running PyTorch 2.6.0. There are no known public threat actors, KEV listing, ransomware use, or reliable network IOCs provided for this vulnerability, so detection should be behavior- and artifact-based.

• torch.nn.functional.ctc_loss
• ctc_loss
• LossCTC.cpp
• aten/src/ATen/native/LossCTC.cpp
• python: segmentation fault
• python3: segmentation fault
• torchrun
• RuntimeError
• Aborted (core dumped)
• Segmentation fault (core dumped)
• Out of memory: Killed process
• Killed process python
• Killed process python3

What your security team should do

• Prioritize inventory first: identify PyTorch 2.6.0 installations across workstations, notebooks, CI/CD runners, training clusters, inference services, and container images.
• Patch PyTorch environments to a fixed release or apply upstream patch 46fc5d8e360127361211cb237d5f9eef0223e567 during the next normal maintenance window, with faster action for shared or multi-user ML infrastructure.
• Where the listed Red Hat EAP 7.1 EUS packages are installed, apply the vendor-fixed package versions and separately confirm whether they are actually relevant to the deployed vulnerable component.
• Restrict untrusted local code execution and untrusted ML job submission on systems where patching is delayed.
• Add resource limits, worker process isolation, and automatic job restart controls to reduce the operational impact of crashes.
• Review logs and job history for unexplained PyTorch worker crashes, repeated failed CTC loss workloads, or suspicious submissions from local users around the publication date and afterward.
• Treat this as an availability issue rather than a data-breach indicator unless other evidence shows unauthorized access or lateral movement.