KiselevMaxim/defi-exploits-pre-audit-perspective

# 2026 年 DeFi 漏洞利用 —— 来自预审计工程师的视角 2026 年第一季度的三次 EVM 漏洞利用详解，透过专注的预审计视角，看哪些问题本可以在上线前被拦截。 ## 为什么会有这篇文章 截至 2026 年 4 月中旬，EVM 链上的 DeFi 协议因漏洞利用已损失超过 7.5 亿美元。仅其中两次攻击 —— Drift Protocol 和 Kelp DAO —— 就占据了该总额的 5.77 亿美元以上。其余损失分散在数十起规模较小的事件中，大多数损失金额在 100 万至 300 万美元之间，受害协议皆是那些自认为已准备好可以上线的项目。 过去五年里，我一直在 Azuro Protocol 编写核心智能合约 —— 这是一个去中心化预测市场协议，从 MVP 发展到生产环境，处理了超过 40,000 名用户和超过 3.9 亿美元的交易量。在这种规模下设计和发布生产代码，迫使你必须考虑那些乏味的故障模式：悄悄发生的算术溢出、盲目相信 AMM 在当前区块返回数据的预言机读取，以及没有任何多签保护的特权角色。 本文档中分析的漏洞利用并不离奇。它们都不需要国家级攻击者、新颖的密码学或零日编译器错误。它们只需要一位高级工程师在上线前花五天时间阅读代码库，并提出那些显而易见的问题。这就是预审计的意义所在。 ## 案例 1 —— Truebit Protocol **日期：** 2026 年 1 月 8 日 **损失：** 约 2640 万美元（8,535 ETH） **链：** Ethereum **缺陷类型：** 算术 —— 整数溢出 **受影响合约：** 位于 `0x764C64b2A09b09Acb100B80d8c505Aa6a0302EF2` 的 `Purchase` ### 发生了什么 Truebit 的 Purchase 合约负责根据存入的 ETH 铸造 TRU 代币。价格计算逻辑位于 `getPurchasePrice()` 中。该计算的分子包含一个加法操作，该操作可能会超过 `uint256` 的最大值并悄然回绕至接近零。 攻击者精心构造了一个足够大的 `mintAmount` 参数来触发溢出。分子发生回绕，计算出的价格骤降至接近零，于是合约兴高采烈地以几乎零成本的 ETH 铸造了数百万枚 TRU 代币。随后，攻击者将这些代币在可用的流动性池中抛售，从协议的储备中抽干了 8,535 ETH。 ### 为什么它能留存于生产环境中 该合约使用 **Solidity 0.6.10** 编译，部署于 2021 年。在部署时，加入了内置算术溢出检查的 Solidity 0.8.0 已经可用。该合约既没有导入 `SafeMath`，也没有对加法包含手动的 `require` 检查，而且据报道从未经过独立审计。 然后它在生产环境中静静运行了大约五年，直到有人发现了它。 ### 预审计会抓住什么 任何高级工程师检查清单上的第一项就是编译器版本指示符。处理用户资金的合约上如果出现 `pragma solidity ^0.6.x`，其本身就是一个值得标记的发现。下一个检查项是，针对用户可控输入的算术运算是否受保护 —— 无论是通过编译器版本还是通过 `SafeMath`。而这两点在这里都不成立。 这不是一个巧妙的缺陷。这是一个教科书级别的回归错误，任何具有 Solidity 生产环境经验的工程师进行的代码审查，都会在第一个小时内将其标记出来。 ### 给协议团队的经验教训 你们在 Solidity 0.8.0 之前部署且此后未经过重新审计或迁移的每一个合约，都有可能成为同类漏洞利用的受害者。2026 年的攻击者正越来越多地使用 AI 工具扫描早期部署的合约，以寻找这类完全相同的缺陷。如果你的生产环境中存在遗留代码，请将其视为“已知的未知风险” —— 而不要认为最初的审计会提供一劳永逸的保护。 **参考文献：** [SlowMist 事后分析](https://slowmist.medium.com/)，[Medium 技术剖析](https://medium.com/@zhenyazhdarkin/truebit-protocol-exploit-how-a-silent-overflow-led-to-a-26m-loss-ba1774037a3d) ## 案例 2 —— Makina Finance **日期：** 2026 年 1 月 20 日 **损失：** 约 413 万美元（1,299 ETH） **链：** Ethereum **缺陷类型：** 通过现货价格读取操纵预言机 **受影响合约：** `MachineShareOracle`（`updateTotalAum()` 函数） ### 发生了什么 Makina Finance 运营着一个金库系统，该系统根据 `MachineShareOracle` 计算份额价格（从而决定存款和提款的账目）。该预言机依次从 Curve 的 `DUSD/USDC` stableswap 池读取实时现货状态 —— 特别是 `calc_withdraw_one_coin()` 及相关函数的结果，所有这些函数返回的值都基于池的当前状态。 攻击者在单个原子交易中执行了以下操作： 1. 从 Morpho 和 Aave V2 闪电贷借入了约 **2.8 亿美元 USDC**。 2. 动用其中约 1.7 亿美元使 Curve 的 `DUSD/USDC` 池失去平衡，扭曲了该池将要报告的价格。 3. 在 Makina 上调用 `updateTotalAum()`，导致预言机读取已膨胀的状态并相应地更新 Makina 的份额价格。 4. 以操纵后的汇率在 Makina 存入或兑换，获得了远超真实市场价格所应给出的价值。 5. 撤销池操纵，偿还闪电贷，并带着差额利润扬长而去。 大部分提取的价值被 MEV 构建者抢跑截获，但该协议的 DUSD/USDC 池依然损失了约 413 万美元。 ### 为什么它能留存于生产环境中 三个叠加的设计缺陷使这一切成为可能： 1. 预言机更新函数是无权限的 —— 任何人都可以调用它。 2. 份额价格派生自同步现货价格读取，没有 TWAP，没有时间延迟，也没有流动性加权检查。 3. 没有偏差上限 —— 没有检查“今天的价格不能比昨天的价格偏差超过 X%”。 单就每一项而言，都是 DeFi 中已知的反模式。然而当它们结合在一起时，就构成了自 2020 年以来已抽干数十个协议的经典闪电贷预言机操纵模型。 ### 预审计会抓住什么 当审查一个使用任何形式预言机的 DeFi 协议时，我会按顺序看三件事：价格最终来自哪里，它能否在单个区块内被操纵，以及当它被操纵时协议的账目会发生什么。 如果对“它能否在单个区块内被操纵”的回答是肯定的 —— 而且当数据源是实时 AMM 池时，答案几乎总是肯定的 —— 那么协议至少需要以下之一：TWAP、针对外部参考的偏差上限，或一项硬性规定，即价格敏感操作不能与状态更新在同一交易中发生。而 Makina 拥有其中任何一项。 这种模式已经如此广为人知，以至于抓住它并不需要对 Makina 的特定架构有深厚的专业知识。它只需要你提出跟对待任何其他金库系统相同的五个问题。 ### 给协议团队的经验教训 如果你的协议账目在与存款或提款相同的交易中读取 AMM 现货状态，那么你就存在这个确切的漏洞。问题不在于“是否会被攻击”，而在于“何时”会有掌握 2.8 亿美元闪电贷流动性的人决定盯上你。增加一个 TWAP 或偏差上限的工程成本不过是几个小时，而不具备它们的代价将是整个池子。 **参考文献：** [VeriChains 分析](https://blog.verichains.io/p/analyzing-the-4m-makina-finance-exploit)，[Coinmonks 剖析](https://medium.com/coinmonks/makinas-4m-hack-8afca700c00c)，[VectorGuard CVE-2026-0120](https://github.com/pavondunbar/Makina-Hack-Rekt-News-CVE-Report) ## 案例 3 —— Resolv Labs **日期：** 2026 年 3 月 22 日 **损失：** 提取了约 2500 万美元（铸造了约 8000 万美元无支撑的 USR） **链：** Ethereum **缺陷类型：** 访问控制 + 缺少链上不变量 **受影响合约：** USR Counter，`requestSwap()` → `completeSwap()` 流程 ### 发生了什么 Resolv 运营着 USR，一种 Delta 中性的与美元挂钩的稳定币。铸造 USR 被实现为一个两步流程： 1. 用户在链上调用 `requestSwap()`，存入 USDC 并创建一个待处理的铸造请求。 2. 持有特权签名密钥（`SERVICE_ROLE`）的链下后端服务调用 `completeSwap()` 以最终确定要铸造多少 USR。 链上的 `completeSwap()` 函数检查了两件事：调用者拥有 `SERVICE_ROLE`，且铸造输出达到了最低阈值。它没有检查： - 存入抵押品与铸造的 USR 之间的比例。 - 铸造数量是否与任何预言机价格进行了比对。 - 每次交易的最大铸造量。 - 每个时间窗口的最大铸造量。 - 总供应量上限。 `SERVICE_ROLE` 本身被分配给了一个单一的外部拥有账户（EOA） —— 不是多签，没有阈值签名，甚至不是硬件钱包。该密钥存储在 AWS KMS 环境中。 攻击者入侵了该 KMS 环境，获得了以 `SERVICE_ROLE` 身份签名的权限，并提交了两笔巨额的 `completeSwap()` 调用。第一笔存入了约 10 万美元 USDC 并作为回报铸造了 **5000 万 USR** —— 相当于超量铸造了 500 倍。第二笔又铸造了 3000 万。随后，他们通过 DEX 流动性将 freshly-minted 的 USR 兑换成 ETH，并在 Resolv 暂停协议前卷走了约 2500 万美元。 ### 为什么它能留存于生产环境中 整个安全模型依赖于一个单一假设：`SERVICE_ROLE` 密钥永远不会被泄露。这里毫无纵深防御可言 —— 一旦密钥丢失，智能合约便没有任何后备措施。 在漏洞发生时，Resolv 的网站宣传其接受了来自五家公司的 14 次审计委托以及 Immunefi 上高达 50 万美元的漏洞赏金。但这些都没有发现这个设计缺陷。 ### 预审计会抓住什么 当我审查一个铸造某种东西的合约时 —— 代币、份额、债务头寸，任何东西 —— 我问的问题很简单且普遍适用： - 是什么阻止了这个函数超额铸造？ - 如果调用者是特权角色，是什么防止了受损的角色抽干协议？ - 是否有按每笔交易、每个区块、每个时间窗口、每个总供应量设定的上限？ - 存入价值与铸造价值之间的关系是在链上强制执行的，还是仅在链下执行？ Resolv 对这四个问题的回答全是错的。智能合约信任链下服务来维护不变量。链下服务则信任其密钥是安全的。当密钥被泄露时，这里根本没有第三层防线。 预审计在工作的第一天就能揭示这种模式。你阅读铸造函数，追踪它的依赖项，然后写下一份发现：“如果这个签名密钥曾被泄露，协议可能会被无限抽干。请在存款和铸造之间增加一个锚定独立预言机价格的链上比例检查。” 这仅仅是一个发现，花三十分钟写完，而它本可以阻止整个事件的发生。 ### 给协议团队的经验教训 如果你的智能合约的安全性完全取决于链下组件的正确运行，那么你的智能合约就不安全。链上不变量是你最后的防线。每一个密钥管理系统在某个时刻都曾被入侵过 —— AWS KMS、HSM、硬件钱包、多签参与者。设计你的合约时要做到，即使在密钥被盗时也能限制损害，而不是假设密钥永远不会泄露。 **参考文献：** [Chainalysis 事后分析](https://www.chainalysis.com/blog/)，[QuillAudits 剖析](https://www.quillaudits.com/blog/hack-analysis/resolv-labs-exploit-explained) ## 贯穿这三者的模式 三种不同的缺陷类型 —— 算术、预言机、访问控制。相同的根本模式：**本应在链上强制执行的假设，却交给了链下信任，或者根本没有强制执行。** - Truebit 信任编译器能处理溢出。但它选择的编译器版本并没有。 - Makina 信任没有人会拿出 2.8 亿美元来操纵一个池子。闪电贷在 2020 年就让这种假设变得过时了。 - Resolv 信任特权密钥永远不会被泄露。而 AWS KMS 环境经常遭到入侵。 预审计并不是为了寻找新奇的零日漏洞。它们的意义在于缓慢而系统地追问 —— 代码库中的每一个假设究竟依赖于什么。生产环境中发生的大多数漏洞利用，都是因为没有人提出过这些问题。 ## 预审计如何融入您的安全流程 预审计**不是** Trail of Bits、OpenZeppelin、Spearbit 或 Sherlock 等专业公司进行的全面审计的替代品。那些委托项目涉及多位高级审计员、适用时的形式化验证、深度经济建模以及数周的迭代。对于在上线时处理重大价值的协议来说，它们是必不可少的。 预审计是上述委托项目**之前**的一个层级。它的存在只有一个原因：确保你不会向顶级审计公司支付 3 万美元后，却发现他们找出的十五个问题本一次彻底的内部审查免费暴露出来。审计员在第一轮发现的每一个问题都会消耗你的修复周期 —— 修复代码、让他们重新审查修复方案，有时还要找出由修复引入的新问题。每一个周期都会增加时间和成本。 由高级工程师在审计公司拿到代码之前进行的为期 5-7 天的专注审查，通常能抓住顶级审计会暴露的问题中的 60-80%。剩下的 20-40% 就是你仍然需要全面审计的原因。但是你的修复轮次减少了，你的发布延误减轻了，你的审计公司可以把时间花在真正困难的发现上，而不是那些显而易见的问题上。 对于尚无法承担 3 万美元以上委托费用的协议 —— 早期团队、V1 版本发布、较小规模的部署 —— 预审计通常是预算范围内可获得的最高质量安全检查点。它不能替代全面审计，任何告诉你相反说法的工程师都在过度推销。但它是一个有意义的防御层，上述三个漏洞利用就是证据，表明 2026 年的协议在没有它的情况下依然在盲目上线。 ## 关于我 我是一名高级 Solidity 工程师，拥有 8 年以上的 EVM 智能合约经验和 23 年以上的整体软件工程经验。我在 [Azuro Protocol](https://azuro.org) 担任了五年的核心工程师，在那里我设计并交付了： - **[LiquidityTree](https://github.com/Azuro-protocol/LiquidityTree)** —— 一种用于在动态变化的 LP 池中进行公平 PnL 分配的链上线段树机制。自 2021 年起在生产环境中运行。 - **[Access](https://github.com/Azuro-protocol/Access)** —— 一种用于智能合约的基于 NFT 的角色和权限系统。自 2021 年起在生产环境中运行。 两者都是开源的，并且在今天仍被用于生产环境。 我为 DeFi 和 GameFi 团队提供专注的预审计代码审查。审查范围通常最多 1500 nSLOC，周期 5-7 天，费用 4,000 至 8,000 美元，交付一份按严重程度对发现进行分类的书面 PDF 报告，并包含一次跟进的电话会议。 **联系方式：** - Telegram: [@MaksimFounder](https://t.me/MaksimFounder) - 电子邮件: maximkiselevrossia@gmail.com - X: [@kiselevm](https://x.com/kiselevm) - GitHub: [@KiselevMaxim](https://github.com/KiselevMaxim) *最后更新：2026 年 5 月。随着时间推移将添加新案例。如果您希望分析特定的协议或漏洞利用，请开启一个 issue。*

标签：Azuro Protocol, CISA项目, DeFi, Drift Protocol, EVM, Kelp DAO, RuleLab, Truebit Protocol, TRU代币, Web3, Web3安全, Web报告查看器, 事件复盘, 代币经济学, 以太坊, 加密货币, 加密货币安全, 加密资产保护, 区块链安全, 合约审计, 攻击向量, 整数溢出, 智能合约安全, 溢出攻击, 漏洞分析, 路径探测, 链上安全, 闪电贷攻击, 零知识证明, 预审计, 预言机操纵, 黑客攻击