The cancelRequest
function in the Starklane bridge contract allows any user to cancel a deposit request, potentially leading to unauthorized cancellations and loss of user funds.
The cancelRequest function (lines 245-258) is designed to cancel a pending L1 to L2 message and return the deposited tokens to the original owner. However, the function lacks proper access control. It doesn't verify that the caller (msg.sender) is the original depositor or an authorized party, hence a malicious actor just have to get a nonce and setup a payload from the LogMessageToL2
event looged in the StarknetMessaging::sendMessageToL2
before constructing a payload that will be used to the request.
The relevant code snippet
The event log that an attacker needs to read from the memepool is gotten from here;
The vulnerability could lead to:
Unauthorized cancellation of legitimate deposit requests
Potential loss or temporary lock of user funds
Disruption of the bridge's normal operation
Loss of user trust in the bridge system
The severity is high due to the potential for direct financial loss to users.
Manual code review
Implement access control in the cancelRequest function:
The process to cancel a message is detailed here: https://docs.starknet.io/architecture-and-concepts/network-architecture/messaging-mechanism/#l2-l1_message_cancellation Since `startRequestCancellation` has the `onlyOwner`, only the owner can begin that process.
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.