XAUT0 BSC Deployment

Upon successful receipt of inbound message hashes, the executor invokes lzReceive. During this process, LayerZero lazily updates the nonce within _clearPayload.

if (_nonce > currentNonce) {
            unchecked {
                // try to lazily update the inboundNonce till the _nonce
                for (uint64 i = currentNonce + 1; i <= _nonce; ++i) {
                    if (!_hasPayloadHash(_receiver, _srcEid, _sender, i)) revert Errors.LZ_InvalidNonce(i);
                }
                lazyInboundNonce[_receiver][_srcEid][_sender] = _nonce;
            }
}

https://github.com/LayerZero-Labs/LayerZero-v2/blob/9c741e7f9790639537b1710a203bcdfd73b0b9ac/packages/layerzero-v2/evm/protocol/contracts/MessagingChannel.sol#L134 While updating the nonce, the protocol enforces that for a given message with nonce n, all messages with nonce < n must be at least inbounded (execution is not required). This validation is implemented via a loop. If there is a long queue of inbounded messages prior to nonce n, the loop may become expensive in terms of gas.

Description:

One might assume that as earlier messages get executed (e.g., message 501 in a queue of 1000), the pressure on subsequent messages reduces. This assumption aligns with LayerZero’s design, as noted in the code:

/// @dev if a lot of messages are queued, the messages can be cleared with a smaller step size to prevent OOG

However, this assumption breaks if the queued messages are unexecutable.

Attack Scenario

An attacker can deliberately create a large number of inbounded but unexecutable messages, causing the loop to run out of gas when processing later messages. This is feasible in OApps such as Tether (USDT), where:

• Cross-chain transfers to blacklisted addresses will revert on the destination chain.
• Transfers to certain contract addresses may also revert. By repeatedly sending such transactions, an attacker can fill the inbound queue with messages that cannot be executed.

Feasibility Analysis

At first glance, this may appear impractical due to high gas requirements (e.g., ~16M gas per transaction on EVM). However, this overlooks executor behavior:

• Executors are only incentivized to spend the gas specified during message submission.
• If the configured gas limit is reasonable (e.g., 300k), an attacker would only need ~150 such failing messages to create a clog.

Impact

This can temporarily block the processing of subsequent messages (i.e., a denial-of-service on the messaging channel). However, this does not result in permanent blockage or loss of funds.

Mitigation / Design Consideration

LayerZero provides a skip mechanism:

• OApp owners or delegates can call skip on the endpoint to manually advance the nonce.
• This clears the blockage and restores normal operation.

Severity

This issue is not Critical or High severity because:

• No funds are lost.
• The blockage is temporary and can be resolved via skip. However, it represents a valid operational risk that can disrupt message processing.

Consider monitoring queued inbound messages on destination chains, detecting abnormal buildups of unexecutable messages, and proactively intervening using the skip function when necessary.