57875 sc medium signature bypass lets creators alter key accesstoken parameters before deployment
Submitted on Oct 29th 2025 at 10:43:56 UTC by @spongebob for Audit Comp | Belong
Report ID: #57875
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
Description
SignatureVerifier.checkAccessTokenInfo only signs name, symbol, contractURI, and feeNumerator. Every other field in AccessTokenInfo is omitted from the hash, so a signature remains valid after mutating payment terms, transferability, supply, pricing, or expiry data before submission (https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/utils/SignatureVerifier.sol#L49).
Factory.produce trusts the caller-supplied struct after that limited check and forwards it verbatim into the AccessToken initializer, only normalizing paymentToken == address(0) to the default currency:
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/platform/Factory.sol#L236
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/platform/Factory.sol#L270
The AccessToken proxy persists and enforces all of those unsupervised fields (royalties, paymentToken, prices, transferable, maxTotalSupply, etc.) for minting, transfers, and payments, with no further validation against a signed payload:
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/tokens/AccessToken.sol#L130
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/tokens/AccessToken.sol#L149
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/tokens/AccessToken.sol#L174
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/tokens/AccessToken.sol#L303
https://github.com/immunefi-team/audit-comp-belong/blob/a17f775dcc4c125704ce85d4e18b744daece65af/contracts/v2/tokens/AccessToken.sol#L374
A malicious creator can therefore take an approved signature, alter unchecked fields (e.g., switch paymentToken, lift the supply cap, toggle transferable) and deploy a collection that violates the off-chain approval assumptions — effectively bypassing the policy the signature was meant to enforce.
No subsequent on-chain step revalidates or constrains those parameters, so the platform currently depends entirely on caller honesty for critical configuration.
Impact
This is a Critical-severity attack path in practice: unchecked fields include maxTotalSupply, transferable, pricing, etc. A creator with an approved signature can mutate these before calling produce, allowing them to mint or configure collections in ways the signer never approved (e.g., removing a supply cap or flipping transferability). The signature remains valid because it doesn't cover those fields, so the factory cannot distinguish the tampered payload.
The realistic likelihood is high. The platform already issues signatures to creators, and the code doesn’t bind those signatures to the critical fields. Any creator who gets an approval can tweak unsigned parameters locally before calling produce. No extra privileges or technical skill are required — just a script or manual transaction edit.
Recommendation
Expand the signed digest in checkAccessTokenInfo to cover every AccessToken field that must stay immutable (payment token, transferability, supply, prices, expiry, etc.), or alternatively recompute and validate that complete digest inside Factory.produce before deploying.
Proof of Concept
Run this diff
Was this helpful?