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.