57854 sc medium front running attack allows collection ownership theft

Submitted on Oct 29th 2025 at 08:19:18 UTC by @Aizen09 for Audit Comp | Belongarrow-up-right

  • Report ID: #57854

  • Report Type: Smart Contract

  • Report severity: Medium

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

  • Impacts:

    • Unauthorized minting of NFTs

    • Theft of unclaimed yield

Description

The Belong NFT Factory allows attackers to steal collection ownership by front-running legitimate creators. When someone tries to create a collection, an attacker can copy their signature from the mempool and submit the same transaction with higher gas, becoming the owner and receiving all mint proceeds.

Why it works:

  • Signature only validates collection data (name, symbol, URI) — NOT who can use it.

  • Anyone can call produce() with any valid signature.

  • msg.sender automatically becomes the collection owner.

  • First transaction mined wins — attacker's higher gas executes first.

Vulnerable Code:

SignatureVerifier.sol (Lines 53-72):

Factory.sol (Lines 230-290):

Impact

Severity: HIGH

Losses for Creator:

  • Loses collection ownership permanently

  • Loses 100% of mint revenue (~990 ETH for 10k collection at 0.1 ETH)

  • Cannot use same collection name ever

  • Loses admin control

  • Wastes gas fees on reverted transaction

Gains for Attacker:

  • Becomes permanent collection owner

  • Receives all mint proceeds (99% after platform fee)

  • Full admin control over collection

  • Receives future royalties

  • Cost: Only gas fees

Example: 10,000 NFT collection at 0.1 ETH = 990 ETH stolen (~$2M at $2k/ETH)

1

Modify signature verification so the signature binds to the intended creator (caller). Example change in SignatureVerifier:

And update Factory.sol to pass msg.sender when calling the verifier:

2

Solution: Add Deadline and Nonce (Additional Protection)

Add expiry and replay protection to AccessTokenInfo:

Enforce deadline and nonces in Factory:

These controls together (binding signature to creator + nonce/deadline) prevent the mempool front-running/replay scenario.

Proof of Concept

The following PoC demonstrates the front-running attack and the root cause: signatures do not bind to the caller, so anyone can reuse them.

Test file to create: test/v2/platform/factory-frontrun.test.ts

Run PoC: yarn hardhat test test/v2/platform/factory-frontrun.test.ts

PoC code:

(Note: keep all links and references as-is. No additional changes to URLs or query parameters were made.)

Was this helpful?