CVE-2026-79785: X-AnyLabeling: MITM model swap yields RCE via torch.load

MEDIUM
Published August 25, 2026
CISO Take

X-AnyLabeling's model downloader disables TLS certificate and hostname verification (CWE-295) when fetching pretrained weights, and the only post-download check validates file format, not provenance, so a network-positioned attacker can substitute the model with one of their own choosing. For the SAM2 video, YOLOE, UPN and open_vision configurations, the substituted .pth/.pt file is loaded with torch.load without weights_only, which unpickles and executes attacker-controlled code on any pre-patched PyTorch install; ONNX targets instead let the attacker silently control the annotations the tool produces. The CVSS 5.9 (AC:H, no confirmed exploit, not in CISA KEV, no EPSS data) reflects that this requires an attacker to already be on-path for the HTTPS connection — a real bar, but a trivially clearable one on shared Wi-Fi, compromised corporate proxies, or a compromised CDN/release host. This is a data-labeling/annotation tool typically run by ML engineers with local code execution rights and access to training data and other models, making it a meaningful pivot point in an ML pipeline. Upgrade to v4.0.0-beta.9 or later immediately, and until then block or audit outbound model downloads and treat any host running X-AnyLabeling pre-beta.9 as exposed to code execution when fetching PyTorch-format models over untrusted networks.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium overall (CVSS 5.9) but the ceiling for the .pth/.pt code path is effectively critical: successful exploitation yields arbitrary code execution on the analyst/engineer's machine, not just a corrupted model. The limiting factor is attack complexity (AC:H) — the attacker must be able to intercept or redirect the HTTPS connection to the model release host, since no certificate or hostname is validated (ssl._create_unverified_context() paired with urllib.request.urlopen). No privileges or user interaction are required beyond the normal act of downloading a model through the tool's UI. There is no public exploit or Nuclei template, it is not in CISA KEV, and EPSS data is unavailable, all consistent with a vulnerability that is exploitable but not yet weaponized in the wild. Because X-AnyLabeling ships several PyTorch-format model configurations (SAM2 video, YOLOE, UPN, open_vision) by default, most real-world installs are exposed to the RCE path rather than the lower-impact ONNX integrity path.

How does the attack unfold?

Network positioning
Attacker gains a man-in-the-middle position on the victim's network path to the model release host (shared Wi-Fi, compromised proxy, DNS/route manipulation).
AML.T0010.003
Model substitution
Because TLS certificate and hostname checks are disabled, the attacker answers the HTTPS model download with a crafted .pth/.pt or ONNX file that passes the tool's format-only integrity check.
AML.T0018.002
Unsafe deserialization
X-AnyLabeling loads the substituted PyTorch-format file via torch.load without weights_only, unpickling and executing the attacker's embedded code.
AML.T0011.000
Impact
Attacker achieves code execution on the ML engineer's host (PyTorch path) or silently controls the annotations produced by the tool (ONNX path), compromising downstream labeling and training data.
AML.T0112.001

How severe is it?

CVSS 3.1
5.9 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR None
UI None
S Unchanged
C None
I High
A None

What should I do?

1 step
  1. Upgrade to X-AnyLabeling v4.0.0-beta.9 or later, which addresses the certificate validation gap (see commit 52f7c30 and the v4.0.0-beta.9 release). Until upgraded: block or tightly proxy-filter the tool's model-download traffic, avoid running it on untrusted networks (public Wi-Fi, unmanaged VPNs), and pre-provision known-good models locally instead of relying on first-run auto-download. Independent of this specific fix, treat torch.load calls without weights_only=True as a standing risk in any locally deployed ML tool — verify the patched version actually sets weights_only=True (or migrates to safetensors) for the SAM2/YOLOE/UPN/open_vision loaders, since TLS validation alone does not stop a compromised or malicious release host from serving a malicious .pth/.pt file. For detection, monitor for TLS connections from hosts running X-AnyLabeling that fail certificate validation, and audit model files already on disk with picklescan or fickling before they are loaded.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.10 - Third-party and supplier relationships
NIST AI RMF
MANAGE-2.3 - Procedures are followed to respond to and recover from a previously unknown risk when it is identified, including third-party AI resource risks
OWASP LLM Top 10
LLM03 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-79785?

X-AnyLabeling's model downloader disables TLS certificate and hostname verification (CWE-295) when fetching pretrained weights, and the only post-download check validates file format, not provenance, so a network-positioned attacker can substitute the model with one of their own choosing. For the SAM2 video, YOLOE, UPN and open_vision configurations, the substituted .pth/.pt file is loaded with torch.load without weights_only, which unpickles and executes attacker-controlled code on any pre-patched PyTorch install; ONNX targets instead let the attacker silently control the annotations the tool produces. The CVSS 5.9 (AC:H, no confirmed exploit, not in CISA KEV, no EPSS data) reflects that this requires an attacker to already be on-path for the HTTPS connection — a real bar, but a trivially clearable one on shared Wi-Fi, compromised corporate proxies, or a compromised CDN/release host. This is a data-labeling/annotation tool typically run by ML engineers with local code execution rights and access to training data and other models, making it a meaningful pivot point in an ML pipeline. Upgrade to v4.0.0-beta.9 or later immediately, and until then block or audit outbound model downloads and treat any host running X-AnyLabeling pre-beta.9 as exposed to code execution when fetching PyTorch-format models over untrusted networks.

Is CVE-2026-79785 actively exploited?

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

How to fix CVE-2026-79785?

Upgrade to X-AnyLabeling v4.0.0-beta.9 or later, which addresses the certificate validation gap (see commit 52f7c30 and the v4.0.0-beta.9 release). Until upgraded: block or tightly proxy-filter the tool's model-download traffic, avoid running it on untrusted networks (public Wi-Fi, unmanaged VPNs), and pre-provision known-good models locally instead of relying on first-run auto-download. Independent of this specific fix, treat torch.load calls without weights_only=True as a standing risk in any locally deployed ML tool — verify the patched version actually sets weights_only=True (or migrates to safetensors) for the SAM2/YOLOE/UPN/open_vision loaders, since TLS validation alone does not stop a compromised or malicious release host from serving a malicious .pth/.pt file. For detection, monitor for TLS connections from hosts running X-AnyLabeling that fail certificate validation, and audit model files already on disk with picklescan or fickling before they are loaded.

What systems are affected by CVE-2026-79785?

This vulnerability affects the following AI/ML architecture patterns: model serving, supply chain / model provisioning, computer vision annotation pipelines.

What is the CVSS score for CVE-2026-79785?

CVE-2026-79785 has a CVSS v3.1 base score of 5.9 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

model servingsupply chain / model provisioningcomputer vision annotation pipelines

MITRE ATLAS Techniques

AML.T0010.003 Model
AML.T0011.000 Unsafe AI Artifacts
AML.T0018.002 Embed Malware

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.10
NIST AI RMF: MANAGE-2.3
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

X-AnyLabeling's model downloader disabled TLS certificate verification. download_with_retry in anylabeling/services/auto_labeling/model.py built a context with ssl._create_unverified_context() and passed it to urllib.request.urlopen, so neither the certificate chain nor the hostname was checked on any model download, and models are fetched over HTTPS from the project's release host. Any party positioned to intercept that connection could therefore answer it with content of their own choosing. The response is written to a .part file and moved into place with os.replace, and the only post-download check, safe_check_model, validates the file's format rather than its provenance: no hash or signature is compared against an expected value. For an ONNX target the substituted file passes onnx.checker.check_model and is then used for inference, so the attacker chooses the model that produces the application's annotations. For a .pth or .pt target, which the shipped SAM2 video, YOLOE, UPN and open_vision configurations use, the check worker calls torch.load without weights_only, so a substituted file is unpickled and executes code of the attacker's choosing on PyTorch releases predating the weights_only default.

Exploitation Scenario

An ML engineer on a shared office Wi-Fi or behind a compromised corporate TLS-inspecting proxy opens X-AnyLabeling and selects the SAM2 video auto-labeling feature, triggering a first-run model download from the project's GitHub release host over HTTPS. Because the downloader uses ssl._create_unverified_context(), the attacker who controls the network path answers the request with a crafted .pth file instead of returning an error or being blocked — no certificate mismatch is ever surfaced to the user. The file passes the tool's only integrity check (a format check, not a signature check), is moved into place, and is loaded by the check worker via torch.load without weights_only, which unpickles and executes the attacker's embedded payload with the engineer's local privileges — giving the attacker a foothold on a machine that likely has access to proprietary training data, credentials, and other internal models.

Weaknesses (CWE)

CWE-295 — Improper Certificate Validation: The product does not validate, or incorrectly validates, a certificate.

  • [Architecture and Design, Implementation] Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • [Implementation] If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Timeline

Published
August 25, 2026
Last Modified
August 25, 2026
First Seen
August 25, 2026

Related Vulnerabilities