The retryMessage function in the L2MessageReceiver contract is susceptible to a re-entrancy attack. The function first executes business logic (_nonblockingLzReceive) before updating the contract's state (delete failedMessages[...]). This order of operations could potentially allow an attacker to re-enter the function before the state is updated.
And then _nonblockingLzReceive will mint MOR tokens to user
Ideally, the deletion should occur before calling _nonblockingLzReceive to prevent potential re-entrancy.
If exploited, an attacker could repeatedly call retryMessage for the same nonce_, potentially leading to unexpected behavior such as duplicate token minting. This poses a significant security risk, potentially leading to financial losses or integrity issues in the token distribution mechanism.
Probability : Low
Impact : High
VsCode
Implement a CEI pattern for this function :
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.