CVE-2026-79784 in Vocos
Summary
by MITRE • 08/25/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in Vocos represents a critical insecure deserialization flaw rooted in dynamic class instantiation based on untrusted configuration data. The core technical issue lies within the instantiate_class function located in vocos/pretrained.py, which accepts a class_path value directly from a YAML configuration file without any validation or allowlisting mechanisms. This process involves splitting the provided string into a module name and an attribute, importing the specified module using Python's _import_ function, resolving the target callable via getattr, and subsequently invoking it with arguments derived from the configuration’s init_args mapping. Because there are no restrictions on which classes can be instantiated or what modules can be imported, an attacker who controls the input configuration file can dictate arbitrary code execution within the context of the application running Vocos.
This architectural weakness is exacerbated by how high-level entry points utilize this function. The from_hparams method processes feature_extractor, backbone, and head entries through this unsafe instantiation process. More critically, the from_pretrained method facilitates remote loading by downloading a config.yaml file from a user-specified Hugging Face repository and passing it directly to from_hparams without sanitization. Consequently, when a user loads a model from a repository they do not control or trust, the system executes code chosen by the repository owner during the loading phase. This effectively turns the model loading process into a remote code execution vector, as the attacker can craft a malicious configuration file that triggers arbitrary Python commands upon import and instantiation.
The operational impact of this vulnerability is severe, allowing for full compromise of the host environment where Vocos is executed. An adversary could exploit this to exfiltrate sensitive data, install backdoors, or pivot further into internal networks depending on the privileges under which the application runs. While PyTorch’s torch.load function has mitigations such as defaulting weights_only to true in recent releases to prevent arbitrary code execution during weight loading, this specific vulnerability remains reachable because it bypasses those protections by targeting the configuration parsing logic rather than the binary model weights themselves. This distinction ensures that even with secure defaults for tensor loading, the application remains vulnerable through its metadata and architecture definition files.
To mitigate this risk, developers must implement strict allowlisting of permitted modules and classes before instantiation occurs. Input validation should ensure that only expected library components are loaded, rejecting any configuration entries that reference external or unexpected packages. Additionally, relying on remote configurations from untrusted sources like public Hugging Face repositories without verification introduces significant supply chain risks; therefore, organizations should prioritize loading models from verified, internal, or trusted sources and consider implementing a sandboxed environment for processing untrusted model files. Aligning with industry standards such as CWE-20 Improper Input Validation highlights the necessity of rigorous checks on all external inputs, while ATT&CK techniques related to command and script interpretation underscore the danger of executing dynamic code derived from user-controlled data structures.