CVE-2026-7584: Zhinst Labone Q RCE Vulnerability

CVE-2026-7584 Overview

CVE-2026-7584 is an insecure deserialization vulnerability [CWE-502] in the Zhinst LabOne Q quantum computing software framework. The flaw resides in the serialization framework's import_cls class-loading mechanism, which dynamically imports and instantiates Python classes during deserialization. The mechanism accepts arbitrary fully-qualified class names from serialized data without validating the target class or restricting which modules can be imported.

An attacker can craft a malicious experiment file that triggers instantiation of arbitrary Python classes with attacker-controlled constructor arguments. Successful exploitation results in arbitrary code execution under the privileges of the user running the Python process.

Critical Impact
Loading a crafted LabOne Q experiment file shared for collaboration or support purposes results in arbitrary code execution in the victim's Python environment.

Affected Products

Zhinst LabOne Q (versions prior to the fix)
Zhinst LabOne Q 26.4.0 beta1 through beta5
Component identifier: zhinst:labone_q

Discovery Timeline

2026-05-01 - CVE-2026-7584 published to NVD
2026-05-04 - Last updated in NVD database

Technical Details for CVE-2026-7584

Vulnerability Analysis

The LabOne Q serialization framework deserializes experiment files that contain references to Python classes by their fully-qualified names. During deserialization, the import_cls helper resolves these names, imports the corresponding modules, and instantiates the class with constructor arguments drawn from the serialized payload.

Because the framework performs no allow-list check on the target class and no restriction on the module namespace, any importable Python class becomes a candidate for instantiation. Constructor arguments are also taken directly from the serialized data, giving the attacker control over both the gadget chain and its parameters. The vulnerability is categorized as deserialization of untrusted data [CWE-502].

Root Cause

The root cause is the absence of validation in the dynamic class-loading routine. The deserializer trusts the embedded class identifier and constructor argument tuple without enforcing a whitelist of permitted classes, a sandbox boundary, or a schema. Any Python module reachable on the interpreter's sys.path can be loaded, including modules whose constructors trigger side effects such as subprocess.Popen or os.system.

Attack Vector

Exploitation requires user interaction. A victim must open a crafted experiment file using LabOne Q's deserialization functions. Realistic delivery scenarios include experiment files shared for collaboration, files distributed through support channels, or files retrieved from compromised internal repositories. The attack vector is local because the malicious file must be processed by the victim's Python interpreter.

Upon load, the deserializer resolves the attacker-supplied class name, imports the module, and invokes the constructor with the embedded arguments. This yields arbitrary code execution within the user's session, leading to high impact on confidentiality, integrity, and availability of the local system.

The vulnerability mechanism follows the classic Python deserialization gadget pattern. See the ZHI Security Advisory 2026-002 for vendor technical details.

Detection Methods for CVE-2026-7584

Indicators of Compromise

Unexpected child processes spawned by the Python interpreter hosting LabOne Q, particularly shells, curl, wget, or scripting hosts.
LabOne Q experiment files received from external or untrusted sources, especially those modified outside expected collaboration workflows.
Outbound network connections initiated by the Python process shortly after an experiment file is opened.
Filesystem writes by the LabOne Q process to directories outside its working data paths.

Detection Strategies

Inspect serialized LabOne Q experiment files for class references that point to modules outside the laboneq package namespace.
Hunt for process trees in which python or LabOne Q workflows spawn cmd.exe, powershell.exe, /bin/sh, or bash.
Alert on Python processes loading sensitive modules such as subprocess, socket, or ctypes immediately after a file-open event in research workstation telemetry.

Monitoring Recommendations

Enable command-line and process-creation auditing on workstations and lab systems running LabOne Q.
Centralize Python interpreter telemetry, including loaded modules and child processes, in a SIEM for correlation against experiment file activity.
Track ingress of .qcdata, .json, or other LabOne Q experiment artifacts from email, chat, and shared drives.

How to Mitigate CVE-2026-7584

Immediate Actions Required

Upgrade LabOne Q to a fixed release as identified in ZHI Security Advisory 2026-002.
Stop opening experiment files received from untrusted or unverified sources until the patch is deployed.
Inventory systems running affected LabOne Q versions, including the 26.4.0 beta1 through beta5 builds, and prioritize them for remediation.
Restrict write access to shared directories that store LabOne Q experiment files to reduce tampering risk.

Patch Information

Zurich Instruments has published a fix in ZHI Security Advisory 2026-002. The fix introduces validation in the import_cls class-loading mechanism so that only approved classes within the LabOne Q namespace can be instantiated during deserialization. Apply the vendor-supplied update on every host that loads LabOne Q experiment files.

Workarounds

Open experiment files only inside isolated, non-privileged user accounts or disposable virtual machines until the patch is applied.
Validate the origin and integrity of experiment files using out-of-band channels before loading them.
Run LabOne Q under a constrained Python environment with minimal third-party packages on sys.path to limit available gadget classes.
Block experiment files from arriving over untrusted email or external file-sharing services through email gateway and DLP rules.

bash

# Verify installed LabOne Q version and upgrade to the fixed release
pip show laboneq | grep -i version
pip install --upgrade laboneq