⚛️ quantum physics

Broken Quantum: A Systematic Formal Verification Study of Security Vulnerabilities Across the Open-Source Quantum Computing Simulator Ecosystem

This paper presents "Broken Quantum," the first comprehensive formal security audit of 45 open-source quantum computing simulators using the COBALT QAI engine and Z3 solver, which identified 547 critical vulnerabilities including a novel quantum-specific attack vector and documented the first supply chain vulnerability transfer from a commercial framework to US national laboratory infrastructure.

Original authors: Dominik Blain

Published 2026-04-09

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Dominik Blain

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of quantum computing as a massive, high-stakes construction project. Before engineers can build the actual quantum skyscrapers (the physical quantum computers), they need to design and test the blueprints on a computer. These "blueprint testers" are called Quantum Simulators. They are the software that lets scientists pretend they have a quantum computer, so they can figure out if their ideas work before spending millions on real hardware.

This paper, titled "Broken Quantum," is like a massive, systematic home inspection of the 45 most popular blueprint testers used by the world's biggest tech giants (IBM, Google, Amazon), top universities (Harvard, MIT), and national labs.

The inspector, Dominik Blain, found that 80% of these simulators are dangerously broken. Here is the breakdown in simple terms:

1. The Core Problem: The "Exponential Explosion"

The fundamental issue is how quantum computers work. If you have 1 qubit (a quantum bit), the computer needs to track 2 numbers. If you have 2 qubits, it needs 4 numbers. If you have 10, it needs 1,024.

The Analogy: Imagine a recipe that doubles in size every time you add one more ingredient.
- 1 ingredient = 1 page.
- 10 ingredients = 1,000 pages.
- 50 ingredients = 8 Petabytes (that's 8 million gigabytes).
The Flaw: Most of these simulators ask the user, "How many ingredients do you want?" and then immediately try to print the recipe. If a user (or a hacker) says "50," the computer tries to allocate 8 Petabytes of memory instantly. Since no computer has that much RAM, the system crashes. This is a Denial of Service attack: "I asked for too much, so your computer died."

2. The Four Types of "Broken" Simulators

The paper categorizes the bugs into four distinct "flavors" of disaster:

Class I: The "Memory Crash" (C++ Backends)

Who: IBM's Qiskit Aer and Oak Ridge National Lab's XACC.
The Metaphor: Imagine a librarian who has a shelf with exactly 64 slots. If you ask for book #65, the librarian doesn't say "No." Instead, they reach off the shelf into the wall, grab a random piece of dust, and try to put it in a book slot.
The Result: In computer code (C++), this is called "Undefined Behavior." It can corrupt the memory, crash the program, or even let a hacker take control of the computer.
The Supply Chain Shock: The Oak Ridge National Lab (a US government facility) was found to have copied IBM's code word-for-word. So, when IBM's code was broken, the National Lab's code was broken too, without them even knowing.

Class II: The "Resource Starvation" (Python Backends)

Who: Google's Cirq, Xanadu's PennyLane, Harvard's Tequila, and many others.
The Metaphor: This is the "Recipe Explosion" mentioned above. The software doesn't crash because of bad memory access; it crashes because it tries to eat the whole kitchen.
The Result: If you ask for a 50-qubit simulation, the software tries to allocate 8 Petabytes of RAM. Your computer runs out of memory, the operating system kills the process, and the server goes down. This is an easy way for a hacker to shut down a quantum cloud service.

Class III: The "Trojan Horse" (Deserialization)

Who: Harvard's Tequila, Tencent's TensorCircuit, and others.
The Metaphor: Imagine you receive a sealed envelope from a friend that says, "This is a list of your favorite recipes." You open it, and instead of a list, it's a bomb that explodes in your face.
The Result: Many simulators use a feature called pickle or eval to load saved data. These tools are like "magic keys" that can run any code inside the file. If a hacker sends a fake "saved quantum state" file, it can execute malicious code on your computer, stealing data or taking over the machine. The paper even demonstrated a live "Proof of Concept" where they hacked a Harvard framework just by sending a fake file.

Class IV: The "Quantum Injection" (QASM Injection)

Who: IBM's Qiskit Terra, Quantinuum's tket.
The Metaphor: This is a new type of bug that only exists in quantum computing. Imagine a form where you write instructions for a robot. Usually, you write "Move forward." But because the form doesn't check your handwriting, you can write "Move forward, then delete all my files."
The Result: The software accepts a string of code (QASM) meant to describe a quantum circuit. Because it doesn't sanitize the input, a hacker can inject extra, malicious commands into the circuit instructions.

3. The "32-Qubit" Danger Zone

The researchers found a specific number that keeps popping up: 32.

In the C++ world, 32 is the point where calculations start to overflow and break the math.
In the Python world, 32 is the point where the memory required becomes so huge it breaks the system.
Why it matters: 32 qubits is a very common size for current research. It means the most popular experiments are happening right in the "danger zone" where these bugs are most likely to trigger.

4. The Good News

Not everyone failed the test.

The "A-List" Students: Frameworks from ETH Zurich (qpp), Oxford (QuEST), Fujitsu (qulacs), and Huawei (MindQuantum) scored 100/100.
Why? They simply checked the user's input before doing anything. They said, "You asked for 50 qubits? Sorry, the maximum is 30. Please try again."
The Lesson: These vulnerabilities aren't unavoidable physics problems; they are just bad coding habits. If you check your math before you build, you don't break the house.

Summary

This paper is a wake-up call. The entire foundation of the quantum computing revolution—the software used to design the future—is currently held together with duct tape and hope.

IBM, Google, and Harvard have critical security holes.
Hackers could crash servers, steal data, or take over computers just by sending a few lines of code.
The Fix: It's surprisingly simple. Developers just need to add a "speed limit" (input validation) to stop users from asking for impossible amounts of resources.

The author has released a free tool called COBALT QAI to help developers find and fix these bugs before the quantum era fully arrives.

1. Problem Statement

Quantum computing simulators form the classical software foundation for virtually all quantum algorithm research, development, and benchmarking. Despite their critical role in the infrastructure of governments, universities, and corporations, the classical security of these simulator implementations has never been systematically analyzed.

The core architectural vulnerability stems from the intrinsic nature of quantum simulation: an $n$ -qubit quantum state requires $2^n$ classical resources (amplitudes or matrix elements). This exponential scaling creates a unique attack surface where user-controlled qubit counts ( $n$ ), if unvalidated, lead to:

Memory Corruption: In C++ backends, leading to undefined behavior and heap corruption.
Resource Exhaustion: In Python backends, leading to denial-of-service (DoS) via massive memory/CPU allocation.
Code Injection: Through unsafe deserialization and novel quantum-specific injection vectors.

2. Methodology

The authors conducted the first comprehensive formal security audit of the open-source quantum simulator ecosystem using a custom toolchain named COBALT QAI.

Scope: 45 open-source frameworks from 22 organizations across 12 countries (including IBM, Google, Amazon, NVIDIA, CERN, Harvard, and national labs).
Tooling:
- Pattern Scanning: Two custom scanners (cobalt_qai_scanner.py for C++ and Python) utilizing regex matching against known vulnerability patterns.
- Formal Verification: A four-module static analysis engine backed by the Z3 SMT solver. Each candidate finding was encoded as a bitvector arithmetic constraint. A SAT result with a concrete witness established formal reachability; UNSAT established infeasibility.
Scoring: Frameworks were graded on a 100-point scale (100 = Secure, <30 = Broken) based on the severity of findings (CRITICAL, HIGH, MEDIUM).
Validation: All findings were verified via Z3 proofs (13/13 patterns confirmed SAT) and live Proof-of-Concept (PoC) exploits.

3. Key Contributions

First Ecosystem Audit: The largest formal security analysis of quantum software to date, covering 45 frameworks.
Four-Class Vulnerability Taxonomy: Identification of four distinct vulnerability classes, including a novel quantum-specific class.
Formal Verification: 13/13 Z3 SAT proofs formally establishing the reachability of all identified vulnerability patterns.
Supply Chain Discovery: The first documented case of a commercial framework vulnerability (IBM) propagating silently into US National Laboratory infrastructure (Oak Ridge NL) via code vendoring.
Live Exploits: Demonstrated working PoCs for Remote Code Execution (RCE), Denial-of-Service (DoS), and Integer Overflow chains.
Open Source Tools: Release of the COBALT QAI scanners for continuous security analysis.

4. Key Results & Findings

The study identified 547 total security findings (40 CRITICAL, 492 HIGH, 15 MEDIUM). 80% of the ecosystem (36 of 45 frameworks) exhibited at least one vulnerability.

Vulnerability Class I: C++ Memory Corruption (CWE-125/190)

Affected: C++ backends (Qiskit Aer, XACC).
Mechanism: Unvalidated qubit counts cause out-of-bounds array access (BITS[num_qubits]) or integer overflows in shift operations (1ULL << n).
Critical Finding: The 32-qubit boundary. A 32-qubit unitary simulation triggers a chain where $n < 64$ (safe input) becomes $2n = 64$ (overflow), causing BITS[64] out-of-bounds access.
Impact: Undefined behavior, heap corruption, and potential code execution.
Notable: XACC (Oak Ridge National Laboratory) was found to vendor the exact vulnerable Qiskit Aer C++ code verbatim, inheriting 5 CRITICAL and 60 HIGH findings.

Vulnerability Class II: Python Resource Exhaustion (CWE-400)

Affected: 14 Python frameworks (Cirq, PennyLane, qibo, etc.).
Mechanism: Unvalidated calls to np.zeros(2**num_qubits) or range(2**num_qubits).
Impact:
- Local: Process crashes (OOM) or CPU exhaustion.
- Cloud: Remote Denial-of-Service (DoS).
Example: np.zeros(2**50) attempts to allocate 8 Petabytes of RAM.
Score: Major frameworks like Cirq, PennyLane, and qibo scored 0/100 (Broken).

Vulnerability Class III: Unsafe Deserialization & Code Injection (CWE-502/94)

Affected: Serialization logic in Python frameworks.
Mechanism: Use of pickle.load(), dill.load(), eval(), or torch.load() without integrity checks.
Critical Finding: Harvard's tequila contains 10 direct pickle.load() calls in its fermionic methods. A malicious .pkl file can trigger immediate Remote Code Execution (RCE).
PoC: The authors demonstrated a live RCE attack vector replicating the tequila exploit.
Other Findings: TensorCircuit (Tencent) and PySCF (Quantum Chemistry) were found to use eval() and unsafe deserialization.

Vulnerability Class IV: QASM Injection (CWE-77/22)

Novelty: A quantum-specific attack vector with no classical analog.
Mechanism: User-controlled data embedded in OpenQASM strings reaches parsers without sanitization.
Impact: Attackers can inject malicious gate definitions, traverse file systems via include directives, or exploit QASM 3's classical control flow to call arbitrary C functions.
Affected: Qiskit Terra (2 unsanitized public APIs), tket (Quantinuum), and others.

Hardware Control Layer

The study extended to hardware control software (e.g., scqubits, qua-tools), finding critical deserialization vulnerabilities that could compromise physical quantum processor calibration and pulse parameters.

5. Significance & Implications

Systemic Failure: The "32-qubit boundary" and the ubiquity of the np.zeros(2**n) pattern across 14 independent organizations indicate a systemic gap in quantum software security norms. The community lacks established standards for qubit count validation.
Supply Chain Risk: The discovery that a US National Laboratory (Oak Ridge) inherits vulnerabilities from a commercial vendor (IBM) via code vendoring highlights a critical blind spot in scientific infrastructure security.
Preventability: The study proves these vulnerabilities are avoidable. 9 frameworks (including qpp, QuEST, qulacs, and MindQuantum) scored 100/100 by implementing proper input validation at API entry points.
Actionable Recommendations:
- Universal Guard: Enforce a maximum qubit count (e.g., 50 for statevectors, 25 for density matrices) at every public API entry.
- C++ Fixes: Add bounds checks before array access and shift operations.
- Serialization: Replace pickle/dill with safe alternatives or enforce strict integrity checks.
- QASM: Sanitize all QASM input strings and restrict include paths.

Conclusion

"Broken Quantum" reveals that the classical software underpinning the quantum revolution is critically insecure. The exponential nature of quantum states, combined with a lack of input validation norms, has created a landscape where memory corruption, DoS, and RCE are pervasive. The authors call for an ecosystem-level intervention to establish security standards, noting that while the vulnerabilities are severe, they are technically straightforward to fix, as demonstrated by the secure frameworks in the study. Coordinated disclosure with 20 organizations is underway.