CVE-2026-79785 in X-AnyLabeling
Summary
by MITRE • 08/25/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability in X-AnyLabeling represents a critical failure in transport layer security during the automated model download process. The core technical flaw resides within the download_with_retry function located in anylabeling/services/auto_labeling/model.py, which explicitly constructs an SSL context using ssl._create_unverified_context(). This configuration instructs the underlying urllib.request.urlopen module to bypass all standard TLS certificate verification procedures. Consequently, neither the server's identity nor the validity of its digital certificate chain is validated against trusted root authorities. By disabling hostname and certificate checks, the application creates a man-in-the-middle attack surface where an adversary positioned on the network path can intercept the HTTPS connection between the client and the project's release host without triggering any security warnings or errors in the standard TLS handshake process.
The operational impact of this flaw is severe due to the subsequent handling of the downloaded data. Once the malicious response is received, it is written to a temporary .part file and atomically moved into place using os.replace, ensuring that the compromised model immediately replaces the intended artifact without leaving residual partial files that might alert users to an interruption in service integrity. The application's post-download validation mechanism relies on safe_check_model, which performs superficial format verification rather than cryptographic provenance checks. For ONNX models, this means any file adhering to the structural schema of a valid ONNX graph will pass inspection regardless of its actual content or origin. This allows an attacker to substitute a malicious model that appears structurally correct but contains embedded logic designed to manipulate inference results, effectively hijacking the application's annotation capabilities by feeding it poisoned data that produces specific, attacker-controlled outputs rather than accurate object detection or segmentation labels.
The severity escalates significantly for PyTorch-based models such as SAM2 video, YOLOE, UPN, and open_vision configurations, where the vulnerability transitions from a logic manipulation issue to arbitrary code execution. The check worker invokes torch.load on these files without setting weights_only=True in older versions of the library. In PyTorch releases predating the enforcement of this safety default, pickle deserialization is inherently unsafe because it allows for the instantiation of arbitrary Python objects during unpickling. An attacker who intercepts the connection can serve a crafted .pth or .pt file containing malicious pickle payloads that execute system commands, exfiltrate data, or establish reverse shells upon loading. This transforms the vulnerability from a simple integrity violation into a full remote code execution vector with potentially high privileges depending on the user context running X-AnyLabeling.
From an industry standards perspective, this flaw aligns closely with CWE-295 Improper Certificate Validation and CWE-78 OS Command Injection via Unsafe Input when considering the PyTorch deserialization aspect. The lack of cryptographic verification for downloaded artifacts also relates to CWE-345 Insufficient Verification of Data Authenticity. In terms of attack vectors, this scenario maps directly to MITM attacks within the ATT&CK framework, specifically leveraging techniques related to network sniffing and credential access if sensitive data were transmitted alongside model weights. The failure to verify digital signatures or hashes before execution constitutes a classic supply chain compromise at the application level, where trust is placed in the transport layer without verifying the payload integrity.
Mitigation strategies must address both the transport security gap and the artifact validation process immediately. Developers should replace ssl._create_unverified_context() with standard SSL context creation that enforces certificate verification against trusted root CAs to prevent man-in-the-middle interception. Furthermore, it is imperative to implement cryptographic integrity checks by downloading a corresponding signature file or hash list from a secure channel and verifying the downloaded model files before they are loaded into memory. For PyTorch models, upgrading to versions where weights_only=True is the default behavior for torch.load is essential to prevent arbitrary code execution during deserialization. Until these patches are applied, users should avoid using X-AnyLabeling on untrusted networks or consider manually downloading verified models from official sources and loading them directly rather than relying on the automated downloader feature.