Damn Vulnerable DeFi — Challenge #2 Naive receiver (high-level)

Educational wargame: Damn Vulnerable DeFi by @tinchoabbate. Challenge framing: a pool offers expensive ETH flash loans; a user-deployed receiver holds ETH and can accept those loans. Goal in the lab is to drain that receiver.

Vulnerability class / root cause

• The pool’s flashLoan(borrower, amount) is callable by anyone and will push a loan into an arbitrary borrower contract that implements the receive hook.
• The receiver trusts calls that appear to come from the pool and always repays principal + fixed fee from its own balance.
• There is no authorization for “who may nominate this receiver as borrower,” so a third party can repeatedly force fee payments until the receiver’s ETH is gone.

Root cause in plain language: missing access control on who can initiate a fee-bearing callback against a victim contract.

Impact (abstract)

A receiver that holds ETH (or similar) and auto-repays flash-loan fees can be drained by unsolicited loans. In production DeFi this is loss of user funds sitting in helper/receiver contracts.

Mitigations / lessons

• Restrict flashLoan so only the borrower (or an approved operator) can start a loan for that address—or require an explicit pull/opt-in from the receiver.
• Receivers should reject unexpected loans / enforce a whitelist of initiators and max fee exposure.
• Prefer pull patterns over “anyone may push a fee-bearing call into me.”
• Keep educational solves in private lab repos; do not publish runnable drain scripts against live deployments.

Solve steps and PoC omitted.