CVE-2026-79784: Vocos through 0.1.0 Arbitrary Code Execution via Unrestricted class_path in Model Configuration
Vocos instantiates a class named by a configuration file without restricting which class may be named. instantiateclass in vocos/pretrained.py takes the classpath 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 argsclass(args, kwargs) where kwargs is the config's own initargs mapping. No allowlist constrains the dotted path, so a configuration may name any importable callable and supply the arguments it is called with. Vocos.fromhparams reaches this for each of the featureextractor, backbone and head entries, and Vocos.frompretrained reaches it with a remote file: it downloads config.yaml from a caller-named Hugging Face repository and passes it straight to fromhparams. 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 weightsonly to true, which leaves this path as the reachable one.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Any user or service that loads Vocos model configuration from an untrusted source is exposed. In particular, Vocos.from_pretrained downloads config.yaml from a caller-selected Hugging Face repository and processes it without restricting the configured class paths.
What does an attacker need to exploit it?
An attacker needs to cause a target to load a model configuration they control, such as by convincing them to use an attacker-controlled Hugging Face repository. No authentication or pre-existing privileges are required, but the target must perform the model-loading action.
Are default Vocos model-loading paths affected?
Yes. Vocos.from_pretrained reaches the vulnerable configuration handling after downloading config.yaml, and Vocos.from_hparams processes the feature_extractor, backbone, and head configuration entries. The issue is independent of the neighboring weight-loading behavior and remains reachable even where PyTorch defaults torch.load to weights_only=true.
What can be done if patching is not immediately possible?
Do not load models or configuration files from repositories or other sources you do not control. Restrict model loading to trusted, reviewed configurations and repositories until a fix that constrains permitted class paths is available.