- The paper conducts a formal verification using the COBALT QAI pipeline to identify 547 vulnerabilities across 45 quantum computing frameworks, exposing systemic security flaws.
- The analysis reveals critical issues such as unchecked exponential memory allocations in C++ and Python, leading to memory corruption, resource exhaustion, and code injection.
- The study highlights supply chain risks and advocates for strict input validation and secure coding practices to protect research and national infrastructure.
Overview and Motivation
The paper "Broken Quantum: A Systematic Formal Verification Study of Security Vulnerabilities Across the Open-Source Quantum Computing Simulator Ecosystem" (2604.06712) presents an extensive formal security audit of 45 open-source quantum computing simulation and hardware control frameworks spanning 22 organizations and 12 countries. Utilizing the COBALT QAI static analysis engine, powered by the Z3 SMT solver, the work performs static analysis and formal verification across C++ and Python codebases, as well as hardware abstraction layers, illuminating systemic security weaknesses that have hitherto received scant attention in quantum software.
The study addresses both the scientific and practical significance of these simulators—the foundational infrastructure underpinning quantum algorithm development, validation, and benchmarking in academia, industry, and government. The findings are positioned as urgent for the quantum community, revealing a lack of basic input validation and other security controls, resulting in vulnerabilities with high exploitability and broad risk propagation, including into US national laboratory infrastructure.
The methodology employs a hybrid static analysis and formal verification pipeline:
- Pattern-based static scanning searches for code constructs indicative of vulnerability using custom Python modules targeting C++ (CWE-125/190), Python exponential resource exhaustion (CWE-400), and deserialization/circuit code injection (CWE-502/94, CWE-77).
- Z3-based SMT modeling encodes each candidate pattern into arithmetic or reachability constraints, yielding SAT (vulnerability is reachable/exploitable) or UNSAT (unreachable) results with concrete witness values.
- Scoring penalizes frameworks by severity-weighted findings, establishing grades from "Secure" to "Broken."
Formal scope includes source-available code as of April 2026. Cloud API gateways and proprietary SaaS implementations are excluded where not open-sourced.
Main Vulnerability Classes and Empirical Results
The analysis identifies four primary vulnerability classes affecting roughly 80% of ecosystem frameworks:
- Class I: C++ Memory Corruption (CWE-125/190)
- Notably, XACC vendors the entirety of Qiskit Aer C++ code, inheriting all critical vulnerabilities—a concrete case of vulnerability supply chain propagation into US national laboratory computing.
- Class II: Python Resource Exhaustion (CWE-400)
- DoS attacks are directly demonstrated, and warnings (as in PennyLane) are insufficient, since execution is not halted.
- Class III: Unsafe Deserialization/Code Injection (CWE-502/94)
- The Harvard tequila package is shown to allow full RCE at 10 pickle.load() call sites; TensorCircuit (Tencent) and OpenFermion (Google) are also highlighted for nested code injection vectors.
- Class IV: QASM Injection (CWE-77/22, Quantum-specific)
Arbitrary user input reaches OpenQASM or QASM3 parsers in frameworks like Qiskit Terra (IBM), tket (Quantinuum), and others, enabling code and register injection, path traversal, and external file includes unique to quantum software.
Among 547 total findings (40 CRITICAL, 492 HIGH, 15 MEDIUM), only nine frameworks are free of all detected vulnerability classes. Numerical highlights:
- Qiskit Aer, Cirq, PennyLane, and qibo each scored 0/100 ("Broken"), totaling hundreds of CRITICAL/HIGH vulnerabilities.
- The 32-qubit boundary emerges as the formal threshold for both C++ and Python vulnerability reachability.
Supply Chain and Ecosystem Analysis
The study documents four vulnerability propagation chains, including:
- Code vendoring:
- XACC (Oak Ridge NL) copies Qiskit Aer’s C++ code, propagating vulnerabilities to several national labs without independent detection, due to the code residing in vendor directories outside typical scan targets.
- Independent replication:
The np.zeros(2**n) pattern is independently reimplemented by at least 14 organizations, demonstrating a systemic lack of awareness and preventive norms in the quantum community.
- Application layer propagation:
PySCF, the most widely used quantum chemistry library, exposes arbitrary eval() vectors that are reachable transitively via higher-level frameworks including Qiskit Nature, OpenFermion, and tequila.
Implications and Recommendations
Theoretical and practical implications are considerable:
- The vulnerabilities identified are not esoteric edge cases but result from the fundamental exponential scaling of quantum state representations combined with unvalidated external input.
- Quantum software shares risks akin to traditional scientific/HPC workflows but also manifests domain-specific threats (e.g., QASM injection).
- Insecure simulators and libraries can subvert scientific integrity, open vectors for denial-of-service/ransom across research infrastructure, and—in the case of hardware control layers—present risks to the operation of physical quantum hardware.
Key recommendations:
- All frameworks should enforce maximal qubit count validation at every API entry point—backwards mitigation via hard-coded upper limits on num_qubits.
- C++ backends must implement strict bounds checks before exponential bit-shifts or array indexing.
- Warnings (as in PennyLane) must be upgraded to hard errors.
- Supply chain management is essential—vendored code must be tracked and synchronized with upstream security patches.
- Quantum software documentation, style guides, and tutorials should teach secure exponential allocation by default.
- Automated linter and scanner tools like COBALT QAI should be integrated into CI/CD pipelines.
These measures are empirically shown to be tractable, as 9 frameworks achieved perfect scores, validating that security is achievable without architectural overhaul.
Future Developments
Anticipated next steps include:
- Development and ecosystem-wide adoption of automated static and formal analysis tools for quantum simulation and hardware software.
- Establishment of global MAX_QUBITS and MAX_QUBITS_DENSITY_MATRIX standards, with enforcement in all major frameworks and cloud APIs.
- Expansion of quantum-specific input validation, especially at QASM and hardware abstraction layers.
- Systematic review and refactoring of dependency and vendored code management practices in quantum open-source projects.
- Greater attention to quantum supply chain security, including CVE tracking and transparency for scientific/research applications.
- Broader integration of formal verification (e.g., SMT, model checking) in scientific software engineering, especially for rapidly evolving domains like quantum computing.
Conclusion
This work establishes, with formal rigor and comprehensive empirical coverage, that security vulnerabilities are endemic in open-source quantum simulation infrastructures. The problems are rooted in both architectural features of quantum computation and avoidable omissions in software engineering practice. Numerical results, live demonstrations of RCE and DoS, and documented supply chain propagation emphasize the urgency of adopting basic validation and security hygiene across quantum frameworks.
Correctable with tractable measures, but presently systemic, these vulnerabilities challenge the community to respond at an ecosystem level. Automated formal security analysis, supply chain vigilance, and adoption of secure-by-default patterns are necessary to safeguard both classical and quantum-era computational science.
