Quantum Crosstalk as an Attack Surface

Abstract

Current IBM Quantum backends run jobs with exclusive device access by default, but the underlying superconducting architecture exhibits always-on ZZ-coupling between adjacent qubits — a physical channel that cannot be eliminated by software. This work demonstrates that a circuit designed to saturate a high-error CX boundary can degrade a co-located victim Grover search from a real-hardware baseline of ~62–63% P(correct) to as low as 21.8% — a reduction of up to 41.5 percentage points — on three IBM Heron r2 backends (ibm_torino, ibm_fez, ibm_marrakesh, 2026-03-17). Critically, all jobs returned error: null: the platform reported success while delivering corrupted results. Scope boundary: both victim and attacker circuits were submitted by the same researcher. IBM's Open Plan scheduler grants exclusive device access per job; true concurrent multi-user co-execution was neither forced nor confirmed. This work establishes the physical mechanism as a verifiable attack primitive — not a live cross-user exploit. A methodological caveat applies: the automatically selected attack boundaries had CX_err = 100% (dead qubit pairs), which may amplify degradation beyond what calibrated crosstalk boundaries would produce. Verifiable IBM Quantum job IDs are provided throughout.

01 — Background: The Physical Layer and Its Security Properties

Superconducting quantum processors operate at millikelvin temperatures, with qubits implemented as anharmonic oscillators (transmons) coupled via microwave resonators. IBM's Heron r2 generation — the hardware used in this work — fields 133- to 156-qubit processors. Under IBM's current Open Plan, each submitted job receives exclusive device access: jobs queue and execute sequentially, not concurrently. This is an important distinction from the classical cloud model where VM co-tenancy is the norm.

Even without true concurrent multi-tenancy today, three features of superconducting hardware make crosstalk a security-relevant concern. First, qubits are coupled by design — you cannot remove the coupling without removing the ability to perform two-qubit gates. Second, this coupling is always-on: ZZ-type interaction persists between neighboring transmons even when no gate is being applied. Third, as providers optimize QPU utilization, concurrent scheduling is a known engineering direction — meaning the exposure window can only grow. Decoherence channels relevant to this threat model are: T₁ (energy relaxation), T₂ (dephasing), and ZZ-type crosstalk, which is proportional to qubit frequency proximity and physical adjacency in the coupling map.

⚠

Threat Model (with scope boundary): An adversary with a legitimate IBM Quantum account can submit high-frequency gate sequences on a qubit zone adjacent to where a victim's circuit will run. If a future or alternative scheduler co-locates both jobs concurrently, the resulting ZZ-crosstalk shifts the effective Hamiltonian of victim qubits mid-computation, corrupting the quantum state without any access to the victim's circuit or output. This work demonstrates that the physical mechanism produces measurable degradation; it does not demonstrate exploitation of IBM's current production scheduler.

02 — Attack Mechanism

Crosstalk Induction via Adversarial Circuit Design

The coupling strength ξ (crosstalk coefficient) between two qubits depends on their transition frequencies ω_i and ω_j and the coupling element g_ij. In this experiment, the attacker circuit and victim circuit were submitted by the same researcher as sequential jobs on the same backend. The attacker qubits were placed adjacent to victim qubits in the device's coupling map, and the attack circuit was designed to maximize crosstalk injection by:

◈

Attack strategy: Saturate boundary qubits (shared between attacker and victim zones) with rapid X–Y–X–Y gate sequences at high shot count. The induced ZZ-interaction accumulates as a phase error φ_err = ∫ ξ(t) dt on victim qubits, effectively rotating them away from the target eigenstate.

Victim Circuit: 3-Qubit Grover Search

The victim runs a 3-qubit Grover algorithm targeting state |110⟩. Under ideal simulation, Grover achieves P(correct) ≈ 88% (1 iteration). On real Heron r2 hardware — before any attacker circuit is introduced — the baseline drops to ~62–63%, reflecting intrinsic device noise. With the attacker circuit active on adjacent boundary qubits, P(correct) falls to between 21.8% and 44.9% depending on the backend, representing degradation of 17.7 to 41.5 percentage points from the real-hardware baseline. The random-chance floor for 8 equally-likely states is 12.5%.

Attack boundary caveat: The attack boundary qubits were selected automatically by choosing the highest CX-error pair on each device. In all three backends, this yielded pairs with CX_err = 100% — effectively dead qubit links. The microwave pulses driving these non-functional CNOT gates inject cross-resonance energy into neighboring qubits even without producing valid gate operations. Observed degradation may therefore be amplified relative to what a calibrated, functional crosstalk boundary would produce. This is an acknowledged methodological limitation; validation on a working boundary pair is the next experimental step.

88% P(correct) — Ideal Simulation

~62–63% P(correct) — Real HW Baseline

21.8–44.9% P(correct) — Under Attack (Real HW)

3 Heron r2 Backends Validated

03 — Hardware Validation

Results were validated on three IBM Quantum Heron r2 backends on 2026-03-17, using the Qiskit Runtime Sampler primitive (8192 shots per job). The attack boundary was identified automatically by querying the CX/ECR error map via IBMBackend.properties() and selecting the highest-error adjacent pair. In all three cases the auto-selected boundary had CX_err = 100% — see caveat above.

A defining characteristic of the attack across all backends: the IBM Quantum API returned "error": null for every job. The platform reported nominal success while delivering results with substantially eroded correctness. No alert, no flag, no anomaly in the job metadata. The degradation is silent by design — not a gap in IBM's monitoring, but a consequence of the platform having no means to distinguish adversarial crosstalk from ordinary hardware noise in a single run.

✓

ibm_torino (Heron r2, 133q) · Victim qubits: q[25,24,23] · Attack boundary: q[35]↔q[44]
Victim job: d6spbovgtkcc73clrgj0 · P(|110⟩) = 62.2%
Attack job: d6spbp6sh9gc73dhq3hg · P(|110⟩) = 36.6% · Δ = −25.5pp

ibm_fez (Heron r2, 156q) · Victim qubits: q[17,7,6] · Attack boundary: q[27]↔q[28]
Victim job: d6spcaf90okc73esjd8g · P(|110⟩) = 63.3%
Attack job: d6spcamsh9gc73dhq440 · P(|110⟩) = 21.8% · Δ = −41.5pp

ibm_marrakesh (Heron r2, 156q) · Victim qubits: q[83,84,85] · Attack boundary: q[81]↔q[82]
Victim job: d6spcg3bjfas73fooht0 · P(|110⟩) = 62.6%
Attack job: d6spcgesh9gc73dhq4c0 · P(|110⟩) = 44.9% · Δ = −17.7pp

All job IDs are verifiable by anyone with an IBM Quantum account. API response: error: null on all six jobs.

04 — Defense Mechanisms Evaluated

Three mitigation strategies were evaluated using the ibm_hanoi noise model in simulation (AerSimulator). These results are simulation-only and have not been validated on real hardware. They illustrate directional tradeoffs, not operational guarantees.

◈

D1 — Circuit Separation: increasing the buffer radius between attacker and victim qubit zones. Simulation shows meaningful fidelity recovery (r=0: 25.2% → r=2: 52.0%), but with high variance at larger radii (r=3: ±14.1%) and significant qubit waste (~40% of a 27-qubit device at r=2). Directional improvement confirmed; not a solution.

D2 — Noise-Aware Qubit Allocation: greedy scoring of qubit placements by CX error contribution. The notebook's greedy allocator achieves +1.7pp improvement under active attack — a proof-of-concept only. The paper's full RL agent (trained on 500,000 circuits) achieves 0.49 → 0.92 fidelity; that result is not replicated here.

D3 — Spectator Qubit Detection: a sentinel qubit placed adjacent to the victim monitors for anomalous |1⟩ states mid-circuit, enabled by IBM Eagle/Heron mid-circuit measurement (not available at the original paper's publication time). Circuit-based simulation at xt=1.0: detection rate = 53%, but post-selection on "clean" shots does not recover accuracy (23.1% with post-selection vs. 24.4% without). At full attack strength, crosstalk is diffuse enough to contaminate all shots. Detection ≠ correction.

Summary: No tested mitigation fully neutralizes the effect under high-intensity attack conditions. D1 and D2 reduce exposure at the cost of resource efficiency. D3 reliably detects anomalous activity but cannot recover computation fidelity when the attack field is spatially diffuse. All three are engineering adaptations to a physical constraint — mitigations, not fixes.

05 — Live Interactive Demo

The panel below is a real-time simulation of the quantum crosstalk attack. The left column shows a 5-qubit segment of a Heron r2 coupling topology in 3D, with victim qubits (cyan), attacker qubits (red), and the boundary qubit (amber) highlighted. The center shows the measurement probability histogram — watch |110⟩ collapse as you launch the attack. This is an interactive simulation calibrated to real hardware noise parameters; it is not live hardware.

Quantum Crosstalk — Live Attack Panel

SIMULATION LIVE

Use the controls on the right panel to launch the attack, adjust intensity, and enable defenses.

OPEN FULLSCREEN ↗

06 — Implications and Contributions

This work demonstrates that ZZ-coupling in superconducting hardware is a physically inescapable noise amplification pathway that an adversary can leverage by deliberate circuit design. The key security-relevant finding is not that IBM's current scheduler is broken — it isn't — but that the physical substrate on which any concurrent scheduler would operate carries an inherent, unaddressable crosstalk channel. As QPU utilization pressure pushes providers toward true concurrent multi-tenancy, this channel becomes an active threat surface.

Three contributions extend beyond the baseline paper (Harper et al.): (1) an ATT&CK-Q taxonomy mapping crosstalk attack variants to a quantum-adapted MITRE ATT&CK-style framework; (2) a Spectator Qubit detection circuit leveraging mid-circuit measurement now available on Eagle/Heron — a capability that post-dates the original paper; and (3) a multi-backend replication across three Heron r2 devices on the same date, with verifiable job IDs and consistent degradation patterns, demonstrating that the effect is architecture-level rather than device-specific.

What this work does not claim: It does not demonstrate live exploitation of IBM's production scheduler. It does not characterize crosstalk on IonQ, Quantinuum, or other architectures. The gate efficiency analysis (GCEB) — comparing CX, SWAP, ECR attack strategies — yielded inconclusive simulation results; the "SWAP ≈ 3× CX" hypothesis from the literature remains unconfirmed and requires hardware-level validation with process tomography tools.

Responsible Disclosure: This work builds on published research (Harper et al.) that has already undergone peer review and disclosure processes. The experimental component uses only the researcher's own IBM Quantum account and job queue. No proprietary data or other users' computations were accessed. If this research is to be presented publicly, notification to IBM Quantum Security (security@us.ibm.com) prior to the talk is strongly recommended as a matter of professional practice.

References

[1] Harper, B. et al. — Crosstalk Suppression for Fault-Tolerant Quantum Error Correction with Pauli Measurements. IBM Quantum / peer-reviewed (basis for the attack model and defense strategies replicated in this work)

[2] Ash-Saki, A. et al. — Analysis of Crosstalk in NISQ Devices and Its Effect on Optimal Qubit Mapping. Proc. ACM International Conference on Computing Frontiers (2020)

[3] Niu, M. et al. — Effects of Crosstalk in Quantum Systems and Countermeasures. IEEE Access (2022)

[4] IBM Quantum — Qiskit Runtime: Sampler Primitive Documentation. docs.quantum.ibm.com

[5] Lino, J. — Toward a Formal Theory of Quantum Malware. Preprint, targeting QCNC 2027. USP / IDB (2025–2026)

[6] Hardware evidence: ibm_torino/fez/marrakesh job IDs documented in qvuln_2026_xtalk_001_evidence.json — verifiable via IBM Quantum account. Experiment date: 2026-03-17. All jobs returned error: null.