TorchServe Vulnerabilities: What You Should Know

Table of Contents

• Module 1: The ShellTorch Vulnerability Chain in TorchServe
  • What Is TorchServe?
  • Overview of the ShellTorch Vulnerability Chain
  • Vulnerability 1: Unauthenticated Management Interface
  • Vulnerability 2: Server-Side Request Forgery (CVE-2023-43654)
  • Vulnerability 3: Unsafe Deserialization in SnakeYAML (CVE-2022-1471)
  • The Full Attack Chain: From Zero Access to Remote Code Execution
  • Business Impact and Threat Actor Motivation
  • Affected Versions and Patch Status
  • Default Configuration Risk Factors
  • Exploitation Likelihood and Real-World Activity
  • Risk Assessment Framework
  • Immediate Remediation Steps
  • General Security Best Practices
• Summary

Module 1: The ShellTorch Vulnerability Chain in TorchServe

What Is TorchServe?

TorchServe is an open source model-serving package built as part of the PyTorch ecosystem. PyTorch itself is a widely used machine learning (ML) framework that underpins a large share of natural language processing (NLP) applications, including many of the systems behind modern generative AI products such as large language model chat assistants. TorchServe is the component responsible for actually hosting and exposing a trained model so that it can receive inference requests over the network — in effect, it is the “runtime” that wraps a model and makes it callable as a service.

Although TorchServe itself is not a widely recognized brand name, its usage footprint is substantial:

• Approximately 30,000 downloads per month from PyPI.
• Approximately 1 million pulls per month from DockerHub.
• Used as a dependency inside larger AI/ML platforms deployed by major technology companies, including Amazon, Google, and Microsoft.

Because it is frequently embedded as a dependency rather than installed directly by name, many organizations that are technically exposed to this vulnerability chain may not immediately recognize that they are running TorchServe underneath a higher-level AI product or internal ML pipeline.

Overview of the ShellTorch Vulnerability Chain

Security researchers at Oligo Security identified a set of vulnerabilities in TorchServe that, when chained together, allow an attacker to achieve unauthenticated remote code execution. This vulnerability chain was named ShellTorch and was disclosed responsibly, giving the PyTorch/TorchServe maintainers time to begin remediation before public disclosure.

ShellTorch is not a single CVE — it is a combination of three distinct weaknesses:

1. A completely unauthenticated management interface (no assigned CVE — a design/configuration flaw rather than a classic code vulnerability).
2. CVE-2023-43654 — a Server-Side Request Forgery (SSRF) vulnerability.
3. CVE-2022-1471 — an unsafe deserialization vulnerability in the SnakeYAML library, a dependency of TorchServe.

mindmap
  root((ShellTorch))
    Issue 1: No Auth
      Management interface exposed on all interfaces
      No login/password required
      Not a CVE - a configuration/design flaw
    Issue 2: SSRF
      CVE-2023-43654
      Attacker forces server to fetch external model
    Issue 3: Deserialization
      CVE-2022-1471
      SnakeYAML dependency
      Malicious YAML executes attacker code
    Result
      Unauthenticated Remote Code Execution

The dependency relationship between these components matters for understanding why the chain works the way it does:

flowchart TD
    subgraph "Dependency Chain"
        PT["PyTorch (ML Framework)"] --> TS["TorchServe (Model Serving)"]
        TS --> SY["SnakeYAML (Config Parsing Library)"]
    end

    subgraph "Vulnerabilities"
        V1["Vuln 1: No Authentication on Management Interface"]
        V2["Vuln 2: SSRF - CVE-2023-43654"]
        V3["Vuln 3: Unsafe Deserialization - CVE-2022-1471"]
    end

    TS -.exposes.-> V1
    TS -.contains.-> V2
    SY -.contains.-> V3

    V1 --> V2 --> V3 --> RCE["Unauthenticated Remote Code Execution"]

    style RCE fill:#f66,color:#fff

Vulnerability 1: Unauthenticated Management Interface

The first and most fundamental issue is that TorchServe’s management interface — the connection used to upload models, register new models, or otherwise modify the running application — has no built-in authentication. There is no login and no password required, and in the default configuration this interface is bound to all network interfaces and IP addresses assigned to the host, meaning it can be exposed directly to the internet if the host itself is internet-facing.

This is not a coding bug in the traditional sense (it has no assigned CVE), but it is arguably the most dangerous element of the chain because it is the entry point for everything that follows. Two contributing factors explain how this situation arose:

• Open source development norms. An open source project maintainer has no inherent obligation to build in fully integrated authentication. The expectation in much of the open source ecosystem is that a downstream integrator will bolt on their own authentication layer (an API gateway, a reverse proxy with auth, network-level access control, etc.). That said, the way this was implemented and left as the default still represents a legitimate design weakness — it does not excuse the outcome.
• The pace of generative AI adoption. As organizations race to build products around generative AI and NLP, basic, well-understood security controls are sometimes overlooked in the rush to ship. An open, unauthenticated administrative interface is exactly the kind of basic control gap that a slower, more deliberate security review would typically catch.

Vulnerability 2: Server-Side Request Forgery (CVE-2023-43654)

CVE-2023-43654 is a Server-Side Request Forgery (SSRF) vulnerability. In a typical SSRF scenario, an attacker manipulates an application into making an outbound request on the attacker’s behalf, often bypassing network segmentation or authentication that would otherwise prevent direct access. TorchServe’s version of this issue is somewhat more direct: because the management interface has no authentication, an attacker can simply connect to it and instruct the server to fetch a model from an attacker-controlled external server.

Once the server pulls that external resource, the attacker has successfully delivered a payload of their choosing into the TorchServe environment: a malicious model. Even considered in isolation, a malicious model is a serious problem — an attacker who can manipulate what a production model does (for example, altering how it classifies images or interprets text) can silently corrupt the behavior of any downstream system that trusts that model’s output. In the ShellTorch chain, however, the malicious model archive is also the delivery vehicle for the next vulnerability.

Vulnerability 3: Unsafe Deserialization in SnakeYAML (CVE-2022-1471)

CVE-2022-1471 dates back to 2022 and affects SnakeYAML, an open source library used for parsing configuration files, which sits underneath TorchServe as a further dependency. The dependency stack looks like this: PyTorch (the ML framework) depends on TorchServe (the serving layer), which in turn depends on SnakeYAML (the configuration/YAML parser).

The SnakeYAML flaw allows for unsafe deserialization: an attacker can embed executable code inside a YAML configuration file, and because SnakeYAML performs no validation on that content before deserializing it, the code is executed by the server. When this is combined with the SSRF vulnerability above, the malicious model archive delivered via SSRF can itself contain a crafted YAML file — meaning the attacker’s payload is deserialized and executed automatically as part of loading the “model.”

The Full Attack Chain: From Zero Access to Remote Code Execution

Put together, the three weaknesses combine into a single, complete exploitation path requiring no credentials whatsoever:

1. The attacker connects directly to the unauthenticated management interface.
2. The attacker instructs TorchServe to register/load a model from an attacker-controlled external server (SSRF, CVE-2023-43654).
3. TorchServe fetches the malicious model archive, which contains a crafted YAML configuration file.
4. SnakeYAML deserializes the YAML content without validation (CVE-2022-1471), executing the embedded attacker code.
5. The attacker now has unauthenticated remote code execution on the host running TorchServe.

sequenceDiagram
    autonumber
    participant A as Attacker
    participant M as TorchServe Management API
    participant C as Attacker-Controlled Server
    participant I as TorchServe Inference Engine
    participant O as Underlying OS/Host

    Note over A,M: No authentication required on management interface
    A->>M: Connect directly to management port (default 0.0.0.0)
    M-->>A: Accepts request, no credentials checked
    A->>M: Submit "register model" request pointing to external URL
    M->>C: SSRF - server fetches attacker-hosted model archive (CVE-2023-43654)
    C-->>M: Returns malicious .mar model archive containing crafted YAML config
    M->>I: Loads model archive, parses embedded YAML via SnakeYAML
    I->>I: Unsafe deserialization of YAML (CVE-2022-1471)
    I->>O: Executes attacker-supplied code
    O-->>A: Remote Code Execution achieved
    Note over A,O: Attacker can now steal data, corrupt models, or pivot to other systems

Business Impact and Threat Actor Motivation

Once an attacker has RCE on a TorchServe host, the practical value to a threat actor is broad, not narrow:

• Data theft. Any data flowing into the model for inference — which may include customer-submitted inputs or sensitive business data — can be intercepted or exfiltrated. Intellectual property embodied in the model itself (its weights, architecture, or training-derived behavior) is also exposed.
• Model integrity corruption. The attacker can upload or swap in their own model, silently changing how the application classifies or interprets data going forward. This is a form of supply-chain/model-poisoning risk layered on top of the RCE.
• General-purpose RCE / pivot point. This is not merely an “AI security” issue — it is a full remote code execution foothold inside the environment. From that foothold, the attacker can pivot to any other servers, services, or endpoints reachable from the compromised host, exactly as with any other RCE-class compromise.

flowchart LR
    RCE["Unauthenticated RCE on TorchServe Host"] --> DT["Data Theft: customer inputs, model IP"]
    RCE --> MC["Model Corruption: swap/poison the model"]
    RCE --> PV["Lateral Pivot to Other Hosts/Services"]
    DT --> IMPACT["Business Impact"]
    MC --> IMPACT
    PV --> IMPACT

Affected Versions and Patch Status

This is an important nuance: patching alone is not sufficient. Upgrading to 0.8.2 addresses the deserialization vulnerability but does not, by itself, remediate the unauthenticated-exposure problem. Configuration changes (covered below) are still required.

Default Configuration Risk Factors

The TorchServe configuration file contains several fields that directly determine exposure:

Organizations running TorchServe as part of an AWS or Google Cloud deployment should also check for cloud-provider-specific guidance, since both Amazon and Google have published notifications and recommended controls related to this exposure pattern.

flowchart TD
    Start["TorchServe Deployment"] --> Check{"Is management_address<br/>set to 0.0.0.0?"}
    Check -->|Yes| Exposed["Management interface reachable<br/>on all network interfaces"]
    Check -->|No, bound to 127.0.0.1 or internal IP| Restricted["Management interface only<br/>reachable locally/internally"]
    Exposed --> Internet{"Is the host itself<br/>internet-facing?"}
    Internet -->|Yes| Critical["CRITICAL: fully internet-exposed,<br/>unauthenticated admin access"]
    Internet -->|No| Internal["Internal-only exposure,<br/>still risky but reduced blast radius"]
    style Critical fill:#f66,color:#fff

Exploitation Likelihood and Real-World Activity

As of the disclosure covered here, no confirmed proof of exploitation in the wild had been reported. Oligo Security’s responsible disclosure process is one reason for this: it gave maintainers a window to begin remediation before full public detail was released. Oligo did publish a proof-of-concept demonstration (via a short video walkthrough), showing that exploitation is achievable.

The technical bar to build a working exploit is described as fairly low — the main gap protecting organizations at the time of this discussion is that an adversary still has to independently construct (or obtain) a working exploit implementation. Given the low technical complexity, this gap should not be relied upon as a durable protection; exploitation activity is plausible in the near term following disclosure of this class of vulnerability.

Risk Assessment Framework

To help an organization quickly triage whether it is meaningfully exposed to this vulnerability chain, the following five-question assessment framework was used:

flowchart TD
    Q1["1. What is the CVSS score?"] --> A1["9.8 (Critical) for both CVEs;<br/>the no-auth issue itself has no CVE<br/>but would rate similarly severe"]
    Q2["2. Is this internet-facing?"] --> A2["Depends on management_address<br/>configuration and host network placement"]
    Q3["3. Is there an active PoC?"] --> A3["No easily-accessible public PoC yet,<br/>but low technical barrier to create one"]
    Q4["4. Can the vulnerable method<br/>be exploited in your environment?"] --> A4["Yes, if running version <= 0.8.1<br/>or a vulnerable default configuration"]
    Q5["5. What is the priority level<br/>for remediation?"] --> A5["Critical for almost all organizations<br/>running ML models on sensitive data"]

Immediate Remediation Steps

The following actions were identified as the immediate priorities for any enterprise running an exposed or vulnerable TorchServe instance:

1. Patch to version 0.8.2 or later. This resolves the SnakeYAML deserialization vulnerability (CVE-2022-1471). Further updates addressing the exposure/authentication gap more completely should be expected and should be tracked.
2. Change the network binding of the management, inference, and metrics interfaces. Update management_address, inference_address, and metrics_address in the configuration file away from the default 0.0.0.0 binding to a localhost address (127.0.0.1) or a restricted internal IP address. The key objective is to remove these interfaces from public accessibility.
3. Restrict allowed_urls. This configuration value controls which domains TorchServe is permitted to fetch models from. It should be locked down to only the specific, trusted domains that your organization actually uses to publish or update models — closing off the SSRF-to-model-load path used in this attack chain.

flowchart TD
    Start["Identify TorchServe deployment"] --> V{"Version <= 0.8.1?"}
    V -->|Yes| Patch["Patch to 0.8.2 or later"]
    V -->|No| Cfg
    Patch --> Cfg["Review configuration file"]
    Cfg --> Bind["Set management_address, inference_address,<br/>metrics_address to 127.0.0.1 or internal IP"]
    Bind --> Allow["Restrict allowed_urls to trusted domains only"]
    Allow --> Cloud{"Running on AWS/GCP/Azure?"}
    Cloud -->|Yes| CloudGuidance["Review cloud provider's specific<br/>ShellTorch/TorchServe guidance"]
    Cloud -->|No| Done["Remediation complete for this vector"]
    CloudGuidance --> Done
    style Done fill:#6c6,color:#000

General Security Best Practices

Beyond the specific configuration and patch actions above, the broader lessons from this vulnerability chain apply well past TorchServe itself:

• Slow down before shipping fast-moving AI features. The rapid pace of generative AI and NLP adoption is not a justification for skipping basic security controls. An unauthenticated administrative interface is a fundamentally simple gap that a deliberate security review would typically catch regardless of how novel the underlying technology is.
• Use allow lists broadly, not just for URLs. The allowed_urls restriction is one specific instance of a general allow-list pattern that should be applied wherever an application can be told to reach out to external resources.
• Run automated code testing and regular penetration testing. These practices are more likely to surface deeper vulnerabilities such as SSRF and unsafe deserialization before they can be chained together by an attacker.
• Segment compromised or high-risk servers. Even after a compromise occurs, limiting what a server is allowed to communicate with — and what actions it is permitted to take — reduces the blast radius of any single compromised host.
• Apply behavioral, least-privilege analysis to every new implementation. When introducing a new piece of software, service, or feature into an environment, explicitly ask: What does it need to do? What does it need to access? Who needs to access it? What level of control does it require? Answering these questions up front allows the initial deployment to be locked down from day one rather than being loosened over time, producing a materially stronger security posture than a “ready, fire, aim” approach to adopting new AI tooling.

flowchart LR
    subgraph "Defense in Depth for AI/ML Serving Infrastructure"
        direction TB
        AL["Allow-list external URLs<br/>and model sources"]
        PT["Automated + manual<br/>penetration testing"]
        SEG["Network segmentation<br/>of ML serving hosts"]
        BA["Behavioral / least-privilege<br/>analysis for new deployments"]
    end
    AL --> Posture["Stronger Security Posture"]
    PT --> Posture
    SEG --> Posture
    BA --> Posture

Summary

The ShellTorch vulnerability chain in TorchServe demonstrates how three individually serious — but not equally novel — weaknesses can combine into a critical, unauthenticated remote code execution path in widely deployed AI/ML infrastructure:

• An unauthenticated management interface, exposed by default across all network interfaces, provided the initial foothold with no credentials required.
• CVE-2023-43654, an SSRF vulnerability, allowed an attacker connected to that interface to force the server to fetch a malicious model from an attacker-controlled location.
• CVE-2022-1471, an unsafe deserialization flaw in the SnakeYAML dependency, allowed a crafted YAML configuration embedded in that malicious model to execute arbitrary attacker code the moment the model was loaded.

Chained together, these three issues let an attacker go from zero access to full remote code execution against a production AI model-serving host — with the ability to steal sensitive data, corrupt model behavior/output, or pivot laterally into the rest of the environment.

Mitigation Checklist

• Inventory all systems (including those embedding TorchServe as a transitive dependency of a larger AI/ML platform) to determine actual exposure.
• Confirm the TorchServe version in use; patch to 0.8.2 or later wherever version 0.8.1 or earlier is found.
• Do not treat patching alone as sufficient remediation — the default network exposure is not fixed automatically by the patch.
• Set management_address, inference_address, and metrics_address to 127.0.0.1 or a restricted internal IP, removing these interfaces from public/internet accessibility.
• Restrict allowed_urls to only the specific, trusted domains your organization uses to publish or update models.
• If deployed on AWS, Google Cloud, or another cloud provider, review that provider’s specific guidance and recommended controls for this exposure.
• Add automated code testing and regular penetration testing coverage for AI/ML serving infrastructure, specifically targeting SSRF and deserialization-class issues.
• Apply network segmentation to ML serving hosts so a compromise of one host does not provide unrestricted lateral movement.
• Adopt a behavioral, least-privilege review process for every new AI/ML tool or feature before deployment: what it needs to do, what it needs to access, who needs access, and what level of control it requires.
• Treat the pace of generative AI adoption as a reason to apply more security discipline, not less — do not let time-to-market pressure bypass basic controls like authentication and allow-listing.

Search Terms

torchserve · vulnerabilities · know · vulnerability · briefings · networking · systems · security · chain · risk · shelltorch