An attacker can potentially steal users' tokens during the deposit flow.
There are two related issues in the depositTokensToL2 function. I have combined them because they are likely to be resolved with the same change.
After the victim has approved the token for the bridge, anyone can deposit tokens on behalf of that user using depositTokensToL2() because "from" is inputted as an argument. This could result in unintended token deposits for the victim.
The more critical issue, which is facilitated by the first issue, allows an attacker to deposit tokens into an L2 address they control and subsequently steal those tokens. This second issue is the primary focus of this finding.
The following unit test illustrates the vulnerability.
An attacker can potentially steal tokens by front-running deposits.
Manual review.
One possible change to address both issues is to remove the input for the depositing address in the first argument, "from". Instead, the sender's address can be derived from "message.sender."
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.