{"vuid":"VU#252619","idnumber":"252619","name":"Multiple deserialization vulnerabilities in PyTorch Lightning 2.4.0 and earlier versions","keywords":null,"overview":"### Overview\r\n[ PyTorch Lightning](https://lightning.ai/docs/pytorch/) versions 2.4.0 and earlier do not use any verification mechanisms to ensure that model files are safe to load before loading them. Users of PyTorch Lightning should use caution when loading models from unknown or unmanaged sources.\r\n\r\n### Description\r\nPyTorch Lightning, a high-level framework built on top of PyTorch, is designed to streamline deep learning model training, scaling, and deployment.  PyTorch Lightning is widely used in AI research and production environments, often integrating with various cloud and distributed computing platforms to manage large-scale machine learning workloads.\r\n\r\nPyTorch Lightning contains multiple vulnerabilities related to the deserialization of untrusted data (CWE-502). These vulnerabilities arise from the unsafe use of `torch.load()`, which is used to deserialize model checkpoints, configurations, and sometimes metadata. While `torch.load()` provides an optional `weights_only=True` parameter to mitigate the risks of loading arbitrary code, PyTorch Lightning does not require or enforce this safeguard as a principal security requirement for the product.\r\n\r\nKasimir Schulz of HiddenLayer identified and reported the following five vulnerabilities:\r\n\r\n1. \tThe `DeepSpeed` integration in PyTorch Lightning loads optimizer states and model checkpoints without enforcing safe deserialization practices. It does not validate the integrity or origin of serialized data before passing it to `torch.load()`, allowing deserialization of arbitrary objects.\r\n2. \tThe `PickleSerializer` class directly utilizes Python’s pickle module to handle data serialization and deserialization. Since pickle inherently allows execution of embedded code during deserialization, any untrusted or manipulated input processed by this class can introduce security risks.\r\n3. \t\tThe `_load_distributed_checkpoint` component is responsible for handling distributed training checkpoints. It processes model state data across multiple nodes, but it does not include safeguards to verify or restrict the content being deserialized.\r\n4. \t\tThe `_lazy_load` function is designed to defer loading of model components for efficiency. However, it does not enforce security controls on the serialized input, allowing for the potential deserialization of unverified objects.\r\n5. \t\tThe `Cloud_IO` module facilitates storage and retrieval of model files from local and remote sources. It provides multiple deserialization pathways, such as handling files from disk, from remote servers, and from in-memory byte streams, without applying constraints on how the serialized data is interpreted.\r\n\r\n### Impact\r\n\r\nA user could unknowingly load a malicious file from local or remote locations containing embedded code that executes within the system’s context, potentially leading to full system compromise.\r\n\r\n### Solution\r\nTo reduce the risk of deserialization-based vulnerabilities in PyTorch Lightning, users and organizations can implement the following mitigations at the system and operational levels:\r\n\r\n1.\tVerify that files to be loaded are from trusted sources and with valid signatures;\r\n2.\tUse Sandbox environments to prevent abuse of arbitrary commands when untrusted models or files are being used or tested;\r\n3.\tPerform static and dynamic analysis of files to be loaded to verify that the ensuing operations will remain restricted to the data processing needs of the environment;\r\n4.\tDisable unnecessary deserialization features by ensuring that `torch.load()` is always used with `weights_only = True` when the files to be loaded are model weights.\r\n\r\nWe have not received a statement from Lightning AI at this time. Please check the Vendor Information section for updates as they become available.\r\n\r\n### Acknowledgements\r\nThanks to the reporter, Kasimir Schulz [kschulz@hiddenlayer.com] from HiddenLayer. Thanks to Matt Churilla for verifying the vulnerabilities. This document was written by Renae Metcalf, Vijay Sarvepalli, and Eric Hatleback.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://lightning.ai/docs/pytorch/stable/","https://www.darkreading.com/cyber-risk/open-source-ai-models-pose-risks-of-malicious-code-vulnerabilities","https://hiddenlayer.com/innovation-hub/models-are-code/","https://www.optiv.com/insights/source-zero/blog/enhancing-your-sdlc-ai-model-vulnerability-scanning"],"cveids":[],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2025-04-03T21:08:09.084097Z","publicdate":"2025-04-03T21:08:08.849378Z","datefirstpublished":"2025-04-03T21:08:09.115413Z","dateupdated":"2025-04-03T21:08:08.849373Z","revision":1,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":118}