Submission Details
Severity:
Receiver mismatch in deposit enables third-party refund without burning attacker’s shares
Root + Impact
Description
Issue:
depositrecords the stake underreceiverbut mints shares tomsg.sender. An attacker can deposit withreceiver = victimso the victim can later callcancelParticipation()and drain vault funds, while attacker keeps the shares.
function deposit(uint256 assets, address receiver) public override returns (uint256) {
...
uint256 stakeAsset = assets - fee;
@> stakedAsset[receiver] = stakeAsset; // attribution to receiver
uint256 participantShares = _convertToShares(stakeAsset);
...
@> _mint(msg.sender, participantShares); // shares to msg.sender (attacker)
}
// Root cause in the codebase with @> marks to highlight the relevant section
Risk
Likelihood:
-
Happens whenever
receiver != msg.senderis used (allowed by the API). -
No check enforces receiver-sender consistency.
Impact:
-
Grief/Drain: a third party (the “receiver”) can cancel and get cash from the vault without any shares burned.
-
Shares remain with attacker to profit later.
Proof of Concept
Attacker calls deposit(1000, victim).
Shares are minted to attacker; stakedAsset[victim] = 1000.
Before start: victim.cancelParticipation() → receives 1000 from vault.
Attacker still holds shares for later payout.
Recommended Mitigation
- remove this code
+ add this code
Updates
Appeal created
bube 19 days ago
Submission Judgement Published Assigned finding tags:
Shares Minted to msg.sender Instead of Specified Receiver
Rewards breakdown
nSLOC
193This contest has a flat reward structure with the following payouts:
100 EXP
20 EXP
2 EXP
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.