Full Report
Aave is a very common loan protocol in the web3 space. This works by depositing your collateral to the system, which allows you to take out loans from any token in the eco-system. A user can withdraw or deposit assets. The method of keeping track of this is Atokens, which act similar to collateral tokens (cTokens) on other protocols. Denial of services (DoS) are particularly nasty in the blockchain space because contracts are commonly built to be not-updatable. So, being able to lock assets in the contract would be awful. Forcing reverting or crashes is a common way to do this. When the user owns at least an AToken with a LTV of 0 and this AToken is used as collateral, restrictions aer put onto the types of interactions that can be performed. Withdraw, transfer and a few others do not work. I don't understand why this is the case but that's how this functions. When an AToken is received by a user without any balance on a transfer, it is automatically added as collateral. However, this conflicts with some of the checks mentioned above. We can transfer over a poisoned token that will cause reverts on most functions because of the account having value it shouldn't have. It is possible to escape this with specific set of actions. However, if this is an EOA, then these actions would have to be done in sequence, giving a bot the opportunity to send over more funds to cause a crash. Neat! To fix this, the token shouldn't be added as collateral right away if the received AToken has a LTV of 0. Compared to web2, there are so many ways to interact with a system to cause problems; from sending unexpected tokens to reentrancy, these bugs are wild. This concludes 3 bugs in Aave that required very obscure scenarios in order to exploit.
Analysis Summary
The provided article describes a set of vulnerabilities discovered in the Aave protocol related to how it handles `ATokens` with a Loan-to-Value (LTV) of zero, which can lead to Denial of Service (DoS). Since specific CVE identifiers, CVSS scores, and patch versions are not provided in the context, I will use placeholders or infer based on the severity of the described impact (DoS on an immutable contract is typically high severity).
Here is the structured summary:
# Vulnerability: Aave Protocol: Denial of Service via LTV=0 AToken Collateral Interaction
## CVE Details
- CVE ID: N/A (Not provided in context)
- CVSS Score: N/A (Inferred High, due to DoS on immutable contracts)
- CWE: CWE-400 (Uncontrolled Resource Consumption, related to DoS) or similar logic flaw.
## Affected Systems
- Products: Aave Lending Protocol (Smart Contracts)
- Versions: Specific vulnerable versions are not detailed, but the vulnerability exists where the logic allows ATokens with 0 LTV to be automatically added as collateral upon transfer, regardless of existing user balances.
- Configurations: Any configuration where an AToken with an LTV of 0 is transferred to a user address that subsequently interacts with the collateral management functions (e.g., withdraw, transfer) of that AToken's underlying reserve.
## Vulnerability Description
The vulnerability stems from an interaction flaw between the AToken collateral tracking mechanism and specific AToken types where the Loan-to-Value (LTV) is zero.
1. **Automatic Collateral Addition:** When an EOA receives an `AToken` transfer *without* an existing balance for that token, the token is automatically registered as collateral.
2. **Restriction Trigger:** If a user possesses an AToken with an LTV of 0 and this specific AToken is used as collateral, restrictive checks are enforced on standard functions (e.g., withdrawal and transfer are blocked).
3. **DoS Vector:** By transferring a "poisoned" AToken (one that triggers these internal zero-LTV collateral restrictions) to a vulnerable address, subsequent critical interactions with the lending pool are forced to revert. For an EOA, this state can potentially be locked indefinitely unless a specific sequence of actions is executed. If the victim is an EOA, an attacker can leverage subsequent transactions (e.g., via a bot sending more funds) to continuously exploit the reverting state, trapping assets or preventing necessary operations (Denial of Service).
## Exploitation
- Status: PoC likely constructible based on description (Described as exploitable via specific steps).
- Complexity: Medium to High (Requires knowledge of internal AToken/Collateral logic and precise sequencing).
- Attack Vector: Network (Remote execution via blockchain transaction).
## Impact
- Confidentiality: None
- Integrity: Moderate (Ability to prevent valid state changes/operations)
- Availability: High (Leads to Denial of Service, potentially locking user assets or preventing protocol liquidity operations for the affected account/asset pool).
## Remediation
### Patches
- **Recommended Fix (Based on Context):** The protocol should be updated to prevent an AToken from being immediately added as collateral if the received AToken has an LTV of 0. Interactions should be gated until explicit deposit actions are taken or the state is otherwise validated.
- [Specific patched versions are not available in the context.]
### Workarounds
- Users identified as potentially affected (e.g., those receiving an LTV=0 AToken) should immediately attempt to execute the "escape sequence" mentioned in the research, if documented, to manually correct the collateral state.
- Minimizing interaction with asset types known to exhibit LTV=0 behavior until official patches are applied.
## Detection
- **Indicators of Compromise:** Transaction logs showing repeated, immediate function reverts following an AToken transfer, particularly when the transferred AToken's LTV is zero.
- **Detection Methods and Tools:** Monitoring for transactions that transfer tokens immediately followed by failed `withdraw()` or `transfer()` calls on the same address, indicative of the restrictive state being triggered.
## References
- [No specific vendor advisories or external links provided in the context.]