SP1 原生驗證漏洞已修補，6.8.1 版發布後主網完成更新

Succinct 的 SP1 V6 原生 Rust 驗證路徑發現漏洞，可能讓錯誤執行的證明通過驗證。Succinct 已修正漏洞，並為運行中的主網 Prover Network 套用修補程式。

Succinct 在 2026 年 10 月 11 日發布的安全公告中，將漏洞嚴重程度列為「高（High）」。受影響套件為 sp1_hypercube、sp1_prover 和 sp1_sdk，受影響版本為 6.0.0 至 6.8.0；修正版本為 6.8.1。

問題出在讀取證明資料時，程式沒有檢查張量的儲存元素數量，是否等於其宣告維度值的乘積。張量是容納多維資料的結構，儲存元素數量應與各維度值相乘的結果相符。

舊版驗證器未確認這兩個數值是否一致。部分驗證步驟會使用宣告的維度值，卻不重新核對儲存元素數量。因此，惡意證明者若提交不一致的張量，各步驟可能會處理同一張量的不同部分。

Succinct 表示，在這種情況下，錯誤執行的證明可能通過原生 Rust 驗證。這是對漏洞技術影響的說明；目前尚未確認公開的漏洞利用案例。

受影響對象是直接提交給有漏洞的原生 Rust 驗證器的 Core 與 Compressed 證明。透過這條路徑接收不可信外部證明者所提交證明的應用程式，可能受到漏洞影響。

漏洞發現時，公告列出的受影響部署案例，是接收第三方證明者證明的 Succinct 自營主網 Prover Network。其他服務是否受影響，目前尚未確認。

以 Solidity 為基礎的 Groth16 與 Plonk 驗證路徑不受此次漏洞影響，因為它們使用固定形式的證明，不會處理問題所涉及的 Rust 張量。若 Compressed 證明的聚合結果最終是 Groth16 或 Plonk 證明，透過相關函式庫的驗證路徑也不受影響。

SP1 是一種零知識虛擬機（zkVM），可為以 Rust 等 LLVM 編譯的程式執行過程生成證明。Succinct 在 Immunefi 的 SP1 程式介紹中說明，開發者可透過此架構生成並驗證程式執行證明。

此次問題並非影響整個 SP1，而是 V6 特定原生 Rust 驗證路徑漏掉了張量形狀檢查。Arbitrum 曾使用 SP1 為實際主網區塊生成零知識證明，詳情可見先前報導。

Succinct 已修改資料讀取流程，會比對張量的儲存元素數量與宣告維度值的乘積，並在原生驗證過程中確認實際張量形狀。6.8.1 版發布後，團隊也為主網 Prover Network 套用經驗證的修補程式。

該網路的使用者不需變更整合方式。若有服務自行運行原生 Rust 驗證器並接收不可信證明，Succinct 建議升級至 6.8.1。