CVE-2026-62997 in kedro-plugins
Summary
by MITRE • 09/17/2026
Kedro-Datasets provides data connectors for Kedro. From version 5.0.0 until 9.5.0, kedro_datasets_experimental.pytorch.PyTorchDataset in kedro-datasets loads .pt model files with torch.load without enforcing weights_only=True, and user-supplied load_args are silently dropped. On PyTorch versions earlier than 2.6, a malicious pickle-backed model from an attacker-influenced shared registry, downloaded checkpoint, or partitioned external source can execute arbitrary code when a Kedro pipeline loads it. The issue affects only the opt-in kedro_datasets_experimental component and does not affect users who load only trusted files. This issue is fixed in version 9.5.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Kedro-Datasets, specifically within the PyTorchDataset implementation found in versions ranging from 5.0.0 to 9.5.0, represents a critical security flaw rooted in improper deserialization practices. The core technical issue lies in the use of Python's pickle module via torch.load without enforcing the weights_only=True parameter on PyTorch versions earlier than 2.6. Pickle is inherently unsafe for untrusted data because it allows arbitrary code execution during the unpickling process, as it can instantiate any class and execute its initialization methods. By failing to restrict deserialization to only weight tensors, the library inadvertently exposes users to remote code execution attacks when processing model files that have been tampered with or originate from unverified sources.
The operational impact of this vulnerability is severe for data science pipelines that rely on shared registries, downloaded checkpoints, or partitioned external datasets where source integrity cannot be guaranteed. An attacker who gains control over a shared registry or intercepts the download process can inject malicious payloads into .pt model files. When a Kedro pipeline loads such a compromised file using PyTorchDataset, the arbitrary code embedded in the pickle stream is executed with the privileges of the user running the pipeline. This could lead to full system compromise, data exfiltration, or lateral movement within the infrastructure hosting the machine learning workflows. The risk is particularly acute in collaborative environments where models are frequently exchanged between different teams or pulled from public repositories without rigorous verification processes.
Compounding this issue is the silent dropping of user-supplied load_args by PyTorchDataset during version 5.0.0 through 9.5.0. This behavior prevents users from passing security-conscious parameters, such as weights_only=True, even if they are aware of the vulnerability and attempt to mitigate it manually. The lack of transparency regarding dropped arguments means that defenses configured at the application level are effectively neutralized by the library's internal handling logic. This design flaw ensures that unless the underlying PyTorch version itself enforces safe defaults or the user upgrades to a patched version, there is no viable workaround within the affected Kedro-Datasets versions to secure the deserialization process against malicious inputs.
This vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, and falls under MITRE ATT&CK technique T1610, specifically related to Dumping or Modifying Machine Learning Models for adversarial purposes when combined with initial access vectors that allow file injection. The attack vector typically involves an attacker influencing the data source before it is consumed by the pipeline, leveraging the trust placed in model files as standard artifacts rather than executable code containers. To mitigate this risk, organizations must immediately upgrade to Kedro-Datasets version 9.5.0 or later, where the issue has been resolved. For environments unable to upgrade instantly, restricting access to shared registries and implementing strict integrity checks on all incoming .pt files are essential interim measures. Additionally, auditing pipeline configurations to ensure that only trusted sources are utilized can reduce the attack surface until a full patch deployment is completed across all affected systems.