CVE-2025-5173: Label Studio PyTorch .pt

Q: Is CVE-2025-5173 actively exploited?

No confirmed active exploitation of CVE-2025-5173 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2025-5173?

1. IMMEDIATE: Audit all .pt model files loaded by label-studio-ml-backend — verify SHA checksums against known-good sources. 2. Restrict the `path` argument to an allowlist of trusted directories; block user-controllable file paths reaching the `load()` function. 3. Switch to `torch.load(..., weights_only=True)` (PyTorch ≥1.13) to disable arbitrary code execution during deserialization — this is the correct long-term fix the vendor should implement. 4. Run the ML backend in an isolated container with no access to sensitive credentials or internal networks (defense in depth). 5. Monitor for unexpected process spawning from the label-studio-ml-backend process. 6. If using pip: pin label-studio-ml to a reviewed commit hash until a fix is released; watch GitHub issue #765 for patch status. 7. Do not load model files from untrusted public repositories (HuggingFace, public S3 buckets) without verification.

Q: What systems are affected by CVE-2025-5173?

This vulnerability affects the following AI/ML architecture patterns: ML data labeling pipelines, Model serving, Training pipelines, MLOps/CI-CD pipelines.

Q: What is the CVSS score for CVE-2025-5173?

CVE-2025-5173 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.19%.

CISO Take

A malicious PyTorch model file (.pt) loaded by the YOLO integration in label-studio-ml-backend triggers arbitrary code execution via Python pickle deserialization — the classic unsafe `torch.load()` pattern. If your ML teams use Label Studio for data labeling with YOLO models sourced from any external or shared location, treat this as a supply chain risk and restrict model file provenance immediately. No patch is available; apply compensating controls now.

What is the risk?

CVSS 7.8 with local attack vector reduces immediate internet-exposed risk, but in shared ML environments (multi-user Label Studio deployments, CI/CD pipelines, or Jupyter-adjacent workflows) the 'local' requirement is trivially met by any authenticated user or compromised upstream model source. The absence of a patch and the rolling-release model with no versioned fix compounds the exposure. EPSS 0.001 reflects current in-the-wild activity, not potential — PyTorch pickle exploits are well-documented and tooling exists. Elevated risk for organizations running data labeling pipelines with externally-sourced models.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Label Studio	pip	<= 1.0.9	No patch
27.7K 1 dependents Pushed 5d ago 71% patched ~145d to patch Full package profile →
label_studio_ml_backend	—	—	No patch

How severe is it?

CVSS 3.1

7.8 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 8% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Local

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

7 steps

IMMEDIATE

Audit all .pt model files loaded by label-studio-ml-backend — verify SHA checksums against known-good sources.
Restrict the path argument to an allowlist of trusted directories; block user-controllable file paths reaching the load() function.
Switch to torch.load(..., weights_only=True) (PyTorch ≥1.13) to disable arbitrary code execution during deserialization — this is the correct long-term fix the vendor should implement.
Run the ML backend in an isolated container with no access to sensitive credentials or internal networks (defense in depth).
Monitor for unexpected process spawning from the label-studio-ml-backend process.
If using pip: pin label-studio-ml to a reviewed commit hash until a fix is released; watch GitHub issue #765 for patch status.
Do not load model files from untrusted public repositories (HuggingFace, public S3 buckets) without verification.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply Chain Code Execution Framework Model AML.T0010.003 - Model AML.T0011.000 - Unsafe AI Artifacts AML.T0018.002 - Embed Malware AML.T0058 - Publish Poisoned Models

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.6 - AI supply chain management

NIST AI RMF

MANAGE-2.2 - Risk treatments for AI risks

OWASP LLM Top 10

LLM05 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2025-5173?

A malicious PyTorch model file (.pt) loaded by the YOLO integration in label-studio-ml-backend triggers arbitrary code execution via Python pickle deserialization — the classic unsafe `torch.load()` pattern. If your ML teams use Label Studio for data labeling with YOLO models sourced from any external or shared location, treat this as a supply chain risk and restrict model file provenance immediately. No patch is available; apply compensating controls now.

Is CVE-2025-5173 actively exploited?

No confirmed active exploitation of CVE-2025-5173 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-5173?

1. IMMEDIATE: Audit all .pt model files loaded by label-studio-ml-backend — verify SHA checksums against known-good sources. 2. Restrict the `path` argument to an allowlist of trusted directories; block user-controllable file paths reaching the `load()` function. 3. Switch to `torch.load(..., weights_only=True)` (PyTorch ≥1.13) to disable arbitrary code execution during deserialization — this is the correct long-term fix the vendor should implement. 4. Run the ML backend in an isolated container with no access to sensitive credentials or internal networks (defense in depth). 5. Monitor for unexpected process spawning from the label-studio-ml-backend process. 6. If using pip: pin label-studio-ml to a reviewed commit hash until a fix is released; watch GitHub issue #765 for patch status. 7. Do not load model files from untrusted public repositories (HuggingFace, public S3 buckets) without verification.

What systems are affected by CVE-2025-5173?

This vulnerability affects the following AI/ML architecture patterns: ML data labeling pipelines, Model serving, Training pipelines, MLOps/CI-CD pipelines.

What is the CVSS score for CVE-2025-5173?

CVE-2025-5173 has a CVSS v3.1 base score of 7.8 (HIGH). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

ML data labeling pipelinesModel servingTraining pipelinesMLOps/CI-CD pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model

AML.T0011.000 Unsafe AI Artifacts

AML.T0018.002 Embed Malware

AML.T0058 Publish Poisoned Models

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.1.6

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

A vulnerability has been found in HumanSignal label-studio-ml-backend up to 9fb7f4aa186612806af2becfb621f6ed8d9fdbaf and classified as problematic. Affected by this vulnerability is the function load of the file label-studio-ml-backend/label_studio_ml/examples/yolo/utils/neural_nets.py of the component PT File Handler. The manipulation of the argument path leads to deserialization. An attack has to be approached locally. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available.

Exploitation Scenario

An attacker with access to the model file path (e.g., a malicious insider, a compromised model registry, or an adversary who has already gained write access to a shared filesystem) crafts a malicious PyTorch .pt file using Python's pickle module to embed a reverse shell payload. When a labeling engineer loads or restarts the YOLO ML backend with this model file, `torch.load()` deserializes the pickle object and executes the attacker's code with the backend process privileges. In a CI/CD context where models are pulled from a shared artifact store before training runs, this becomes a supply-chain vector that triggers automatically without user interaction beyond routine pipeline execution.

Weaknesses (CWE)

CWE-20 Improper Input Validation Primary CWE-502 Deserialization of Untrusted Data Primary CWE-502 Deserialization of Untrusted Data Primary CWE-20 Improper Input Validation CWE-502 Deserialization of Untrusted Data

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

[Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.