CVE-2026-79784: Vocos: RCE via unrestricted class loading in model config

HIGH
Published August 25, 2026
CISO Take

Vocos, a neural audio vocoder library, instantiates any Python class named inside a model's config.yaml without restricting which class path is allowed, and calls it with attacker-controlled keyword arguments — so loading a model is equivalent to running arbitrary code the model author chose. This isn't a training-time or inference-input attack; it's a supply-chain trap that fires the moment a developer calls Vocos.from_pretrained() against a Hugging Face repo they don't control, since that method automatically downloads and executes the malicious config. There's no EPSS score, no CISA KEV listing, no public PoC and no Nuclei template yet, so exploitation isn't observed in the wild, but the CVSS 8.8 (network, no privileges, full confidentiality/integrity/availability impact) reflects that once a victim is lured into loading a poisoned repo, compromise is complete and trivial to construct — it needs only a crafted YAML file, no code exploit development. Treat any TTS/audio pipeline that pulls Vocos checkpoints from Hugging Face as untrusted-input territory: restrict from_pretrained() to vetted, first-party repo IDs, review config.yaml contents before loading any third-party checkpoint, and track the upstream fix at github.com/gemelo-ai/vocos/issues/76 for a patched release with class_path allowlisting.

Sources: NVD vulncheck.com ATLAS

What is the risk?

High impact, low-to-moderate exploitation likelihood today. The vulnerability requires user interaction (a developer or pipeline choosing to load a specific model repo), which limits mass, automated exploitation compared to a fully unauthenticated network flaw — but once that interaction happens, exploitation is deterministic and grants full code execution with no privilege requirement and low attack complexity. The absence of a public exploit, Nuclei template, or KEV listing means this is not yet being weaponized at scale, but the pattern (unsandboxed class instantiation from remote config) is well understood by attackers who already target the ML model supply chain via poisoned Hugging Face repos and pickle-based weight files. Organizations that programmatically or semi-automatically pull community Vocos checkpoints (e.g., voice-cloning demos, TTS fine-tunes) carry the highest exposure.

How does the attack unfold?

Stage malicious model repo
Attacker publishes a Hugging Face repository with a crafted config.yaml whose class_path/init_args point to an arbitrary callable and attacker-controlled arguments.
AML.T0058
Victim loads the model
A developer or pipeline calls Vocos.from_pretrained() with the attacker's repo ID, triggering an automatic download of the malicious config.yaml.
AML.T0011.000
Unsafe reflection executes payload
instantiate_class imports the named module, resolves the attribute, and calls it with the config's init_args, executing the attacker's chosen code.
AML.T0010.003
Full code execution impact
Attacker achieves arbitrary code execution in the loading process, enabling data theft, lateral movement, or persistence on the host running the TTS pipeline.

How severe is it?

CVSS 3.1
8.8 / 10
EPSS
N/A
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 to a patched Vocos release once available (track github.com/gemelo-ai/vocos/issues/76) that allowlists permitted class_path values for feature_extractor, backbone, and head entries. 2) Until patched, never call Vocos.from_pretrained() with a Hugging Face repo ID that isn't explicitly vetted and pinned to a known-good commit/revision — treat it like executing an untrusted script. 3) Manually inspect config.yaml contents (class_path and init_args fields) before calling from_hparams() on any third-party or user-submitted configuration. 4) Run model-loading code in a sandboxed, network-egress-restricted container or VM with minimal privileges, since a successful exploit executes with the loading process's full permissions. 5) Ensure PyTorch is on a release that defaults torch.load(weights_only=True) to reduce the adjacent deserialization risk on the weights file itself. 6) Monitor for anomalous outbound connections or process spawns immediately following model-load calls as a detection signal.

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.6.2.3 - Third-party and customer requirements
NIST AI RMF
MAP 3.4 / GOVERN 6.1 - Third-party AI resources and supply chain risk
OWASP LLM Top 10
LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-79784?

Vocos, a neural audio vocoder library, instantiates any Python class named inside a model's config.yaml without restricting which class path is allowed, and calls it with attacker-controlled keyword arguments — so loading a model is equivalent to running arbitrary code the model author chose. This isn't a training-time or inference-input attack; it's a supply-chain trap that fires the moment a developer calls Vocos.from_pretrained() against a Hugging Face repo they don't control, since that method automatically downloads and executes the malicious config. There's no EPSS score, no CISA KEV listing, no public PoC and no Nuclei template yet, so exploitation isn't observed in the wild, but the CVSS 8.8 (network, no privileges, full confidentiality/integrity/availability impact) reflects that once a victim is lured into loading a poisoned repo, compromise is complete and trivial to construct — it needs only a crafted YAML file, no code exploit development. Treat any TTS/audio pipeline that pulls Vocos checkpoints from Hugging Face as untrusted-input territory: restrict from_pretrained() to vetted, first-party repo IDs, review config.yaml contents before loading any third-party checkpoint, and track the upstream fix at github.com/gemelo-ai/vocos/issues/76 for a patched release with class_path allowlisting.

Is CVE-2026-79784 actively exploited?

No confirmed active exploitation of CVE-2026-79784 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-79784?

1) Upgrade to a patched Vocos release once available (track github.com/gemelo-ai/vocos/issues/76) that allowlists permitted class_path values for feature_extractor, backbone, and head entries. 2) Until patched, never call Vocos.from_pretrained() with a Hugging Face repo ID that isn't explicitly vetted and pinned to a known-good commit/revision — treat it like executing an untrusted script. 3) Manually inspect config.yaml contents (class_path and init_args fields) before calling from_hparams() on any third-party or user-submitted configuration. 4) Run model-loading code in a sandboxed, network-egress-restricted container or VM with minimal privileges, since a successful exploit executes with the loading process's full permissions. 5) Ensure PyTorch is on a release that defaults torch.load(weights_only=True) to reduce the adjacent deserialization risk on the weights file itself. 6) Monitor for anomalous outbound connections or process spawns immediately following model-load calls as a detection signal.

What systems are affected by CVE-2026-79784?

This vulnerability affects the following AI/ML architecture patterns: model serving, audio/TTS inference pipelines, AI model supply chain / Hugging Face model loading.

What is the CVSS score for CVE-2026-79784?

CVE-2026-79784 has a CVSS v3.1 base score of 8.8 (HIGH).

What is the AI security impact?

Affected AI Architectures

model servingaudio/TTS inference pipelinesAI model supply chain / Hugging Face model loading

MITRE ATLAS Techniques

AML.T0002.001 Models
AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.3
NIST AI RMF: MAP 3.4 / GOVERN 6.1
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

Vocos instantiates a class named by a configuration file without restricting which class may be named. instantiate_class in vocos/pretrained.py takes the class_path value from the configuration, splits it into a module and an attribute, imports the module with __import__, resolves the attribute with getattr, and calls the result as args_class(*args, **kwargs) where kwargs is the config's own init_args mapping. No allowlist constrains the dotted path, so a configuration may name any importable callable and supply the arguments it is called with. Vocos.from_hparams reaches this for each of the feature_extractor, backbone and head entries, and Vocos.from_pretrained reaches it with a remote file: it downloads config.yaml from a caller-named Hugging Face repository and passes it straight to from_hparams. Loading a model from a repository the user does not control therefore executes code of the repository owner's choosing in the loading process. The neighbouring torch.load of the downloaded weights is a separate matter and is constrained on PyTorch releases that default weights_only to true, which leaves this path as the reachable one.

Exploitation Scenario

An attacker creates a Hugging Face repository styled as a legitimate or enticing Vocos voice model (e.g., 'high-quality-voice-clone-v2') and crafts its config.yaml so that one of the feature_extractor, backbone, or head entries sets class_path to a callable like os.system or subprocess.Popen, with init_args supplying a reverse-shell or data-exfiltration command as the constructor arguments. The attacker promotes the repo in a community forum, Discord, or as a dependency in a public demo notebook. A developer or automated pipeline calls Vocos.from_pretrained('attacker/high-quality-voice-clone-v2') to evaluate or integrate the 'model' — Vocos silently downloads config.yaml, resolves the attacker's dotted path via __import__ and getattr, and calls it with the attacker's kwargs, achieving code execution in the developer's environment or production inference server without any exploit development beyond writing a YAML file.

Weaknesses (CWE)

CWE-470 — Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'): The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

  • [Architecture and Design] Refactor your code to avoid using reflection.
  • [Architecture and Design] Do not use user-controlled inputs to select and load classes or code.

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
August 25, 2026
Last Modified
August 25, 2026
First Seen
August 25, 2026

Related Vulnerabilities