# Attacker can manipulate the `lockDuration` of other users positions

Broken access check in addToPosition lets anyone donate 1 wei to another user's staking position, recalculating lockDuration and blocking their vote.

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

**Target:** MlumStaking.addToPosition
**Root cause:** _requireOnlyOperatorOrOwnerOf calls ERC721Upgradeable._isAuthorized(msg.sender, msg.sender, tokenId), which always returns true because owner == spender, so any caller passes the check.
**Steps:**
1. Alice creates a position with 100e18 and lockDuration 2 weeks.
2. Admin starts a voting period; Alice's lockDuration equals period duration so she is eligible.
3. Bob calls `addToPosition(1, 1 wei)` on Alice's tokenId after approving 1 wei.
4. lockDuration is recalculated to 1 week, below the minimum, so Alice's `vote` reverts with InsufficientLockTime.
**How found:** Code review of the access control helper: noticed _isAuthorized was called with msg.sender as both owner and spender, making the check tautological.
**Exploitation:** Attacker donates 1 wei to any victim's position via addToPosition, triggering the average lock time recalculation and reducing the victim's lockDuration below the voting threshold.
**Insight:** When an access check delegates to a library function, verify the arguments: passing the same address for owner and spender in _isAuthorized always returns true.