CVE-2026-90777: ESPnet: RCE via unsafe checkpoint deserialization
HIGHESPnet, the widely used speech-processing toolkit, loads pretrained model checkpoints with torch.load(weights_only=False), which deserializes arbitrary Python pickle objects and lets a malicious checkpoint execute code the moment someone loads it for inference or fine-tuning. CVSS 8.8 reflects full compromise of confidentiality, integrity, and availability, and the attack requires only that a user be convinced to load an attacker-supplied checkpoint file — no authentication or special access needed, though EPSS data isn't yet available and this CVE is not in CISA KEV or paired with a public exploit or Nuclei template, so there's no evidence of active mass exploitation today. The real exposure is supply-chain: any team pulling pretrained speech models from model hubs, forums, or third-party sources for fine-tuning is at risk, and this is the same class of attack that has repeatedly compromised ML pipelines via poisoned pickle files. Patch to the v.202609 release or later, which fixes the vulnerable path in espnet2/torch_utils/load_pretrained_model.py, and in the meantime restrict checkpoint loading to trusted, hash-verified sources, run model-loading code in a sandboxed/least-privilege environment, and scan third-party checkpoints with a pickle-safety tool (e.g., picklescan or fickling) before use.
What is the risk?
High severity (CVSS 8.8) driven by full C/I/A impact and network attack vector, tempered by the requirement for user interaction (a victim must actively load the malicious checkpoint) and low current exploitation signal — no EPSS score published, not in CISA KEV, and no public exploit code or scanner template identified. This is a classic and well-understood deserialization pattern (CWE-502, torch.load with weights_only=False), so the barrier to weaponization is low for anyone with basic Python/pickle knowledge, meaning real-world risk is likely to rise quickly once a working PoC circulates, especially given ESPnet's use in research and production speech pipelines.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| espnet | — | — | No patch |
Do you use espnet? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade ESPnet to v.202609 or later, which patches load_pretrained_model.py to avoid unsafe deserialization. 2) If upgrading isn't immediately possible, never load checkpoints from untrusted or unverified sources; enforce a checksum/signature allowlist for internal model artifacts. 3) Run any checkpoint-loading step (training init, fine-tuning, inference bootstrap) inside a sandboxed, network-restricted, least-privilege container. 4) Scan incoming checkpoint files with a pickle-safety tool such as picklescan or fickling before they touch torch.load. 5) For detection, monitor for unexpected child processes or outbound connections spawned immediately after model-loading calls in ESPnet-based services.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-90777?
ESPnet, the widely used speech-processing toolkit, loads pretrained model checkpoints with torch.load(weights_only=False), which deserializes arbitrary Python pickle objects and lets a malicious checkpoint execute code the moment someone loads it for inference or fine-tuning. CVSS 8.8 reflects full compromise of confidentiality, integrity, and availability, and the attack requires only that a user be convinced to load an attacker-supplied checkpoint file — no authentication or special access needed, though EPSS data isn't yet available and this CVE is not in CISA KEV or paired with a public exploit or Nuclei template, so there's no evidence of active mass exploitation today. The real exposure is supply-chain: any team pulling pretrained speech models from model hubs, forums, or third-party sources for fine-tuning is at risk, and this is the same class of attack that has repeatedly compromised ML pipelines via poisoned pickle files. Patch to the v.202609 release or later, which fixes the vulnerable path in espnet2/torch_utils/load_pretrained_model.py, and in the meantime restrict checkpoint loading to trusted, hash-verified sources, run model-loading code in a sandboxed/least-privilege environment, and scan third-party checkpoints with a pickle-safety tool (e.g., picklescan or fickling) before use.
Is CVE-2026-90777 actively exploited?
No confirmed active exploitation of CVE-2026-90777 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-90777?
1) Upgrade ESPnet to v.202609 or later, which patches load_pretrained_model.py to avoid unsafe deserialization. 2) If upgrading isn't immediately possible, never load checkpoints from untrusted or unverified sources; enforce a checksum/signature allowlist for internal model artifacts. 3) Run any checkpoint-loading step (training init, fine-tuning, inference bootstrap) inside a sandboxed, network-restricted, least-privilege container. 4) Scan incoming checkpoint files with a pickle-safety tool such as picklescan or fickling before they touch torch.load. 5) For detection, monitor for unexpected child processes or outbound connections spawned immediately after model-loading calls in ESPnet-based services.
What systems are affected by CVE-2026-90777?
This vulnerability affects the following AI/ML architecture patterns: training pipelines, model serving, fine-tuning workflows.
What is the CVSS score for CVE-2026-90777?
CVE-2026-90777 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.51%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003 Model AML.T0011.000 Unsafe AI Artifacts AML.T0018.002 Embed Malware Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An adversary crafts a malicious ESPnet checkpoint file embedding a pickle payload that executes arbitrary code on deserialization, then publishes it as a 'high-performing' pretrained ASR or TTS model on a public model hub, forum, or via a phishing email targeting a research team. A victim engineer downloads the checkpoint and loads it into ESPnet for fine-tuning or inference — the moment torch.load(weights_only=False) deserializes the file, the embedded payload executes with the privileges of the training/inference process, giving the attacker a foothold on the GPU training host, access to any co-located datasets or credentials, and a base for lateral movement.
Weaknesses (CWE)
CWE-502 — Deserialization of Untrusted Data: The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
- [Architecture and Design, Implementation] If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- [Implementation] When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H References
- github.com/espnet/espnet product
- github.com/espnet/espnet/blob/v.202511/espnet2/torch_utils/load_pretrained_model.py technical-description
- github.com/espnet/espnet/commit/91ca045fc179f29bc7b7fe05cd852aea65310003 patch
- github.com/espnet/espnet/releases/tag/v.202609 release-notes
- github.com/espnet/espnet/security/advisories/GHSA-64f6-3gqc-r926 vendor-advisory
- vulncheck.com/advisories/espnet-before-202609-remote-code-execution-via-unsafe-deserialization third-party-advisory
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply Chain CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply Chain CVE-2023-3765 10.0 MLflow: path traversal allows arbitrary file read
Same attack type: Supply Chain CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply Chain CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution