CVE-2026-90777 in ESPnet
Summary
by MITRE • 09/13/2026
ESPnet before 202609 deserializes pretrained model checkpoints using torch.load with weights_only=False, allowing arbitrary code execution from attacker-supplied files. Attackers can craft malicious checkpoint files that execute code during deserialization when loaded through the initialization or fine-tuning path.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in ESPnet prior to version 202609 stems from an insecure implementation of model serialization and deserialization mechanisms, specifically within the PyTorch-based loading routines used for pretrained model checkpoints. The core technical flaw lies in the invocation of torch.load with the weights_only parameter explicitly set to False or left at its default unsafe state during critical initialization and fine-tuning workflows. In Python environments utilizing PyTorch, the pickle module is employed by default under these conditions to deserialize checkpoint files. This deserialization process allows for arbitrary object instantiation and method execution upon loading, which creates a severe security risk when processing untrusted input data. Attackers can exploit this behavior by crafting malicious checkpoint files that contain serialized payloads designed to execute system commands or perform other harmful actions the moment they are loaded into memory via ESPnet's standard model initialization procedures.
This vulnerability is classified under CWE-502, which denotes Deserialization of Untrusted Data, a category of flaws where an application deserializes untrusted data without sufficiently verifying that the resulting data will be valid. The operational impact of this flaw is significant, as it grants remote attackers the ability to achieve arbitrary code execution on systems running vulnerable versions of ESPnet. Since model checkpoints are often shared across research communities and downloaded from public repositories or third-party sources, an attacker can distribute a poisoned checkpoint file that appears legitimate but contains embedded malicious logic. When a user attempts to load this compromised model for training, evaluation, or inference purposes, the underlying deserialization routine will execute the payload before any actual machine learning operations begin, effectively compromising the host system's integrity and confidentiality.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1059, specifically sub-technique 008 which covers Command and Scripting Interpreter execution via Python scripts. The attack vector relies on social engineering or supply chain compromise to introduce the malicious checkpoint file into the victim's environment. Once executed, the payload can establish persistence, exfiltrate sensitive data, or pivot further within the network depending on the privileges of the user running ESPnet. This is particularly dangerous in research and development environments where users may operate with elevated permissions to facilitate model training processes involving large datasets and computational resources.
Mitigation strategies must focus on restricting the deserialization process to prevent arbitrary code execution. The primary remediation involves upgrading to version 202609 or later, where this issue has been addressed by enforcing stricter serialization protocols. For environments that cannot immediately upgrade, it is critical to modify application code to ensure that torch.load always utilizes weights_only=True when loading model checkpoints. This parameter restricts the deserialization process to only load tensor data and basic Python objects, thereby neutralizing the ability of malicious payloads embedded in custom classes or functions within the pickle stream to execute arbitrary commands. Additionally, organizations should implement strict validation policies for all incoming model files, treating them as untrusted input similar to any other external file source. Implementing sandboxed environments for loading third-party models can also provide an additional layer of defense by isolating potential execution contexts from the main system infrastructure.