CVE-2025-55551: pytorch · Uncontrolled Resource Consumption
Source CVE Database V5
Not known to be exploited · CVSS 7.5 High.
Data as of 26 Oct 2026, 17:16 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 36% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 25 Sep 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
Given the lack of an official patch at the time of disclosure, European organizations should implement several practical mitigations: 1) Restrict exposure of PyTorch-based services to untrusted networks and inputs by enforcing strict network segmentation and input validation to minimize attack surface. 2) Monitor resource utilization closely on systems running PyTorch 2.8.0, setting thresholds and alerts for abnormal CPU, memory, or process usage that could indicate exploitation attempts. 3) Employ runtime application self-protection (RASP) or behavior-based anomaly detection tools to identify and block suspicious slice operations or resource-intensive calls within the torch.linalg.lu component. 4) Where feasible, isolate AI workloads in containerized or virtualized environments with resource limits (CPU, memory) to contain potential DoS effects. 5) Engage with PyTorch maintainers and community for updates or patches and plan for timely upgrades once fixes are available. 6) Conduct internal code reviews and testing to identify if custom code or third-party libraries invoke vulnerable slice operations and refactor or sandbox these calls. These targeted mitigations go beyond generic advice by focusing on operational controls and monitoring tailored to the nature of this vulnerability.
Description
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.