CVE-2026-120833 in labbench
Summary
by MITRE • 11/03/2026
labbench before 0.46.1 contains a deserialization of untrusted data vulnerability in read() and read_relational() that passes any file with a .p or .pickle extension to pandas.read_pickle based on the extension alone. Attackers who supply a crafted data file or relational data archive can execute arbitrary code when a user loads it with these functions.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in LabBench versions prior to 0.46.1 represents a critical security flaw rooted in the insecure deserialization of untrusted data. This issue specifically affects the read() and read_relational() methods, which are designed to load serialized Python objects from disk or relational archives. The core technical failure lies in how these functions determine the file format for processing. Instead of validating the actual content structure or employing a more robust mechanism for type identification, the implementation relies exclusively on the file extension, specifically checking if it ends with .p or .pickle. This approach creates a significant trust boundary violation because an attacker can easily manipulate the filename to bypass any superficial checks while embedding malicious payloads within the data stream itself.
From a technical perspective, this vulnerability exploits the inherent dangers associated with Python's pickle module and similar serialization libraries like pandas.read_pickle. These modules are not designed to be secure against untrusted input; they allow for arbitrary object instantiation during the deserialization process. When an application loads a maliciously crafted .pickle file, it does not merely parse data but executes code defined within the serialized objects. An attacker who supplies a specially constructed data file or relational data archive can embed Python opcodes that trigger remote code execution upon loading. This means that any user interacting with LabBench and utilizing these specific functions to load external files is at risk of having their system compromised, potentially leading to full control over the host environment where the application runs.
The operational impact of this vulnerability is severe, as it directly facilitates Remote Code Execution (RCE). In scenarios where users are expected to share or import data from untrusted sources, such as community datasets, collaborative projects, or downloaded archives, the risk is amplified significantly. An adversary could distribute a seemingly legitimate dataset with a .pickle extension that contains exploit code targeting specific versions of pandas or Python itself. Once loaded by an unsuspecting user or automated system within LabBench, this payload executes immediately, bypassing traditional security controls that might rely on file type validation based solely on extensions. This aligns closely with CWE-502, which describes the deserialization of untrusted data as a distinct weakness category often leading to arbitrary code execution, and maps directly to MITRE ATT&CK techniques involving command and script interpretation or payload delivery through malicious files.
To mitigate this vulnerability, immediate action is required by upgrading LabBench to version 0.46.1 or later, where the developers have presumably addressed the insecure deserialization pattern. For environments that cannot immediately upgrade, mitigation strategies must focus on strict input validation and restricting file sources. Applications should never rely solely on file extensions for determining how to process data; instead, they should implement content-based verification or use safer serialization formats such as JSON or CSV where possible. Additionally, deploying sandboxing mechanisms can limit the blast radius of any potential exploitation by isolating the deserialization environment from critical system resources. Security teams should also audit existing codebases using these functions to ensure that no untrusted data is being processed without adequate safeguards in place before patching becomes feasible.