Popular deep learning framework, PyTorch Lightning, has been found to contain multiple critical security flaws.
The deserialisation vulnerabilities, identified under the reference VU#252619, impacts all versions of the framework up to and including version 2.4.0 and could potentially allow attackers to execute arbitrary code by loading untrusted model files.
The discovery of these vulnerabilities was made by Kasimir Schulz from HiddenLayer and the disclosure was coordinated by the CERT Coordination Center (CERT/CC) at Carnegie Mellon University.
PyTorch Lightning, which serves as a high-level interface for PyTorch, streamlines complex tasks such as distributed training and hardware scaling. Its widespread adoption is evident: the framework has been cited in thousands of research papers, integrated into enterprise machine learning (ML) pipelines, and downloaded over 200 million times as of March 2025—amplifying the potential impacts.
Deserialisation functions like torch.load() and Python’s pickle module lack inherent safeguards, allowing attackers to embed malicious code in model files (e.g., .ckpt or .pt formats). When loaded by automated workflows – such as training pipelines or inference services – these files could trigger unauthorised code execution, leading to system compromise, data theft, or lateral network movement.
CERT/CC identified insecure deserialisation mechanisms across several subsystems:
- Distributed checkpointing: The _load_distributed_checkpoint function processes unverified serialised data across cluster nodes.
- Cloud_IO module: Retrieves models from local files, remote URLs, or in-memory streams without content validation.
- Lazy loading routines: The _lazy_load method defers execution without verifying deferred code.
- DeepSpeed integration: Exposes additional attack surfaces through deserialisation of optimiser and model states.
- PickleSerializer: Directly wraps Python’s pickle module, offering no sandboxing or validation.
Until a patch is released, CERT/CC advises organisations to:
- Enforce strict trust boundaries: Avoid loading models from untrusted or unauthenticated sources.
- Use restricted deserialisation: Employ torch.load(weights_only=True) to restrict loading to tensor data only.
- Isolate untrusted workloads: Process external files in sandboxed environments, such as containers with limited privileges.
- Inspect files pre-loading: Use tools like pickletools to analyse serialised content for suspicious patterns.
- Audit automation pipelines: Ensure CI/CD systems and model registries do not deserialise user-provided data without safeguards.
The vulnerabilities found in PyTorch Lightning underscore longstanding concerns about the security of ML toolchains. Deserialisation risks in PyTorch and related frameworks have been documented for years, yet many tools continue to prioritise convenience over safety.
These flaws are a stark reminder that ML workflows are increasingly attractive targets for attackers. Organisations must treat model files with the same caution as executable code, particularly in shared or production environments.
(Photo by Johannes Plenio)
See also: Stack Overflow: Developers strongly prefer open-source AI
Want to learn more about cybersecurity and the cloud from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is co-located with other leading events including Digital Transformation Week, IoT Tech Expo, Blockchain Expo, and AI & Big Data Expo.
Explore other upcoming enterprise technology events and webinars powered by TechForge here.
