PyTorch Lightning CVE-2026-31221

Attack requires the victim to execute Python code that calls LightningModule.load_from_checkpoint() on an attacker-controlled checkpoint file. Specific prerequisite: the target application or script must load external checkpoint files rather than only using internally generated checkpoints. The vulnerability affects default PyTorch Lightning installations without code modifications - no non-default configuration required. Limiting factors include: (1) Local attack vector (AV:L) requires the malicious checkpoint file to be present on the victim's filesystem, typically via social engineering, supply chain compromise, or compromised model repositories; (2) User interaction required (UI:R) - the victim must actively execute code to load the checkpoint, it does not auto-execute; (3) No privilege requirements (PR:N) means any user account can be exploited, but execution occurs with the victim's existing privileges, not elevated access. The attack does not work against systems that only load checkpoints from cryptographically verified sources or use custom loading code with weights_only=True.

Real-world risk is moderate and highly context-dependent. The CVSS base score of 7.8 (High) reflects maximum impact (code execution with full system privileges), but the attack vector is Local with Required user interaction, significantly constraining exploitation scenarios. The low EPSS score (0.06%, 19th percentile) suggests minimal observed exploitation attempts in the wild, and absence from CISA KEV confirms no known active exploitation campaigns. However, these traditional risk signals may underestimate threat in machine learning contexts where checkpoint sharing is common practice. Researchers routinely download pre-trained models from GitHub, Hugging Face, academic repositories, and collaborative platforms - often without verification. The ML community's trust-based culture and lack of checkpoint integrity verification creates practical remote attack paths via social engineering or typosquatting. Priority depends heavily on organizational context: high-risk for organizations that download external checkpoints or operate model sharing platforms; low-risk for isolated research environments using only internally generated checkpoints. The vulnerability is not automatable at scale (requires per-victim social engineering), but technical impact is critical (full RCE). SSVC decision tree likely yields 'Scheduled' rather than 'Immediate' priority for most organizations.

An attacker creates a malicious PyTorch Lightning checkpoint file containing a weaponized Pickle payload that executes a reverse shell when deserialized. They publish this checkpoint on GitHub or Hugging Face disguised as a popular pre-trained model (e.g., 'bert-base-optimized.ckpt'). A data scientist researching NLP downloads the checkpoint and loads it using model = MyLightningModule.load_from_checkpoint('bert-base-optimized.ckpt') in their development environment. The torch.load() call deserializes the Pickle payload, executing the attacker's code with the data scientist's privileges, establishing persistence and exfiltrating proprietary training data or source code. No public proof-of-concept exists at time of analysis, but the exploit technique is well-documented in Python security research.