57891 sc medium signature replay lets attackers hijack nft collection deployment
Submitted on Oct 29th 2025 at 11:39:30 UTC by @spongebob for Audit Comp | Belong
Report ID: #57891
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
https://github.com/immunefi-team/audit-comp-belong/blob/0cbcde6fd80dbc55a9e3403c8e5a74827dea19e2/src/snip12/produce_hash.cairo#L5 shows the signed payload commits to the intended creator_address (alongside name/symbol/URI/royalty).
During minting the factory recreates that struct from caller-supplied data (https://github.com/immunefi-team/audit-comp-belong/blob/0cbcde6fd80dbc55a9e3403c8e5a74827dea19e2/src/nftfactory/nftfactory.cairo#L289) and verifies the signature with the configured signer, but after validation it discards the provided creator_address and instead records get_caller_address() everywhere the collection ownership matters (https://github.com/immunefi-team/audit-comp-belong/blob/0cbcde6fd80dbc55a9e3403c8e5a74827dea19e2/src/nftfactory/nftfactory.cairo#L321-L389).
Because there is no equality check between info.creator_address and the transaction sender, any account that learns a valid signature can replay or front-run it, keeping the approved creator value in the struct to pass signature verification while ending up as the on-chain creator/owner. The attacker therefore captures the deployed collection, royalties, and referral attribution which is an unauthorized NFT mint.
Impact
I consider this a Critical impact – it meets the “Unauthorized minting of NFTs” criterion. An attacker can front-run or replay any valid signature to deploy the collection under their address, taking control of the drop and any revenue it generates.
Creators must share their signed payload with the factory (often via a marketplace/backend), so any compromised backend, leaked logs, or even a mempool observer can capture that signature. Because the on-chain check doesn’t tie it to the intended caller, the attacker can immediately replay it, and the factory has no way to distinguish them. No unusual prerequisites or high costs are involved — access to a valid signature is sufficient, so exploitation is practical and expected once signatures are exposed.
Recommendation
Bind the signature to the intended creator (and optionally replay-protect it). Extend the ProduceHash struct and its hash to include the authorized creator address (and any other execution-critical fields like deadline/nonce). Require _produce to compare that signed creator with get_caller_address() before deploying. This ensures only the signer-authorized account can mint, and prevents front-running/replay by other callers.
Proof of Concept
Run the diff:
Was this helpful?