Scroll披露，部署在以太坊主网上的Bundle证明验证器存在漏洞，可能使旧的有效证明被用于新的公开输入。项目方于2026年11月3日收到漏洞赏金报告，并于11月10日为Batch Version 10注册了修复后的验证器。Scroll确认，该漏洞未在主网上遭到利用。
验证缺陷涉及状态确认的可信边界
这次漏洞的关键，是证明与公开输入之间的对应关系可能被绕过。证明有效，并不意味着它可以用于确认另一组输入；验证器需要确认的，是证明与当前待确认数据相匹配。若旧证明能够被用于新的公开输入，原本针对特定数据成立的验证结果，就可能被挪用到其他数据上。
按照Scroll披露的漏洞机制，攻击者可能借此最终确认任意状态根和提款根。状态根用于概括链上状态，提款根则与提款信息的验证有关。因此，这一缺陷触及状态与提款确认的可信基础，而不仅是证明处理效率或服务可用性。不过，能够造成这些后果的漏洞能力，与是否已经发生攻击，需要分别判断。
利用路径受证明者权限和强制模式约束
利用该漏洞存在前提：攻击者需要获得许可制证明者角色，或借助连续7天未完成最终确认后启用的强制批次模式。这意味着，漏洞并非仅凭提交一份旧证明就能由任意外部参与者直接利用，能否进入相关处理路径同样重要。
许可制证明者角色构成了一道参与权限约束，但它不能替代验证器本身的正确性。若具备相应权限的参与者可以触发缺陷，证明验证仍须独立承担校验责任。从这一点看，权限控制限制了潜在攻击入口，修复验证逻辑则处理了缺陷本身，两者作用不同。
强制批次模式涉及另一条条件路径。连续7天未完成最终确认，是其启用条件，而不是漏洞已经被利用的证据。Scroll表示，该模式从未启用，因此不能把这一备用路径的存在直接理解为漏洞期间已有相应攻击入口被实际打开。
748次最终确认提供了什么证据
Scroll表示，漏洞存在期间的748次最终确认均使用正常证明完成，并确认主网上没有发生漏洞利用。这一数字的统计对象是最终确认次数，不是用户数、交易数或受影响资产数量，不能据此推算资金风险规模。
这些披露将技术上可能发生的攻击与实际运行情况区分开来：漏洞具备绕过证明与输入对应关系的潜在能力，但项目方对期间确认记录的检查结果，以及强制模式从未启用的状态，支持其关于未被利用的结论。此前版本的验证器不受影响，也限定了此次问题的版本范围，不能将其扩展为所有历史验证器均存在同类缺陷。
修复落地后，仍应区分版本与权限风险
从已披露安排看，这次事件值得关注的重点，是验证逻辑缺陷与运行约束同时存在：前者可能破坏确认结果的可信性，后者限制了缺陷可被触发的条件。我们的判断是，不能因存在权限门槛而低估验证器漏洞，也不能仅凭最严重的理论后果认定已经发生资产损失；评估应同时核对缺陷能力、可达路径和实际确认记录。
目前明确的修复动作，是为Batch Version 10注册修复后的验证器。后续若有进一步公开说明，最有价值的信息将是该版本的验证器使用情况、证明与公开输入绑定关系的修复细节，以及对许可制证明者和强制批次路径的验证结果。这些条件直接关系到同类错误能否再次穿过确认流程，也比单独强调漏洞严重程度更有助于判断修复效果。
