Full Report
Aave is a very common laon protocol in the web3 space. A flashloan is a loan that occurs within a single transaction. By doing this, a user can get access to a large amount of money without the owner risking anything. Usually, there is a fee associated with providing the flash loan. On Aave, this fee is called a premium. The user asks for a specific amount, then a percentage is added on top of this for what they are required to pay back. Aave calls a callback function in the users smart contract for this. Once a user goes to repay the flashloan, the function validates that the original funds were paid back. On the premium, it checks to see if this was paid back OR opens a position on the amount that needs to be repaid. When specifying the position that needs to be taken, there is a miscalculation on the approval price. Some of the funds will not be sent in this case, resulting in leftover funds that Aave could spend. If a hack occurred of Aave, this would be a bad avenue for exploitation. Additionally, this logs a wrong event. USDT does not follow the ERC20 standard for both returning a bool on successful execution or approvals with a value greater than zero. Both of these can lead to reverts, sadly. This issue is present in the standard template for flashloans on Aave, which makes it more interesting of an issue. Overall, this is a defense-in-depth issue that was fairly complicated to encounter and understand. Not a very big problem in Aave.
Analysis Summary
# Vulnerability: Aave v3 Miscalculation in `executeFlashLoan` Premium Logic
## CVE Details
- **CVE ID:** N/A (Disclosed via Bug Bounty Program)
- **CVSS Score:** Low/Medium (Vendor-assessed)
- **CWE:** CWE-682: Incorrect Calculation; CWE-770: Allocation of Resources Without Limits or Throttling
## Affected Systems
- **Products:** Aave v3 Core Protocol
- **Versions:** Versions prior to v3.0.2
- **Configurations:** Flashloan transactions utilizing the "Flashloan-to-Borrow" feature (opening a position instead of instant repayment) and implementations based on the `MockFlashLoanReceiver.sol` template.
## Vulnerability Description
The flaw exists within the `FlashloanLogic.executeFlashLoan` function. When a user executes a flashloan with the intent to open a borrow position, they are technically not required to pay the flashloan premium (fee). However, the protocol logic incorrectly calculates `vars.totalPremiums[vars.i]` as if a fee were still due.
This leads to several technical discrepancies:
1. **Over-approval:** The `receiver` contract is instructed to approve Aave to spend more tokens than necessary (Principal + Phantom Premium).
2. **Event Logging:** The `FlashLoan` event emits incorrect premium data.
3. **ERC20 Incompatibility:** For tokens like USDT that do not strictly follow ERC20 standards (e.g., reverting on non-zero to non-zero approvals), the "phantom" premium can cause the entire transaction to revert if the contract attempts to approve a new amount over an existing non-zero allowance.
## Exploitation
- **Status:** PoC available (submitted via bug bounty); No evidence of exploitation in the wild.
- **Complexity:** High (Requires specific interaction with flashloan-to-borrow logic).
- **Attack Vector:** Network (Smart Contract Interaction).
## Impact
- **Confidentiality:** None
- **Integrity:** Low (Incorrect event logging and state data regarding premiums).
- **Availability:** Medium (Potential for DoS in integration contracts, particularly with non-standard tokens like USDT).
## Remediation
### Patches
- **Aave v3.0.2:** The logic has been updated to ensure premiums are correctly calculated as zero when a borrow position is opened.
### Workarounds
- **Integration Update:** Developers using flashloans should update their receiver contracts to ignore the `premium` variable passed by the pool if they are using the "borrow" mode.
- **Safe Approvals:** Use OpenZeppelin’s `SafeERC20` or Solmate’s `SafeTransferLib` to handle non-standard tokens like USDT/BNB that may revert on specific `approve()` calls.
## Detection
- **Indicators of Compromise:** Discrepancies between `premium` values in `FlashLoan` events and actual protocol revenue for flashloan-to-borrow transactions.
- **Detection Methods:** Audit flashloan callback implementations for `safeApprove(0)` calls prior to setting new allowances to prevent USDT-style reverts.
## References
- **Aave Governance Disclosure:** hxxps[://]governance[.]aave[.]com/t/bgd-bug-bounties-proposal/13077
- **Vulnerable Code Reference:** hxxps[://]github[.]com/aave/aave-v3-core/blob/94e571f3a7465201881a59555314cd550ccfda57/contracts/protocol/libraries/logic/FlashLoanLogic[.]sol
- **Researcher Write-up:** hxxps[://]stermi[.]medium[.]com/aave-v3-bug-bounty-part-1-security-concerns-and-improvements-about-the-executeflashloan-function-47a91fd4c067