CVE-2026-112304 in docTR
Summary
by MITRE • 10/19/2026
docTR through 1.1.0 contains an unsafe deserialization vulnerability in load_pretrained_params() that loads checkpoints with torch.load without weights_only=True. Attackers who control a local or URL-supplied checkpoint can embed a malicious pickle payload to execute Python code with the loading process's privileges on torch releases before 2.6.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The docTR library, specifically through version 1.1.0, contains an unsafe deserialization vulnerability within its load_pretrained_params function that allows for arbitrary code execution under specific conditions. This flaw stems from the use of PyTorch's torch.load method to deserialize model checkpoint files without enforcing strict safety constraints such as setting weights_only=True or restricting unpickling operations. In versions of PyTorch prior to 2.6, this configuration permits the loading process to execute arbitrary Python code embedded within maliciously crafted pickle payloads contained in the checkpoint file. The vulnerability is particularly dangerous because it targets a common workflow where developers and users load pre-trained models from local directories or remote URLs without sufficient validation of the source integrity.
From a technical perspective, the core issue lies in how PyTorch handles serialization formats during model loading. When torch.load is invoked on a checkpoint file that contains serialized Python objects rather than pure tensor data, it invokes Python's pickle module to reconstruct these objects. If an attacker controls the content of this checkpoint file, they can inject malicious code into the pickled object structure. Upon execution by the vulnerable load_pretrained_params function, this injected code runs with the same privileges as the user or service executing the script. This effectively bypasses any sandboxing mechanisms that might otherwise protect the system from untrusted input processing during model initialization phases.
The operational impact of this vulnerability is severe, particularly in environments where models are loaded from external sources such as public repositories, shared drives, or third-party services. An attacker who can supply a malicious checkpoint file to an unsuspecting user can achieve remote code execution on the victim's machine. This could lead to full system compromise, data exfiltration, lateral movement within internal networks if the compromised host is part of a larger infrastructure, and potential denial of service through resource exhaustion or destructive commands. The risk is amplified in automated pipelines where models are downloaded from unverified sources as part of continuous integration or deployment processes without manual inspection of file contents.
This vulnerability aligns with Common Weakness Enumeration category CWE-502, which describes deserialization of untrusted data. It also maps to MITRE ATT&CK technique T1648, specifically the Leverage Serverless Execution sub-technique if exploited in cloud environments where model loading occurs within serverless functions or containerized workloads. Additionally, it relates to CWE-94 for improper control of generation code since the vulnerability allows injection and execution of arbitrary Python scripts during normal library operations.
Mitigation strategies should focus on both immediate remediation and long-term defensive practices. The primary fix involves updating PyTorch to version 2.6 or later where safer default behaviors are enforced, although relying solely on framework updates may not be sufficient if older versions remain in use within legacy systems. For existing deployments, developers must ensure that any checkpoint files loaded via torch.load originate from trusted sources and have been verified for integrity using cryptographic hashes such as SHA-256 before loading. Implementing strict input validation to reject non-tensor data types during deserialization can also reduce exposure. Organizations should audit their codebases for similar patterns of unsafe deserialization across other libraries that rely on pickle-based serialization formats, ensuring consistent application of security best practices throughout the machine learning pipeline lifecycle.