Introduction
During a recent security audit of an Eco integration for LI.FI, I discovered a denial-of-service (DoS) vulnerability in Eco's Vault contract that could prevent legitimate users from receiving their refunds.
What makes this vulnerability particularly interesting is its simplicity—an attacker needs just 1 wei to completely block refunds for certain users.
Background
Eco.com's Vault contract manages user deposits and refunds for their intent-based system. Users can lock tokens (like USDC) as rewards in the vault, and under certain conditions (if bridging fails), they're entitled to refunds of their locked funds.
The Vulnerability
The vulnerable code can be found in the Vault contract at line 130. The issue stems from how the contract handles ETH refunds.
The Problem
When the Vault processes a refund, it attempts to send any accumulated ETH back to the user along with their tokens. However, if the user is a smart contract that cannot accept ETH payments (i.e., lacks a payable fallback or receive function), the entire refund transaction will revert.
Attack Scenario
Here's how an attacker could exploit this vulnerability:
- A smart contract creates an intent with 100 USDC as a reward and locks it in the vault
- An attacker force-sends just 1 wei of ETH to the vault on behalf of the victim contract (using selfdestruct or other force-send methods)
- When the smart contract attempts to claim their refund, the transaction fails because:
- The vault tries to send back the 1 wei along with the USDC
- The victim contract cannot accept ETH payments
- The entire refund transaction reverts
- The victim's funds remain permanently locked in the vault
Impact
This vulnerability allows an attacker to:
- Permanently lock legitimate users' funds with minimal cost (just 1 wei + gas)
- Target any smart contract user that cannot receive ETH
- Create a reliable DoS condition that cannot be resolved without a contract upgrade
The attack is particularly dangerous because:
- It's extremely cheap to execute
- It affects all smart contract integrators that don't handle ETH
- There's no way for the victim to recover their funds once attacked, if contract is not upgradeable.
But since it's affect a small subset of users, I would classify this as a LOW severity bug.
The Fix
After submission, the team fixed in the issue via PR-345.
Responsible Disclosure
Since Eco's bug bounty program is currently paused, I decided to disclose this vulnerability responsibly by:
- Privately reporting it to the Eco team through Spearbit
- Publishing this writeup to help the security community learn from this case
Key Takeaways for Developers
This vulnerability highlights several important security considerations:
- Beware of forced ETH sends: Contracts should never assume they only receive ETH through intended channels
- Separate concerns: Don't let ETH refund failures block critical token operations
- Consider smart contract users: Many protocols integrate via smart contracts that may not handle ETH
- Test edge cases: Always consider what happens when users are contracts, not EOAs
Conclusion
This case demonstrates how even simple oversights in smart contract design can lead to critical vulnerabilities. A single wei—the smallest unit of ETH—was enough to create a complete denial of service condition. As the DeFi ecosystem continues to grow and protocols integrate with each other, it's crucial to consider all possible user types and attack vectors.
Disclaimer: This vulnerability has been responsibly disclosed and a fix has been submitted. Users should wait for official announcements from Eco regarding the deployment of the patch before resuming normal operations.