TempleDAO StaxLPStaking Access Gap

On October 11, 2022, TempleDAO lost approximately $2.3 million (1,831 ETH) when an attacker exploited a missing access-control check in the StaxLPStaking contract's migrateStake() function. The function was meant to migrate a user's own staked position to a new contract — but it did not verify that the caller owned the position being migrated.

What happened

TempleDAO's StaxLPStaking contract let users stake LP tokens. It included a migrateStake(address oldStaking, uint256 amount) function intended for users to move their own stake to an upgraded staking contract.

The fatal flaw: migrateStake() trusted the caller-supplied parameters without verifying the caller actually owned the stake being migrated. It called the old staking contract's migrateWithdraw for an arbitrary address, then credited the result — meaning any caller could migrate (and thereby withdraw) any other staker's entire position to a destination they controlled.

The attack was correspondingly trivial:

1. The attacker called migrateStake() specifying a destination they controlled and the TempleDAO staking contract holding all user stakes.
2. The function, lacking the ownership check, migrated and released the staked LP tokens to the attacker.
3. The attacker unwrapped the LP position and walked with 1,831 ETH ($2.3M).

The entire exploit was a single transaction exploiting a single missing require.

Aftermath

• TempleDAO paused affected contracts and engaged the attacker via on-chain messages.
• The team published a post-mortem identifying the missing caller-ownership validation as the sole root cause.
• The stolen funds were laundered through Tornado Cash; recovery was minimal.

Why it matters

TempleDAO is one of the purest examples in the catalogue of the "missing access-control check" bug class — distinct from oracle manipulation, reentrancy, or economic exploits. There was no clever flash loan, no price manipulation, no novel mechanism. There was a function that should have checked msg.sender owned the position and didn't.

The structural lesson is almost embarrassingly simple but recurs constantly:

Every function that moves a user's assets must verify the caller is authorised to move those specific assets. Not "is the caller a valid user" — "does the caller own the exact position this call affects."

The pattern repeats across the catalogue: TempleDAO (migrateStake), Exactly Protocol (unvalidated market), Hedgey Finance (unchecked claimLockup), Seneca (Chamber drain). Each is a function that performs a privileged or fund-moving operation based on caller-supplied parameters, without validating the caller's relationship to the affected assets.

These bugs are trivially caught by even cursory audit or by basic access-control unit tests ("can address B migrate address A's stake?"). The frequency with which they ship anyway — particularly in migration and periphery functions written quickly and late — is one of the catalogue's recurring quiet themes.