Denial-of-Service (DoS) Vulnerability in ERC1155 Token Minting Process

[hats-bug-reporter[bot]]

Github username: @Jelev123 Twitter username: zhulien_zhelev Submission hash (on-chain): 0xb2e380e01ac8dafd1d9dac580b4228eab144d453065df9c67ae016c9a902cb54 Severity: medium

Description: Description\ The function _mintAndUpdateTotalSupply call _mint. The code depends on onERC1155Received callback being implemented by the receiving contract to check ERC1155 implementation, if the receiver contract doesn't implement onERC1155Received the transaction will revert.

Attack Scenario\ A user with bad intentions can cause Dos

1. Proof of Concept (PoC) File

   function _mintAndUpdateTotalSupply(address _account, uint256 _id, uint256 _value, bytes memory _data) internal {
       _mint(_account, _id, _value, _data);
       ..snip
   }

   function _mint(address to, uint256 id, uint256 value, bytes memory data) internal {
      ..snip
       _updateWithAcceptanceCheck(address(0), to, ids, values, data);
   }

   function _updateWithAcceptanceCheck(
       address from,
       address to,
       uint256[] memory ids,
       uint256[] memory values,
       bytes memory data
   ) internal virtual {
       _update(from, to, ids, values);
       _acceptanceCheck(from, to, ids, values, data);
   }

   function _acceptanceCheck(
       address _from,
       address _to,
       uint256[] memory _ids,
       uint256[] memory _values,
       bytes memory _data
   ) internal {
       if (_to != address(0)) {
           address operator = _msgSender();
           if (_ids.length == 1) {
               uint256 id = _ids.unsafeMemoryAccess(0);
               uint256 value = _values.unsafeMemoryAccess(0);
               _doSafeTransferAcceptanceCheck(operator, _from, _to, id, value, _data);
           } else {
               _doSafeBatchTransferAcceptanceCheck(operator, _from, _to, _ids, _values, _data);
           }
       }
   }

   function _doSafeBatchTransferAcceptanceCheck(
       address operator,
       address from,
       address to,
       uint256[] memory ids,
       uint256[] memory values,
       bytes memory data
   ) private {
       if (to.code.length > 0) {
           try IERC1155Receiver(to).onERC1155BatchReceived(operator, from, ids, values, data) returns (bytes4 response)
           {
               if (response != IERC1155Receiver.onERC1155BatchReceived.selector) {
                   // Tokens rejected
                   revert ERC1155InvalidReceiver(to);
               }
           } catch (bytes memory reason) {
               if (reason.length == 0) {
                   // non-ERC1155Receiver implementer
                   revert ERC1155InvalidReceiver(to);
               } else {
                   /// @solidity memory-safe-assembly
                   assembly {
                       revert(add(32, reason), mload(reason))  <---
                   }
               }
           }
       }
   }

Recommendation

There are many ways to handle this issue

[benjaminbollen]

Thank you for your report on the potential Denial-of-Service (DoS) vulnerability in the ERC1155 token minting process. After careful review, we've determined that this is not an issue.

The behavior you've described is actually a core feature of the ERC1155 standard. Contracts need to actively acknowledge their ability to handle ERC1155 tokens. If an avatar (human, organization, or group) is not ERC1155 compatible, it simply won't be able to interact with these tokens. This is not a vulnerability, but a safeguard built into the standard.

We appreciate your attention to potential security risks in our system. Your thorough examination of our token minting process contributes to the overall security review of our platform. Thank you for your diligence in helping ensure the robustness of our system.