Blockaid追踪Flow借贷项目More Markets 930万美元漏洞利用：安全应急负责人如何守住处置边界

8月31日，已确认的是一笔930万美元级别的利用事件

2026年8月31日，区块链安全公司Blockaid披露，其追踪到Flow区块链上的借贷项目More Markets发生了一起价值930万美元的漏洞利用事件。相关信息由BeInCrypto于当天发布，事件主体包括安全机构Blockaid、Flow生态借贷项目More Markets，以及被利用的链上资金，关键规模为930万美元。

从安全应急负责人的视角看，当前最重要的不是迅速补齐一个未经证实的攻击剧本，而是先把“已确认事实”和“待核验事实”分开。现阶段公开素材明确给出了事件发生的项目、所属链上生态、追踪机构和损失规模，但没有进一步说明攻击入口、漏洞类型、具体资产构成、攻击交易、项目方是否暂停合约、资金是否流入交易平台，也没有给出More Markets或Blockaid的完整技术分析与官方处置声明。

这一区分直接决定应急动作。若在初步阶段把推测当成事实，团队可能错误修改合约、误标地址，甚至在没有完成证据留存前破坏关键线索。930万美元已经足以说明事件具有高优先级，但金额本身并不能证明漏洞属于预言机、清算、权限、价格操纵、重入或跨合约调用中的任何一种。应急负责人需要先建立事件编号、时间线和证据目录，再进入技术归因。

第一阶段不是“找原因”，而是冻结变化

面对More Markets这类借贷项目事件，第一项工作应是控制新增风险，且必须区分“停止风险扩散”和“保留取证环境”两件事。

如果项目方仍能控制相关参数，应立即评估是否需要暂停新增借贷、提款、清算、抵押品调整或其他可能继续改变资产状态的操作。具体是否暂停，不能仅凭930万美元这一数字决定，而要结合攻击交易是否仍在发生、相关合约是否还能被调用、项目的治理权限是否可用，以及暂停本身会不会引起更大范围的资产损失。任何紧急管理操作都应记录发起人、审批人、时间、交易内容、签名过程和链上结果。

对于安全团队而言，最先要固定的是可复核证据：

• 记录Blockaid披露的原始页面、发布时间和相关链接；
• 保存已确认的攻击交易、受影响合约和关联地址；
• 对节点返回的数据、区块高度、交易回执和事件日志进行留档；
• 将项目合约当前状态、关键参数和资产余额做快照；
• 记录每一步暂停、升级、参数修改和地址标记操作；
• 将事实、判断、假设分别写入事件记录，避免后续报告混淆。

如果团队只关注追回资金，而没有同时保存完整证据，后续可能无法解释资金是如何从用户仓位、协议池或其他合约中流出的。反过来，如果只做取证而不阻断可重复利用路径，攻击者可能继续改变链上状态。因此，处置流程应由封堵、监控、取证三条线并行推进，而不是等到原因完全查清后才开始限制风险。

第二阶段要重建资金路径，而不是只盯一个地址

借贷协议的资产变动通常不会只停留在单笔转账上。应急团队应从Blockaid已经确认的线索出发，重建事件前后完整的链上路径，至少回答四个问题：资金从哪里被取出，经过了哪些合约，是否发生了资产兑换，最终停留在哪里。

第一步是确认受影响的资产和账户范围。930万美元是事件报道中的关键损失规模，但报告素材没有说明这一数字对应单一资产、多个资产，还是按某一时点估值计算。因此，项目方不能直接把930万美元等同于某个代币数量，也不能在没有余额快照的情况下对用户损失作逐笔承诺。

第二步是区分协议资产、用户仓位和攻击者控制资产。应急团队需要将事件前后的总余额、可取余额、抵押品余额、借款余额、清算状态和未结算头寸分别核对。若某些余额只是会计记录，而对应资产已经被转移，前端显示仍然正常，就会形成二次误判。

第三步是追踪中间跳转。攻击者可能使用多个地址、合约调用和兑换路径，但在事实未确认之前，不能简单把所有与攻击地址发生交互的地址都标成黑名单。地址标记应记录判断依据，并注明置信度与待验证项。对于已经进入交易平台、托管服务或其他可冻结入口的资金，项目方需要通过合规渠道提交证据，而不是在公开渠道发布未经核实的指控。

第四步是持续监控后续动作。事件发生后，攻击者可能拆分资产、转入新的合约，或者等待市场流动性变化。监控规则应覆盖攻击交易的直接关联地址、受影响合约的新调用、异常提款、资产兑换和跨合约转移。每条告警都要能够回溯到交易哈希、区块高度和规则触发原因，避免只发送一条无法复核的“高危提示”。

未知的攻击机制，必须通过假设验证逐项排除

目前素材没有披露More Markets事件的具体漏洞成因。安全团队可以建立假设，但不能把假设写成结论。较稳妥的做法，是按照协议边界逐项验证，而不是先选定一个最容易传播的故事。

如果怀疑是价格相关问题，应检查事件期间价格来源、更新间隔、资产流动性、报价有效期和借贷市场采用的估值规则；如果怀疑是清算逻辑，应核对健康因子、抵押率、清算奖励以及清算前后资产变化；如果怀疑是权限问题，应检查管理员、升级者、参数管理者和多签账户在事件前后的调用记录；如果怀疑是合约交互问题，则应对调用栈、外部调用顺序、状态更新和异常回退进行复现。

这些只是排查方向，并不是对本次事件的判断。只有当团队能够用链上交易、合约源码、部署版本、日志和可重复测试相互印证时，才能在事件报告中确认原因。若源码未公开、合约已升级或链上数据不足，应明确写出证据缺口。

复现环境也应与生产环境隔离。团队可以使用事件前的合约版本、相同的关键参数和对应区块状态建立仿真环境，验证某笔交易是否能够产生相同结果。测试记录应包括输入、调用者、区块状态、预期结果和实际结果。不要在真实资金环境中反复尝试攻击路径，也不要为了验证猜测而向生产合约发送高风险交易。

对用户和合作方，信息发布要做到“已知、未知、行动”

930万美元级别事件发生后，用户最关心的是资产是否安全、哪些功能还能使用、是否需要撤销授权，以及项目方是否已经确认损失范围。项目方的公告应围绕这些问题组织，而不是只发布一句“正在调查”。

第一份公告可以先说明：More Markets位于Flow生态，Blockaid已经追踪到一笔930万美元级别的漏洞利用事件，项目方正在核验受影响范围；同时列出已经暂停或仍可用的功能。若某项信息尚未确认，应直接标注“尚未确认”，而不是用模糊措辞制造确定感。

对于用户操作建议，也应以实际风险为依据。如果某些合约交互仍可能导致资金继续流失，应明确提醒用户暂缓相关操作；如果需要撤销授权，公告应提供经过核验的官方入口，并提醒用户防范冒充项目方的钓鱼链接。不能在没有确认授权风险的情况下，把所有用户都引导到第三方工具进行操作。

对合作方的沟通则需要更细。节点服务商、钱包、交易平台、审计机构和链上监控团队应收到结构化信息，包括已确认交易、受影响合约、相关资产、攻击地址的证据状态，以及项目方希望对方协助的具体事项。任何地址名单都应注明“直接确认”“高度关联”或“待核验”，避免把推测性地址扩散为事实。

事件结束后，修复不能只停留在补漏洞

More Markets事件的后续治理，不能以“合约修复完成”作为唯一结束条件。安全应急负责人需要推动一次完整的恢复验收。

首先，项目方应确认受影响合约的版本、部署权限和升级路径。若需要迁移资产或启用新合约，必须说明旧合约如何限制继续使用、用户仓位如何核对、资产如何迁移，以及异常余额如何处理。任何新合约上线前，都应完成代码审查、权限核验、关键路径测试和小范围验证。

其次，要重新检查借贷系统的风险边界。包括资产上架条件、价格来源、最大借款规模、单一市场暴露、清算参数、暂停权限和异常提款限制。参数并非越严格越安全，但每项参数都应有明确依据、变更审批和回滚方案。

再次，应把监控从“发现攻击”扩展到“发现风险状态”。针对借贷协议，监控不应只依赖单笔大额转账，还应关注短时间内抵押品价值异常变化、借款规模跳升、价格来源失真、权限调用、合约升级和批量账户行为。告警触发后要有值班人、升级路径和处置时限，否则监控只会产生信息，不会形成防线。

最后，项目方需要发布可复核的事后报告。报告至少应区分事件时间线、受影响范围、已确认漏洞、仍在调查的问题、处置交易、资金追踪状态和后续补救安排。对于尚未追回或无法确认的资金，不能用笼统措辞替代事实；对于尚未确定的攻击机制，也不应为了完整叙事而过早定性。

930万美元的More Markets事件提醒安全团队，链上借贷协议的应急处理不是一次技术排障，而是一项同时面对合约状态、资金流向、用户沟通和证据完整性的综合工作。Blockaid已经提供了关键事件线索，接下来真正决定损失是否扩大、调查是否可信的，是项目方能否在信息不完整时保持动作克制，在风险持续时快速建立边界，并把每一个结论都放回可验证的链上证据中。