量子计算，这个动辄融资金额以亿计算的赛道里，谷歌、IBM等巨头一直在较量谁的量子计算系统量子比特保真度更高，相干时间更长。

但大多数人不知道的是，在这些充满科幻感的物理硬件背后，支撑整个量子算法研究的，其实是跑在经典计算机上的“量子模拟器软件”。

在今天，几乎所有的量子算法研发、新药模拟和金融模型，实际上都跑在传统的经典计算机上。物理学家们是用经典代码写出来的量子电路模拟框架，来预测和验证量子硬件的行为。

可以说，这些开源的模拟器框架，就是整个量子计算大厦的经典基础设施。

然而，就是这层被全球各大国家实验室、顶尖高校和科技巨头高度依赖的地基，最近被一份名为《Broken Quantum》的独立安全审计报告狠狠地敲碎了。

在对全球22家顶尖机构（包括IBM、谷歌、亚马逊、百度、哈佛等）的45个开源量子模拟框架进行“体检”后，研究人员发现了整整547个安全漏洞，80%的框架全部沦陷，其中不乏直接能接管服务器的致命高危漏洞。

如果你以为这只是几个安全员用肉眼“扒开代码随便看看”，那就大错特错了。揪出这些漏洞的，是极其硬核的 COBALT QAI 静态分析引擎，背后还站着大名鼎鼎的 Z3 SMT 逻辑求解器。

研究团队直接把各大厂的代码转化成了数学约束，通过“形式化验证”，在数学逻辑上铁证如山地证明了：这些漏洞是100%可以被触发的。

01. 被忽视的指数爆炸

要理解这些漏洞有多离谱，我们得先纠正一个核心概念。

在模拟量子世界时，资源消耗是呈指数级爆炸的。物理学家们在代码里模拟一个 n 个量子比特的纯态（Statevector），需要用 2n 个复数振幅来表示；如果模拟更复杂的密度矩阵（Density Matrix），资源量直接飙升到 22n。这是量子力学叠加态的物理本质决定的，无可厚非。

那么，各大厂的开发者们（包括谷歌的Cirq、百度的paddle-quantum）是怎么在代码里实现这一点的呢？

他们在Python里写下了一句类似 np.zeros(2**n) 的内存分配代码。问题在于，他们完全没有对用户输入的参数n设置任何安全上限。

但从软件安全的视角来看，这简直是在服务器上放了个不设防的核按钮。因为Python的整数是没有上限的，如果有人（或者自动化脚本）在公共科研云平台上，把 n 设成了50，这行毫无保护的代码就会理直气壮地向操作系统索要 8 PB（也就是800万GB）的内存。

结果没有任何悬念：操作系统为了自保，会当场把这个进程“干掉”（OOM-kill），直接造成拒绝服务（DoS）攻击。连欧洲核子研究中心（CERN）部署在高能物理计算网格上的 qibo 框架，也因为这个底层的逻辑漏洞，暴露在了极其脆弱的风险之中。

02. 致命的32比特陷阱

如果说Python的崩溃还只是让机器宕机，那底层用C++写的模拟器（比如IBM的Qiskit Aer），画面就更惊悚了。

报告揭示了一个极其硬核且有趣的现象——“32比特边界”。

在学术界，32个量子比特是一个非常典型的研究门槛（比如常用于量子化学模拟），它刚好处于单台超级计算机能模拟的极限边缘。但这个数字，在计算机底层架构里却是一个“死亡陷阱”。

在C++中，整数溢出是不会报错的，它只会“默默发疯”。当物理学家们在做酉矩阵（Unitary Matrix）或密度矩阵模拟时，算法需要把输入的量子比特数翻倍。

于是，当你输入合理的 n=32 时，乘以2变成了64。在C++的64位计算体系下，264 会导致位移操作产生严重的越界访问甚至未定义行为。

这意味着，研究员只是输入了一个极其正常的科研参数，系统的内存指针就像脱缰的野马一样越界了，这不仅仅会让程序崩溃，甚至可能被黑客用来接管整个进程。

03. 直接控制服务器，甚至篡改物理硬件

看到这里，你可能会觉得：就算开源代码写得烂，巨头们在商业云服务（比如 IBM Quantum API）的外围网关加个拦截层，限制一下输入的量子比特数不就完了？

确实，云端的拦截勉强能防住内存耗尽。但如果我们仅仅停留在“忘记检查边界”这个层面，就严重低估了当前量子计算软件生态在工程上的“腐烂”程度。

真正让安全专家感到后背发凉的，是那些跟“量子比特数”毫无关系、深植于架构底层的灾难。

比如，量子研究员们需要经常保存和加载复杂的量子态数据。在这个环节，全球顶尖的高校和巨头们展现出了惊人的“门户大开”。

哈佛大学有个挺火的量子化学模拟框架叫 tequila，它的代码里竟然明晃晃地挂着10个 pickle.load() 调用。在安全圈，大家都知道这玩意儿是个直接执行任意代码的“定时炸弹”。

为了证明这不仅是理论风险，审计团队甚至现场手搓了一个仅仅341字节的伪造文件，研究员只要一加载这个文件，黑客就能瞬间拥有这台服务器的最高控制权。

更绝的是，底层支撑着谷歌和IBM大量业务的开源量子化学库 PySCF，它的开发者甚至直接对传入的分子结构字符串使用了 eval() 函数。这就相当于把自家金库的密码直接贴在了大门上，只要上传一个恶意的分子结构文件，整个系统就能瞬间沦陷。

此外，黑客还迎来了一种专属于量子世界的全新玩具——QASM注入。就像早期互联网时代的SQL注入一样，现在黑客可以通过在量子汇编指令（OpenQASM）里夹带私货，直接打穿量子编译器。这在传统经典计算里连个对照物都找不到。

更让人后怕的是，漏洞的触手已经从经典软件伸向了真实的物理量子计算机。用于控制真实超导量子硬件脉冲的底层工具（如芝加哥大学的 scqubits 和 Quantum Machines 的 qua-tools），同样被查出了极其危险的反序列化漏洞。

这意味着，黑客不仅仅能搞瘫模拟器，甚至有可能直接篡改真实物理量子处理器的校准数据和物理脉冲。这是从“软件危机”走向“物理破坏”的关键一步。

04. 国家级基建的代码搬运

如果说代码写得烂是能力问题，那盲目“抄袭”导致的病毒式传染，就是态度问题了。

美国能源部旗下的橡树岭国家实验室，搞了个叫XACC的框架，这可是背靠6.5亿美元政府投资、用在四个美国国家实验室里的科研基建。

但安全员扒开代码一看：好家伙，XACC里有5个最致命的C++漏洞，连代码带标点符号，全是从IBM的商业框架Qiskit那里原封不动复制粘贴（Vendoring）过来的。

这可以说是量子计算领域第一起被实锤的“商业漏洞传染给国家级基建”的供应链安全事件。

这种不加审计的盲目抄袭，让表面的修修补补变得毫无意义，有人在这头堵上了一个漏洞，那头又因为复制粘贴引入了十个雷。

05. 如何修补？

当然，这场大考并非全盘皆输。在被审计的 45 个框架中，牛津大学的 QuEST、富士通的 qulacs 以及华为的 MindQuantum 等9个框架拿了满分。它们用完美的表现证明了一件事：漏洞并非量子物理学不可逾越的障碍，而纯粹是工程实现问题。只要老老实实做好软件工程的安全规范，在 API 入口做好参数校验等，量子计算的漏洞是完全可以防护的。

根据《Broken Quantum》审计报告给出的官方整改建议，行业亟需在以下四个方面立刻“打补丁”：

一、通用建议：在 API 入口处验证 Qubit 计数

不论底层是Python还是C++，所有框架都必须在接受用户输入的源头强制建立拦截机制。报告建议直接硬编码设置上限：纯态模拟（Statevector）上限设为50个比特，密度矩阵（Density Matrix）模拟上限设为25个比特。任何超出这个物理极限的模拟请求，不要尝试计算，直接报错拦截。

二、 针对C++框架：补上救命的“边界检查”

像IBM和橡树岭国家实验室使用的C++底层框架，必须在分配内存（如操作 BITS[] 数组）或进行比特数翻倍之前，增加基础的 if 逻辑判断。只要发现用户输入的比特数 >= 64（或者在需要翻倍的场景下 >= 32），必须主动抛出 invalid_argument 异常，彻底封死内存越界和整数溢出的黑客后门。

三、把口头警告升级为错误

像Xanadu主导的PennyLane等框架，其实已经意识到了超大矩阵会耗尽资源，但他们仅仅在代码里写了一个“弱提示”（Warning：不推荐，将耗费很长时间），任由程序继续往下跑。建议所有团队必须将此类警告强制升级为阻断执行的错误，决不能把安全防线交给用户的自觉。

四、停止盲目抄袭，建立安全同步机制

对于XACC这种严重依赖外部代码库（Vendoring）的科研基建，必须立刻停止“抄完就不管”的陋习。团队必须建立安全追踪机制，时刻盯着上游（如IBM Qiskit Aer）的安全补丁并及时同步，避免让几十亿美元的科研基础设施裸露在已知商业漏洞的枪口之下。

《Broken Quantum》这份报告就像是一记响亮的耳光。它毫不留情地指出，在幻想着征服量子世界之前，地球上最聪明的物理学家们，是时候好好补一堂基础的软件工程安全课了。

毕竟，如果连支撑这一切的软件地基都千疮百孔，甚至连操控真实芯片的物理指令都能被轻易篡改，那我们盖再高的量子大厦，也终究只是一座一碰就碎的科幻泡影。

引用：

[1]https://arxiv.org/abs/2604.06712

[2]https://quantumzeitgeist.com/quantum-simulator-security-flaws/

声明：本文来自量子客，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。