57089 sc medium unauthorized collection hijack via unsigned creator

Submitted on Oct 23rd 2025 at 11:40:28 UTC by @OxPrince for Audit Comp | Belongarrow-up-right

  • Report ID: #57089

  • Report Type: Smart Contract

  • Report severity: Medium

  • Target: https://github.com/immunefi-team/audit-comp-belong/blob/feat/cairo/src/nftfactory/nftfactory.cairohttps://github.com/immunefi-team/audit-comp-belong/blob/feat/cairo/src/nftfactory/nftfactory.cairo

  • Impacts: Unauthorized minting of NFTs

Description

Brief/Intro

NFTFactory.produce lets anyone supply a signed payload to deploy a new NFT collection. The off-chain signer is supposed to authorize a specific creator off-chain, but the message that gets signed does not include the intended creator’s address. As a result, the contract never verifies that the caller is the party that the signer approved.

Vulnerability Details

1

Step: Signed message composition

The message that must be signed only includes name_hash, symbol_hash, contract_uri, and royalty_fraction (src/snip12/produce_hash.cairo:5-28). There is no field tying the signature to a specific caller.

2

Step: On-chain storage and creator assignment

When the transaction executes, _produce stores get_caller_address() as the new collection’s creator and permanently marks the (name_hash, symbol_hash) pair as used (src/nftfactory/nftfactory.cairo:253-354).

3

Step: Exploitation via front-running / signature replay

Because the signature is caller-agnostic, any address that observes or obtains the signature can front-run the intended owner and call produce first. The signature check passes, the attacker becomes the recorded creator, and the legitimate user is permanently blocked by the NFT_EXISTS guard.

Note: The comment in the hash function (“This can be a field within the struct, it doesn't have to be get_caller_address()”) signals the developer intent to bind some actor to the signature, but that intent was never implemented.

Impact Details

An attacker who copies an authorized payload—e.g., by front-running the intended transaction—can:

  • Deploy the collection under their own address.

  • Control the newly deployed NFT contract and any referral proceeds.

  • Prevent the real creator from ever deploying the same collection name/symbol.

This breaks the trust model of the factory and results in total loss of control for the legitimate project team.

References

Add any relevant links to documentation or code

Proof of Concept

The following test demonstrates front-run hijack of the produce flow. The attacker reuses a valid signature produced for an intended creator and calls produce first, becoming the recorded creator and causing the legitimate creator's later attempt to revert with NFT is already exists.

chevron-righttest_nftfactory.cairo (Proof of Concept)hashtag

Was this helpful?