The withdrawTokens
function in the Starklane bridge contract allows an attacker to deploy and whitelist an arbitrary ERC721 collection on L1 by exploiting the collection deployment logic when no corresponding L1 collection exists for a given L2 collection.
The vulnerability exists in the withdrawTokens
function:
The function allows processing a request with an empty tokenIds
array.
If collectionL1
is address(0)
, it deploys a new ERC721 collection using parameters from the request.
The newly deployed collection is automatically whitelisted.
An attacker can craft a request with:
A non-existent L2 collection address
Empty tokenIds
array
Arbitrary name
and symbol
This allows the attacker to deploy and whitelist an arbitrary ERC721 collection on L1 without proper authorization.
Unauthorized Collection Deployment: An attacker can deploy arbitrary ERC721 collections on L1.
Whitelist Manipulation: These deployed collections are automatically whitelisted, potentially bypassing security checks.
Bridge Integrity Compromise: This could lead to a mismatch between L1 and L2 collections, compromising the bridge's integrity.
Potential for Further Exploits: The attacker-controlled L1 collection could be used for additional malicious activities.
Manual
Require Non-Empty Token IDs: Ensure that the tokenIds array is not empty in the withdrawTokens function.
solidityCopyrequire(req.tokenIds.length > 0, "Token IDs array cannot be empty");
Separate Collection Deployment: Move the collection deployment logic to a separate function that requires proper authorization (e.g., only callable by the contract owner or a trusted role).
No real impact. Attacker will have to pay the deployment of the new contract even with 0 token, and it won’t have any interest do to that since he won’t take the control of the contract.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.