57677 sc medium signature replay in venuedeposit enables affiliate referral code hijacking leading to unauthorized commission theft

Submitted on Oct 28th 2025 at 05:10:11 UTC by @chupinexx for Audit Comp | Belongarrow-up-right

  • Report ID: #57677

  • Report Type: Smart Contract

  • Report severity: Medium

  • Target: https://github.com/immunefi-team/audit-comp-belong/blob/main/contracts/v2/platform/BelongCheckIn.sol

Impacts

  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

  • Direct theft of any user NFTs, whether at-rest or in-motion, other than unclaimed royalties

  • Affiliate steal all venues funds (via repeated commission theft)

Description

Brief / Intro

The signature scheme used to authorize venueDeposit transactions lacks any nonce or replay-prevention mechanism. Every signature issued for a venue deposit can be reused indefinitely. An affiliate who obtains a valid signature from a venue's first deposit can replay it and front-run any subsequent deposit the venue makes, causing commissions to be routed to the attacker instead of the intended affiliate.

Vulnerability Details

The backend signature for venue deposits only covers four static fields:

Critical missing elements:

  • No nonce (no counter to track signature usage)

  • No timestamp (no expiration)

  • No amount binding (amount is not part of the signed payload)

The VenueInfo struct shows what is signed vs. what isn't:

Although referralCode is included in the signed payload, without a nonce/timestamp it can be replayed indefinitely for future deposits.

Step-by-Step Attack Execution

1

First deposit with Affiliate A

  • Venue makes an initial deposit using Affiliate A's referral code.

  • Affiliate A receives commission and now possesses signature_A which proves (venue, referralCode_A, uri, chainId).

  • Because the signature lacks nonce/timestamp, signature_A remains valid forever.

2

Venue plans second deposit with Affiliate B

  • Later, the venue initiates a second deposit intending to reward Affiliate B (different referral code).

  • Backend issues signature_B for (venue, referralCode_B, uri, chainId).

3

Affiliate A front-runs the second deposit

  • Affiliate A observes the pending transaction and constructs a front-running transaction using:

    • same venue and uri

    • OLD referralCode (referralCode_A)

    • NEW amount from the pending transaction

    • signature_A (replayed)

  • Affiliate A broadcasts with higher gas to execute first.

4

Signature validation passes

  • The contract validates the signature using only (venue, referralCode, uri, chainId).

  • Because those fields match what the backend signed for Affiliate A originally, the signature validates—even though it was already used.

  • There is no check for signature reuse, nonce, or timestamp.

5

Affiliate A steals commission

  • The contract calculates the affiliate fee from the NEW amount, but attributes it to Affiliate A (the replayed referralCode_A).

  • Affiliate A receives the commission for the second deposit instead of Affiliate B.

  • If venue provided no new affiliate, the attack still steals the venue's affiliate fee (e.g., 10%).

Impact Details

  • Direct and ongoing financial loss for affiliates: Any future affiliate commissions from a venue can be stolen by a previous affiliate who holds a valid signature. Over time this could amount to significant stolen commissions.

  • Venue loss: If the venue deposits without a new referral code, previous affiliates can still replay signatures and steal a percentage (e.g., 10%) of the venue's deposits.

References

  • https://github.com/belongnet/checkin-contracts/blob/6b78ead6186c49cfec2787522460ddd516579a6b/contracts/v2/platform/BelongCheckIn.sol#L382

  • https://github.com/belongnet/checkin-contracts/blob/6b78ead6186c49cfec2787522460ddd516579a6b/contracts/v2/platform/BelongCheckIn.sol#L389-L394

Proof of Concept

Add this test to the existing test suite in test/v2/platform/belong-check-in.test.ts

Run the test:

The test demonstrates:

  1. Setup two affiliates (A and B) with distinct referral codes

  2. First deposit with Affiliate A (legitimate commission)

  3. Venue intends to use Affiliate B for the second deposit

  4. Affiliate A front-runs using a replayed signature from the first deposit

  5. The replayed signature validates and Affiliate A receives the second commission

  6. Affiliate B receives zero commission while Affiliate A steals it

Was this helpful?