Morpheus 审计报告分享：AAVE 项目 Pool 合约地址更新导致的组合性风险

前言

这次为大家带来的是 Code4Rena 审计平台上 Morpheus 项目的审计结果分享，也是第一次写这种形式的博客，主要的目的是在阅读审计报告的时候学习并归纳一些比较有价值的漏洞形式。好的，话不多说，直接开始。

漏洞信息

漏洞报告

1. https://code4rena.com/audits/2025-08-morpheus/submissions/S-484
2. https://code4rena.com/audits/2025-08-morpheus/submissions/S-666

漏洞代码

1. https://github.com/code-423n4/2025-08-morpheus/blob/a65c254e4c3133c32c05b80bf2bd6ff9eced68e2/contracts/capital-protocol/Distributor.sol#L192-L248

漏洞背景

在 AAVE 项目中，Pool 合约的地址是可能改变的：

1. 代码中存在修改 Pool 地址的逻辑：
   1. https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/configuration/PoolAddressesProvider.sol#L23
   2. https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/configuration/PoolAddressesProvider.sol#L57-L61

在 C4 的审计报告中提到“AAVE 在 V2 到 V3 等主要版本升级或池迁移期间修改过 Pool 地址”，那么历史上出现过修改 Pool 地址的操作吗？：[尚未找到证据]

为了求证这个说法，经过多次的搜索与链上状态分析，并没找到修改的相关信息。

AAVE 地址查询：https://aave.com/docs/resources/addresses

1. 通过查询相关 Event 没有结果：
   • V2 Event：AddressSet(bytes32,address,bool)：0xf2689d5d5cd0c639e137642cae5d40afced201a1a0327e7ac9358461dc9fff31
   • V3 Event：AddressSet(bytes32,address,address)：0x9ef0e8c8e52743bb38b83b17d9429141d494b8041ca6d616a6c77cebae9cd8b7
2. 通过对比 PoolAddressesProvider 和 Pool 合约的部署日期，均为一致的，说明 Pool 在部署后就没有进行过更改。

漏洞案例

在 Distributor 合约的设计中，token - aToken - Pool 三者的关系是对应的。

且 Pool 的地址是通过 setAavePool() 函数手工设置的

在 addDepositPool() 函数中， 管理员可以为目标 token 新增一个奖励池子，如果该池子是 AAVE 策略的，会先检查该 token 对应的奖励池是否已经存在，然后再对 Pool 进行进行 token 和 aToken 的授权。

如果 AAVE 更新了 Pool 的地址，则 token 和 aToken 对应 Pool 应该进行改变。但即使管理员通过 setAavePool() 函数重新设置了 aavePool 的地址，也无法取消旧池子的授权，以及为新池子添加授权。

如果采取再次添加新池子的形式，也会由于 !isDepositTokenAdded[token_] 的检查而失败。

这个设计缺陷会导致奖励池中的资产被锁定，用户无法正常领取奖励。

修复方案

在 setAavePool() 函数中添加如下逻辑

1. 取消对旧池子的授权
2. 执行对新池子的授权

补充材料

建议在需要 Pool 合约时从 PoolAddressesProvider 智能合约中通过 getPool() 函数获取正确的地址，而不是自行设定一个 Pool 地址。如果采取手动设置的形式，在 AAVE 更新后和手动更新前这段事件内，无法保证协议能够正常运行。

https://aave.com/docs/developers/smart-contracts/pool-addresses-provider

后记

第一次写这种形式的文章，感觉无论是自己分析还是读者阅读，最大的难点就是如何在不熟悉项目代码的前提下，能够对漏洞报告中的内容有清晰的认知和深入的理解。但是目前没有很好的办法能够满足这种需求，只能够退而求其次。尝试尽可能地把漏洞相关的代码从项目中拆解出来并且向读者交代一个大概的项目背景这样类似 docker 般的形式来输出内容。当然如果你什么更好的方法也随时欢迎讨论，感谢阅读。