# Users can deny the vault from claiming reward tokens

Anyone can front-run the vault's reward claim by calling Convex/Aura getReward directly, making the before/after balance delta zero and permanently stranding reward tokens in the vault.

- Payout: Contest reward
- Severity: high
- Program: Leveraged Vaults
- Credited: DenTonylifer
- Disclosed: 2024-06-18
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2024-06-leveraged-vaults-judging/issues/63
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-leveraged-vaults%3AH-7
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:race-window technique:source-review vuln:business-logic vuln:reward-distribution

**Target:** VaultRewarderLib reward-claim logic against Convex/Aura reward pools
**Root cause:** _claimVaultRewards measures claimed rewards as balanceAfter - balanceBefore, but the external getReward is permissionless, so a third party can push rewards to the vault before the snapshot, yielding a zero delta.
**Steps:**
1. Vault holds shares in Convex/Aura reward pool; rewards accrue to vault address.
2. Attacker observes pending _claimVaultRewards tx and front-runs by calling `IAuraRewardPool(rewardPool).getReward(vault, true)` (or Convex equivalent) directly.
3. Reward tokens transfer to vault before the vault's own claim executes.
4. Vault's _claimVaultRewards records balancesBefore already including the tokens; _executeClaim returns nothing new; `balanceAfter - balancesBefore[i]` = 0.
5. _accumulateSecondaryRewardViaClaim records zero; tokens remain stuck in vault with no accounting or rescue path.
**How found:** Code review of the balance-delta accounting in _claimVaultRewards combined with reading the external Convex/Aura getReward implementations, noticing they are unguarded and callable for any account.
**Exploitation:** Zero-capital griefing: monitor mempool for _claimVaultRewards, submit permissionless getReward(vault) with higher gas; rewards land in vault but are never credited to shares, permanently lost to users/protocol.
**Insight:** When a contract measures income via before/after balance snapshots, check whether the income source is permissionlessly pushable by third parties; any unguarded external claim/transfer to the contract lets an attacker pre-fill the balance and zero out the delta.