57327 sc medium title front running leads to denial of service and unauthorized referral farming in creation functions

  • Submitted on: Oct 25th 2025 at 09:20:46 UTC by @BBHGuild for Audit Comp | Belongarrow-up-right

  • Report ID: #57327

  • Report Type: Smart Contract

  • Report severity: Medium

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

  • Impacts: Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief / Intro

The Factory contract's creation functions (produce, produceCreditToken, and deployVestingWallet) are vulnerable to front-running. An attacker observing the mempool can intercept valid, signed parameters intended for these functions and submit their own transaction using those parameters first. This preempts the legitimate user's transaction, causing it to fail due to a deterministic address collision (salt reuse). This results in a Denial of Service (DoS) for the user. Additionally, for the produce function, the attacker can insert their own referral code, enabling unauthorized referral farming.


Vulnerability Details

The core issue lies in how signatures are validated for the creation functions within the Factory contract. Functions like produce, produceCreditToken, and deployVestingWallet rely on parameters (AccessTokenInfo, ERC1155Info, VestingWalletInfo) that include a signature generated by the authorized signerAddress. This signature correctly verifies that the parameters themselves were approved by the signer.

However, the functions do not validate that the transaction sender (msg.sender) is authorized to use these signed parameters or is the intended recipient/creator associated with the payload. They only check the signature's validity against the signerAddress.

The factory uses LibClone.cloneDeterministic or LibClone.deployDeterministicERC1967, which employ CREATE2. The address of the new contract is deterministically calculated based on the deployer's address (address(this) which is the factory), a salt, and the creation code hash. The salt used in these functions is derived from parameters within the signed payload (e.g., keccak256(abi.encode(name, symbol)) for produce and produceCreditToken).

An attacker (e.g., a block builder or someone monitoring the mempool) can execute the following sequence:

1

Observe

Identify a pending transaction calling produce, produceCreditToken, or deployVestingWallet with valid signed parameters.

2

Copy

Extract the signed parameters (accessTokenInfo, creditTokenInfo, or vestingWalletInfo including the signature field) from the observed transaction's calldata.

3

Front-run

Submit their own transaction calling the same factory function with the copied parameters. For produce, the attacker can also substitute their own referralCode. Make it execute before the victim's transaction (e.g., higher gas price).

4

Success (Attacker)

The attacker's transaction succeeds because the signature is valid (it was signed by the signerAddress for the given parameters) and the deterministic address has not been created yet. The contract is deployed at the predicted address. In the case of produce, the attacker's referral code is associated with the creation.

5

Failure (Victim)

The legitimate user's transaction later executes but fails. The CREATE2 operation reverts because the contract at the deterministic address (derived from the same salt) already exists, leading to errors like Factory.TokenAlreadyExists or Factory.VestingWalletAlreadyExists. This results in a Denial of Service (DoS) for the user.

The included proof of concept demonstrates this clearly for the produce function: attacker successfully calls produce using valid signed parameters intended for a victim and an attacker-controlled referral code. The victim's subsequent call with the same signed parameters reverts.

https://gist.github.com/emilesean/81f3b8e2336d7f43018f97a238a1d115


Proof of Concept


Remediation

circle-info

Enhance access control for creation functions. Options include:

  • Include msg.sender in the signed message hash so signatures are bound to the intended caller (e.g., signer signs hash that includes intended creator address).

  • Verify within the function that msg.sender matches an intended creator/beneficiary derived from the signed payload (explicit check).

  • Alternatively, incorporate a nonce or ephemeral value tied to the intended caller into the signed payload to prevent reuse by others. These changes prevent an attacker from reusing signed parameters seen in the mempool.

Was this helpful?