SP1——Succinct的零知识证明系统——中的一个高危健全性漏洞，使该公司自己的主网Prover Network暴露于无效证明风险。SP1是一个零知识虚拟机(zkVM),旨在让开发者无需重新运行程序即可证明程序的正确执行，而健全性——即验证器只接受确实如所述发生的执行的证明这一保证——是所有基于此类证明构建的应用所依赖的核心属性。根据10月11日发布的一份GitHub安全公告,Prover Network是Succinct已知的唯一受影响部署。

该公告编号为GHSA-p7v2-jjv3-8p8f,指出恶意证明者可以提交无效执行的证明，而网络的验证器会接受它。Prover Network接受来自第三方证明者的证明，这意味着其验证器必须将每一次提交都视为潜在的恶意行为——这使得该漏洞与网络的运行直接相关，因为健全的验证正是区分真实工作与伪造结果的关键。

利用仅限于原生Rust验证器路径

只有当证明直接发送至SP1的原生Rust验证器时，该漏洞才可被利用。Core和Compressed证明在该路径上暴露。

Groth16和Plonk检查未受影响，因为它们依赖形状固定的包装证明，且从不触及问题核心的证明者可控张量格式。用于链上Plonk和Groth16验证的Solidity检查器同样安全。调用verify_sp1_proof函数验证Compressed证明的应用，只有在证明聚合最终以Groth16或Plonk证明结尾时才受到保护。

根据公告，sp1_hypercube、sp1_prover和sp1_sdk的6.0.0至6.8.0版本受影响。Succinct于9月24日在6.8.1版本中发布修复，比公告公开早17天，随后将其部署至主网Prover Network——这一时间安排意味着在漏洞技术细节公开之前，可用的修复方案已经就绪。

张量标签不匹配未被检查

该漏洞存在于SP1的原生Rust验证器中，即负责判定证明是否有效的组件。

SP1将多维数据存储在称为Tensor的结构中。Tensor由一个存储值的缓冲区和描述其形状的声明维度组成，两者必须一致才能实现健全的验证：存储元素的数量必须等于声明维度的乘积。

每条证明数据都带有指示其大小的标签，但验证器从未确认标签与实际内容相符，仅查看标签。因此，攻击者可以提交带有伪造标签的数据。验证的不同部分随后会读取同一缓冲区的不同区段，这意味着伪造的证明可能通过验证。

6.8.1版本在反序列化过程中引入了长度检查。任何存储元素数量不等于其声明维度乘积的张量都会被拒绝。

谁需要升级

从主网Prover Network请求证明的用户无需在其端做任何更改。运行自己的原生Rust验证器并接受来自其不信任的证明者的证明的运营者必须升级至6.8.1。由于Succinct的公告只能涵盖其已知的部署，自托管的运营者需要对照公告中受影响版本的列表，自行检查其配置是否处于受影响范围内。

披露及相关事件

根据公告，Vitalis Salis发现了该漏洞，并通过Immunefi的漏洞赏金计划进行了报告。

此次披露是今年报告的一系列证明系统健全性问题中的最新一起。Cryptopolitan此前报道过Zcash的chard屏蔽池中的健全性漏洞以及Foom.Cash遭遇的一起攻击事件,后者中攻击者因验证器配置错误而伪造了zkSNARK证明。