56896 sc critical staking contract is vulnerable to inflation attack making malicious 1st staker grief the following stakers

triangle-exclamation

#56896 [SC-Critical] staking contract is vulnerable to inflation attack making malicious 1st staker Grief the following stakers

  • Submitted on Oct 21st 2025 at 15:54:34 UTC by @rzizah for Audit Comp | Belongarrow-up-right

  • Report ID: #56896

  • Report Type: Smart Contract

  • Report severity: Critical

  • Target: https://github.com/belongnet/checkin-contracts/blob/main/contracts/v2/periphery/Staking.sol

  • Impacts: Griefing (no profit motive required — attacker can harm other users or protocol)

Description

Brief / Intro

The staking contract uses the standard ERC-4626 vault implementation and relies on the default _decimalsOffset value. This enables an attack where the first staker can grief later stakers, causing them to receive zero (or fewer) shares for their deposits and suffer loss of funds.

Vulnerability Details

The contract uses a standard ERC-4626 vault which normally prevents many inflation attacks. However, because the default _decimalsOffset is used, the vault becomes vulnerable to a grieving / inflation-style attack where a malicious first staker manipulates the asset-to-share ratio to harm subsequent stakers.

The attack flow is described below.

1

Setup: attacker becomes first depositor

  • Attacker back-runs the pool creation transaction (or otherwise ensures they are the first depositor).

  • Attacker deposits a minimal amount to receive 1 share: deposit(1). Now totalAssets() == 1 and totalSupply() == 1.

2

Victim attempts to deposit

  • A victim attempts to deposit a larger amount (e.g., 50e18).

3

Attacker inflates asset balance

  • Attacker front-runs the victim's deposit and directly transfers a large amount of assets into the vault (e.g., asset.transfer(100e18) to the vault).

  • This artificially inflates totalAssets() while totalSupply() remains low (1), increasing the asset-per-share price.

4

Victim's deposit mints zero shares

  • The victim's deposit executes after the direct transfer inflation.

  • Due to the inflated asset-per-share ratio, the victim receives zero (or significantly fewer) shares for their deposit.

5

Attacker redeems inflated value

  • After any lock/unlock period, the attacker redeems their minimal share(s) and receives a large portion of the assets — these assets include amounts the attacker used to inflate the vault and the victim’s deposit, effectively causing the victim to lose funds.

6

Repetition / chaining

  • The attacker can repeat the same technique for subsequent stakers by directing transfers to the vault right before their deposits, causing partial or total loss for innocent stakers.

Impact Details

Total or partial loss of funds for honest stakers; attacker can grief other stakers without needing a profit motive (though profit can be extracted as described).

References

  • Vulnerable code location: https://github.com/belongnet/checkin-contracts/blob/6b78ead6186c49cfec2787522460ddd516579a6b/contracts/v2/periphery/Staking.sol#L242-L246

Relevant excerpt:

Proof of Concept (test)

Add the following test to staking.test.ts under describe('Staking features'). Run on a local hardhat network with prefunded accounts:

yarn hardhat test --network hardhat --grep "is vulnerable to inflation attack" ./test/v2/platform/staking.test.ts

The test shows that an innocent user (user2) receives 0 shares and loses deposited funds after the attacker inflates the vault.

Was this helpful?