被黑4次，每次同一类漏洞：Venus Protocol 捐赠攻击全链路技术分析

2026年3月15日，Venus Protocol（BNB Chain 借贷协议）再次遭到攻击，产生 $2.15M 坏账。这是该协议5年内的第4次重大安全事故。

更讽刺的是：2023年 Code4rena 审计就明确指出了这个攻击向量，Venus 团队将其归类为"正常行为"。

一、攻击全链路分析

1.1 准备阶段：9个月的潜伏

• 77 笔 Tornado Cash 提款，7,447 ETH（约 $16.29M）
• Aave 存入 ETH → 借出 ~$9.92M 稳定币
• 9个月慢慢买入 THE，占 supply cap 的 84%
• 社区已标记攻击者地址为可疑，Venus 未行动

1.2 突破阶段：捐赠攻击

Supply cap 只在 mint() 中检查，直接 transfer() 绕过：

function mint(uint256 mintAmount) external {
    require(totalSupply + mintAmount <= supplyCap, "Cap exceeded");
}
// 攻击者: THE.transfer(address(vTHE), 36_000_000e18);  // 无检查

vToken 汇率 = 合约余额 / vToken 供应量。捐赠膨胀余额但不增 vToken。抵押品从 ~$3.3M → ~$12M（3.81×）。

阶段	合约内 THE	占 Cap	方式
准备	12.2M	84%	mint()
捐赠	49.5M	341%	transfer()
峰值	53.2M	367%	清算前

1.3 提取阶段

递归借贷循环 + 薄流动性价格操纵。预言机抵抗了37分钟后失效。$5.07M 提取，$2.15M 坏账。

二、审计为什么没用？

Code4rena (2023): "Donations bypass supply cap logic." → 团队: "Supported behavior."

12个月前 ZKSync 部署同类漏洞亏 $717K。5年4次，同类根因。

William Li 2023年发表论文建模了此类攻击，3月15日实时识别并做空赚 $15K。Venus 2小时后才回应。

三、修复方案

uint256 public totalManagedAssets;
function _beforeTokenTransfer(address from, address to, uint256 amount) internal {
    if (to == address(this)) {
        totalManagedAssets += amount;
        require(totalManagedAssets <= supplyCap, "Cap exceeded");
    }
}

四、核心教训

1. Supply cap 必须覆盖所有路径
2. 链上监控关注累积模式
3. 认真对待审计发现
4. Compound V2 fork 都有这个问题

---

数据来源：Venus Post-mortem、Code4rena 2023、The Block、Quill Audits、William Li