FLOW-5: claimRefund Can Orphan Pending Requests and Prevent Cleanup

[liobrasil]

Severity: Medium

Files Affected

• solidity/src/FlowYieldVaultsRequests.sol

Description

FlowYieldVaultsRequests.createYieldVault() and depositToYieldVault() escrow funds by transferring tokens into the contract in _validateDeposit(), and then incrementing pendingUserBalances[user][token] inside _createRequest() while the request stays in RequestStatus.PENDING until the authorized COA calls startProcessing(requestId).

However, claimRefund(tokenAddress) allows a user to withdraw the entire pendingUserBalances[msg.sender][tokenAddress] without checking whether that balance is backing any still-PENDING CREATE/DEPOSIT requests.

Exploit Scenario

1. User deposits 10 FLOW via createYieldVault()
2. _validateDeposit() transfers 10 FLOW to contract
3. _createRequest() credits pendingUserBalances[user][token] += 10
4. User immediately calls claimRefund(NATIVE_FLOW)
5. User receives 10 FLOW, pendingUserBalances set to 0
6. Request remains PENDING but is now unbacked

This can permanently bloat the pending queue with "unbacked" PENDING requests that cause startProcessing() to revert with InsufficientBalance, and can make cancelRequest() / dropRequests() revert due to underflow.

Recommendation

Consider changing behavior so cancelRequest() and dropRequests() can mark requests as failed and remove them from queues even if the tracked pendingUserBalances is insufficient.

---

Parent Issue: #15

[liobrasil]

Fixed in commit e832744

claimRefund() now only withdraws from claimableRefunds mapping, not pendingUserBalances. Users cannot drain escrowed funds backing pending requests.
claimableRefunds is only credited when a request is cancelled/dropped/failed—never while backing a still-PENDING request. The "create request → immediately drain escrow → leave unbacked PENDING entry" exploit path no longer exists.

[vishalchangrani]

@liobrasil to add details about test.