CVE-2025-49837: GPT-SoVITS-WebUI Deserialization Flaw

CVE-2025-49837 Overview

CVE-2025-49837 is an insecure deserialization vulnerability affecting GPT-SoVITS-WebUI, a popular voice conversion and text-to-speech web application. The vulnerability exists in the vr.py file within the AudioPre class, where user-controlled input is passed directly to PyTorch's torch.load function without proper validation or sanitization. This allows remote attackers to achieve arbitrary code execution by supplying a malicious serialized payload disguised as a model file.

Critical Impact

Remote attackers can achieve arbitrary code execution on systems running vulnerable GPT-SoVITS-WebUI instances by exploiting unsafe deserialization in the model loading functionality.

Affected Products

• rvc-boss gpt-sovits-webui version 20250228v3 and prior

Discovery Timeline

• 2025-07-15 - CVE CVE-2025-49837 published to NVD
• 2025-07-30 - Last updated in NVD database

Technical Details for CVE-2025-49837

Vulnerability Analysis

This vulnerability stems from the unsafe use of PyTorch's torch.load function with user-controllable input. The attack chain begins when a user provides input through the model_choose variable in the web interface. This input, intended to specify a path to a voice model file, flows through multiple functions without adequate validation.

When a user interacts with the UVR5 (Ultimate Vocal Remover) component of GPT-SoVITS-WebUI, the model_choose parameter is passed to the uvr function. This function creates a new instance of the AudioPre class, passing the user-supplied path as the model_path attribute. During this process, the .pth extension is appended to the path. Within the AudioPre class constructor, the torch.load function is called with this user-controlled path.

PyTorch's torch.load function uses Python's pickle module under the hood to deserialize objects. Pickle deserialization is inherently unsafe when processing untrusted data, as it can instantiate arbitrary Python objects and execute code during the unpickling process. An attacker who can control the file being loaded can craft a malicious .pth file containing a pickled payload that executes arbitrary system commands upon deserialization.

The attack is network-accessible through the web interface, requires no authentication, and has no user interaction requirements for exploitation. Successful exploitation grants the attacker the ability to execute arbitrary code with the privileges of the application process, potentially leading to complete system compromise, data exfiltration, or lateral movement within the network.

Root Cause

The root cause is CWE-502: Deserialization of Untrusted Data. The application uses torch.load to deserialize model files without validating the source or integrity of the data. Since torch.load relies on Python's pickle module, any maliciously crafted file can execute arbitrary code during the deserialization process. The vulnerability is compounded by the lack of input validation on the model_choose parameter, allowing attackers to potentially specify arbitrary file paths.

Attack Vector

The attack is conducted over the network through the GPT-SoVITS-WebUI interface. An attacker can exploit this vulnerability by:

1. Uploading or placing a malicious .pth file containing a crafted pickle payload on the target system
2. Using the web interface to select this malicious file as the model
3. Triggering the model loading process, which calls torch.load with the attacker-controlled path
4. The malicious pickle payload executes arbitrary Python code during deserialization

The vulnerability exists in the file path handling between tools/uvr5/webui.py and tools/uvr5/vr.py. For detailed code context, refer to the GitHub Security Advisory which documents the vulnerable code paths at lines 32 in vr.py and multiple locations in webui.py.

Detection Methods for CVE-2025-49837

Indicators of Compromise

• Unexpected network connections originating from the GPT-SoVITS-WebUI process
• Suspicious .pth files uploaded to model directories that were not created by administrators
• Anomalous process spawning from the Python interpreter running GPT-SoVITS-WebUI
• Unusual file system access patterns from the web application process

Detection Strategies

• Monitor for torch.load calls with paths containing user-controllable input or pointing outside expected model directories
• Implement file integrity monitoring on model directories to detect unauthorized file modifications
• Deploy endpoint detection and response (EDR) solutions to monitor for suspicious process chains originating from Python/GPT-SoVITS processes
• Analyze web application logs for unusual model loading requests or path traversal attempts

Monitoring Recommendations

• Enable verbose logging for the GPT-SoVITS-WebUI application to capture model loading events
• Configure network monitoring to detect unusual outbound connections from the application server
• Implement process monitoring to alert on unexpected child processes spawned by the web application
• Set up file system auditing on directories where model files are stored

How to Mitigate CVE-2025-49837

Immediate Actions Required

• Restrict network access to GPT-SoVITS-WebUI instances to trusted users and networks only
• Implement strict input validation on the model_choose parameter to allow only expected model names
• Audit existing .pth files in model directories for unexpected or suspicious content
• Consider running GPT-SoVITS-WebUI in an isolated container or sandboxed environment to limit blast radius

Patch Information

At the time of publication, no known patched versions are available for GPT-SoVITS-WebUI. Users should monitor the official GPT-SoVITS GitHub repository for security updates and apply patches as soon as they become available. The vulnerability is tracked in GitHub Security Advisory GHSL-2025-049 through GHSL-2025-053.

Workarounds

• Use torch.load with weights_only=True parameter (requires code modification) to prevent arbitrary code execution during deserialization
• Implement an allowlist of valid model paths and validate user input against this list before loading
• Deploy the application behind a reverse proxy with authentication to limit access to trusted users
• Run the application with minimal privileges and in an isolated environment (container, VM, or sandbox)

# Example: Restrict network access using iptables
# Only allow connections from trusted IP addresses
iptables -A INPUT -p tcp --dport 7860 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7860 -j DROP