# Voting and bribe rewards can be hijacked during emergency unlock by already existing positions

During emergency unlock, addToPosition() stays unrestricted, letting pre-existing 1-wei positions add large amounts and hijack Voter voting power and bribe rewards.

- Payout: Contest reward
- Severity: medium
- Program: Magicsea
- Credited: ChinmayF
- Disclosed: 2024-07-15
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-06-magicsea-judging/issues/290
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-06-magicsea%3AM-5
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:incomplete-fix technique:source-review vuln:access-control vuln:business-logic vuln:governance

**Target:** MlumStaking.addToPosition / Voter voting
**Root cause:** addToPosition() lacks the emergencyUnlock check applied in _lockPosition(), so existing positions can increase amountWithMultiplier and thus voting power while all other entry paths (createPosition, renewLock, extendLock) are blocked.
**Steps:**
1. Pre-plan: open many 1-wei positions with long lockDuration so they satisfy Voter minimumLockTime.
2. Wait for admin to activate emergencyUnlock.
3. Call `addToPosition(positionId, largeAmount)` on each pre-existing position; multiplier caps at 1x but raw amount (and vote weight) grows.
4. Vote in the running Voter period with inflated weight; no new positions can enter since createPosition sets lockDuration=0 and renew/extend revert.
**How found:** Code-reading comparison of position-modifying functions: noticed renewLock/extendLock revert during emergency unlock and createPosition yields lockDuration=0, but addToPosition has no such guard, then reasoned about voting eligibility via minimumLockTime in Voter.sol.
**Exploitation:** Attacker pre-creates many 1-wei long-lock positions, then during an active emergencyUnlock tops them up via addToPosition and votes, monopolizing vote weight to steer LUM emissions to chosen pools and capture bribe rewards while honest users cannot add voting power.
**Escalation:** Scaling across many pre-created positions amplifies vote share; affects both LUM emission direction and bribe reward distribution.
**Insight:** When a contract has an emergency/pause mode, enumerate every state-mutating function and diff their guards; the one function missing the pause check (here addToPosition) is where weight/balance-based governance or reward math can be inflated using pre-existing state.
