CVE-2026-79784: Vocos: RCE via unrestricted class loading in model config
HIGHVocos, 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.
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?
How severe is it?
What is the attack surface?
What should I do?
1 step-
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:
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
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
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')
Primary
CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') 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 References
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