@markcarey
## Streme V2 Staking Contract Exploit
On December 10, 2025, a vulnerability was exploited in the **v2** version of the Streme staking contracts. This vulnerability allowed an attacker to stake tokens without actually depositing them into the staking contract. As a result, the attacker was able to receive a portion of the streaming staking rewards and, if left unaddressed, would have had the ability to unstake and potentially drain all tokens held in the affected contracts.
Temporary mitigation actions were taken immediately. A permanent resolution plan was prepared, tested, and subsequently deployed over the following days. The vulnerability has been fully patched, and all affected staking contracts have been migrated to secure versions. No user funds were lost, and staking rewards have continued to stream uninterrupted throughout the incident. No action is required from affected stakers.
We estimate that the attacker received approximately **$25 USD** in staking rewards. Additional details are provided below.
### Quick Notes
* **BEAMR was NOT affected.** It was deployed using newly patched staking contracts.
* **STREME and all other βv1β tokens were NOT affected.** The vulnerability only existed in v2 staking contracts.
---
## Affected Tokens
The staking contracts for the following 19 Streme tokens were exploited:
**BANGER, LETS, NEWS, V2, ARRR, BASETARD, BSANTA, MIRAGE, NO, ROGUE, TYTG, FAKE (...a806), FAKE (...a0e6), NAND, VOLTS, EMERALD, bee, MON (fake: ...e2cb1), PRESALE**
---
## Incident & Response Timeline
* **8:33 PM EST, Dec 10** β We were alerted to unusual staking behavior by Farcaster user **@kender7**, deployer of the affected V2 token. Thank you, Kender.
* **9:30 PM EST, Dec 10** β Streaming rewards to the attacker for BANGER were halted.
* **9:40 PM EST, Dec 10** β With assistance from Fran at Superfluid, the vulnerability was identified.
* **11:49 PM EST, Dec 10** β A patched staking contract was deployed, ensuring future deployments were secure.
* **12:30 AM EST, Dec 11** β First draft of recovery plan and contracts completed.
* **Dec 11 β Dec 17** β Attacker stakes were repeatedly locked while the recovery plan, contracts, and scripts were refined, tested, and reviewed.
* **12:00 PM EST, Dec 18** β Recovery contracts deployed to Base Mainnet.
* **12:10 PM EST, Dec 18** β Recovery executed and all 19 affected staking contracts were safely migrated.
---
## Vulnerability Explanation
`StakedTokenV2.sol` is a smart contract used to deposit Streme tokens in exchange for staked tokens on a 1:1 basis. It also updates member units in a Superfluid distribution pool (GDA), which streams staking rewards in real time.
The v2 version introduced optional delegation features that allow staking rewards to be streamed to a secondary address while the staked tokens remain in the userβs wallet. These delegation features were never exposed through the Streme user interface and were effectively unused.
The vulnerability existed in the `stakeAndDelegate` convenience function, which attempted to stake and delegate rewards in a single transaction. Internally, it invoked the staking function using the Solidity `this` keyword:
```
this.stake(msg.sender, amount);
```
Using `this` changes the execution context such that `msg.sender` becomes the contract itself rather than the original transaction sender. As a result, when the `stake()` function attempted to transfer tokens from the staker to the contract, it instead transferred tokens from the contract to itself.
Because the staking contract already held all deposited tokens, the attacker was able to mint staked tokens without depositing any new funds. This process could be repeated indefinitely, increasing the attackerβs share of the staking rewards stream.
On multiple occasions, we successfully halted reward streams to the attacker but were unable to burn their staked tokens. However, we were able to keep those tokens locked, preventing the attacker from unstaking.
---
## Resolution Plan
At a high level, the resolution involved migrating all affected tokens to newly deployed, patched staking contracts while permanently disabling the vulnerable ones. All staker balances, unlock dates, and reward streams remain unchanged, and no user action is required.
To recover the Streme tokens from the vulnerable contracts, we intentionally leveraged the same vulnerability to stake enough tokens for a recovery contract to obtain a 100% claim on the deposited tokens. Using admin permissions, the lock duration was temporarily set to zero, allowing the recovery contract to immediately unstake all tokens.
The recovery process also:
* Disabled transfers of the old staked tokens
* Removed any GDA units associated with the attacker
* Deployed replacement staking contracts
* Transferred recovered Streme tokens into the new contracts
The new staking contracts reuse the same Superfluid GDA pools, ensuring that staking reward streams continued without interruption.
The replacement contracts include migration features that allow stakers to transition automatically, without requiring explicit action.
---
## Going Forward
Within hours of the incident, a patched version of the staking contract was deployed. This version, which does not contain the vulnerability, has been used for **all new token deployments since 11:49 PM EST on December 10, 2025**.
---
## Acknowledgements
We extend our sincere thanks to **@kender7** for promptly reporting the issue, and to members of the **Superfluid team** for their assistance in identifying the vulnerability, developing the recovery contract, and reviewing both the recovery and updated staking contracts. Your support was invaluable.
---