CVE-2026-90777: ESPnet: RCE via unsafe checkpoint deserialization

HIGH
Published September 13, 2026
CISO Take

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.

Sources: NVD GitHub Advisory ATLAS VulnCheck

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?

Stage malicious checkpoint
Attacker crafts an ESPnet checkpoint file embedding a pickle payload and publishes it as a legitimate pretrained model.
AML.T0010.003
Victim loads checkpoint
A user or automated pipeline loads the checkpoint via ESPnet's initialization or fine-tuning path using torch.load(weights_only=False).
AML.T0011.000
Code execution
Pickle deserialization triggers the embedded payload, executing arbitrary code with the privileges of the loading process.
AML.T0018.002
Host compromise
The attacker gains a foothold on the training/inference host, exposing data, credentials, and enabling further lateral movement.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
espnet No patch

Do you use espnet? You're affected.

How severe is it?

CVSS 3.1
8.8 / 10
EPSS
0.5%
chance of exploitation in 30 days
Higher than 42% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI Required
S Unchanged
C High
I High
A High

What should I do?

1 step
  1. 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:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.10 - Third-party and supplier relationships
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities

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

training pipelinesmodel servingfine-tuning workflows

MITRE ATLAS Techniques

AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.10
OWASP LLM Top 10: LLM03

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

Timeline

Published
September 13, 2026
Last Modified
September 14, 2026
First Seen
September 13, 2026

Related Vulnerabilities