flashloan sets s_currentlyFlashLoaning[token] = true during the callback to prevent recursive flash loans for the same token. This per-token flag is the only reentrancy protection in the contract.
The flag does not guard redeem(), deposit(), or any other state-modifying function. Combined with the CEI violation in H-4 (exchange rate inflated before the callback), an LP who is also a flash loan borrower can call redeem() inside executeOperation at the pre-earned inflated rate, extracting more underlying tokens than they deposited.
Likelihood:
Any LP who also initiates a flash loan — a natural combination in a lending protocol — can execute this attack.
The attack is amplified by H-4 (CEI violation) and H-1 (deposit bypass); together these create a compounded exploit path within a single callback.
Impact:
Cross-function reentrancy during the callback enables LP-borrowers to extract yield before it is earned, at the expense of other LPs.
The per-token flag creates a false sense of reentrancy safety while leaving every other state-modifying function in the protocol exposed during callback execution.
Place this test in test/ and run forge test --match-test testCrossFunctionReentrancy. The test demonstrates that a malicious flash loan receiver can call redeem() during the executeOperation callback because there is no cross-function reentrancy guard, extracting inflated token amounts.
Inherit ReentrancyGuardUpgradeable and apply nonReentrant to both flashloan() and redeem() so the cross-function reentrancy path is blocked at the modifier level.
The s_currentlyFlashLoaning per-token flag can be retained for the semantic check (e.g., blocking deposits during active flash loans per H-1 fix), but it is not a substitute for a full reentrancy guard.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.