BOB Staking — Bonuses obtainable without proper locking

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 63719-h-01-bonuses-obtainable-without-proper-locking-due-to-flawed. Standalone Foundry PoC and full write-up: 63719-h-01-bonuses-obtainable-without-proper-locking-due-to-flawed_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/wrong-condition · reward-theft · account-ownership

Reproduction: a self-contained Foundry PoC that compiles & runs in an isolated project with only forge-std — no fork, no RPC, no anvil_state. Full trace: output.txt. PoC: test/63719-h-01-bonuses-obtainable-without-proper-locking-due-to-flawed_exp.sol.

AuditVault taxonomy: severity/high · sector/staking · platform/pashov · wrong-condition · reward-theft · reward-accounting · timestamp-dependence

Key info#


Impact	HIGH — max-lock bonus paid while stake remains unlocked
Protocol	BOB Staking + BonusWrapper
Vulnerable code	`BobStaking.stake` inconsistent-lock guard
Bug class	Wrong condition: only enforces lock match when stored `lockPeriod != 0`
Finding	Pashov BOB-Staking security review 2025-10-18 · #63719
Report	Pashov BOB-Staking review
Source	AuditVault
Status	Audit finding — resolved per report. Reproduced as a reduced local synthetic.
Compiler	`^0.8.24` (PoC)

TL;DR#

First stake with lockPeriod = 0 sets unlockTimestamp = now and stores lockPeriod = 0.
Second stake with a long lock period still passes the consistency check (guard requires stored lock ≠ 0).
unlockTimestamp is not updated on subsequent stakes.
BonusWrapper pays the long-lock bonus while the position remains unlocked.

The vulnerable code#

SOLIDITY

// FIX: also reject when amountStaked > 0 && lockPeriod differs
if (stakers[receiver].lockPeriod != 0 && stakers[receiver].lockPeriod != lockPeriod) {
    // @> VULN: skipped entirely when stored lockPeriod == 0
    revert InconsistentLockPeriod();
}

Root cause#

Lock-period immutability is only enforced for non-zero prior locks. Zero is treated as "unset" even after a successful stake that already initialized unlock timing.

Preconditions#

Bonus period still active.
lockPeriod = 0 is a valid allowed period.
Reward owner has approved / funded the max bonus.

Attack walkthrough#

Stake 400 BOB via BonusWrapper with lockPeriod = 0 (no bonus, unlocked).
Stake another 400 with lockPeriod = 21 * 30 days.
Wrapper pulls 800 BOB bonus and stakes total; BobStaking accepts without updating lock.
Position holds principal + free bonus while still unlocked.

Diagrams#

flowchart TD A["Stake 400 lockPeriod=0"] --> B["unlockTimestamp = now"] B --> C["Stake 400 with long lock"] C --> D["BonusWrapper pays 800 bonus"] D --> E["VULN: lock check skipped"] E --> F["unlockTimestamp not updated"] F --> G["Free bonus while unlocked"]

Impact#

rewardOwner is drained for lock bonuses without users committing capital to the advertised lock. Timing variants (dust long lock, then large add near expiry) amplify the theft.

Sources#

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 63719-h-01-bonuses-obtainable-without-proper-locking-due-to-flawed_exp (evm-hack-registry mirror).
AuditVault finding: 63719-h-01-bonuses-obtainable-without-proper-locking-due-to-flawed.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync