Staking Vault - Noon Capital (Stablecoin)

The sendTokensViaHyperlane function in StakedUSNBasicOFTHyperlane.sol and StakingVaultOFTUpgradeableHyperlane.sol lacks critical validation checks before burning or locking tokens. This creates a vulnerability due to validation asymmetry between source and destination chains.

The implementation in StakedUSNBasicOFTHyperlane.sol demonstrates the issue:

// In sendTokensViaHyperlane (source chain):
function sendTokensViaHyperlane(uint32 _destinationDomain, address _recipient, uint256 _amount) external payable {
    if (!hyperlaneEnabled) revert HyperlaneNotEnabled();
    if (_amount == 0) revert InvalidAmount();
    // Missing zero address check for _recipient
    // Missing blacklist check for _recipient
    
    bytes32 remoteToken = remoteTokens[_destinationDomain];
    if (remoteToken == bytes32(0)) revert RemoteTokenNotRegistered();

    // Burn tokens first - BEFORE ANY RECIPIENT VALIDATION
    _burn(msg.sender, _amount);

    // ...message encoding and dispatch...
}

While the contract correctly enforces blacklisting in the _update function:

function _update(address from, address to, uint256 amount) internal virtual override {
    if (blacklist[from] || blacklist[to]) revert BlacklistedAddress();
    super._update(from, to, amount);
}

This creates a vulnerability with two main failure modes:

1. Zero Address Recipients: If a user sends tokens to address(0), the tokens are burned on the source chain, but the destination's handle() function will revert with if (recipient == address(0)) revert InvalidRecipient();

2. Blacklisted Recipients: If a user sends tokens to a blacklisted address, the tokens are burned on the source chain, but when the destination chain tries to mint them via _mint(recipient, amount), it will internally call _update() which will revert with BlacklistedAddress() due to the blacklist check.

In both cases, tokens are permanently removed from circulation on the source chain, but never minted on the destination chain. This results in permanent loss of funds with no recovery mechanism.

Implement comprehensive validation in the sendTokensViaHyperlane function before burning any tokens:

function sendTokensViaHyperlane(uint32 _destinationDomain, address _recipient, uint256 _amount) external payable {
    if (!hyperlaneEnabled) revert HyperlaneNotEnabled();
    if (_amount == 0) revert InvalidAmount();
    if (_recipient == address(0)) revert InvalidRecipient();
    if (blacklist[_recipient]) revert BlacklistedAddress();
    
    bytes32 remoteToken = remoteTokens[_destinationDomain];
    if (remoteToken == bytes32(0)) revert RemoteTokenNotRegistered();
    
  
    // ... rest of the function
}

SOLVED: The suggested mitigation was implemented by the Noon Capital team.