OpenSea security record

In contract `NFTStore.sol`, in function `launchProduct()`, LAUNCH_ROLE will add product into the system, and buyer can later pay for the product. The NFT contract will have to assign contract `NFTStore` as a mint role so that `NFTStore` can mint token for the buyer. However, such design can easily be exploited. This also applies to `NFTAuction.launchAuction()`.

The project has no test suite.

There is no control that a unique token(combination of _contractAddr and _tokenId) is not launched in multiple auctions. If same token is listed in different actions, bidders send their funds to the contract on different auctions of the token. But the finalizeAuction will be executed successfully for just one of the auctions, and others will fail due to trying to mint an existing token and the funds get locked in the contract. Similar scenario leads to lock of the funds if a previousely minted token is launcehd in an auction.

In `NFTStore.sol`, Two product `A`, `B` can have the same contract address and `productTokenIds[A]`, `productTokenIds[B]` may have the same TokenID. So, when that token is minted in the product `A`. The token cannot be minted again in `B`, which means that product exists but is invalid to be bought. Although this would not harm the security, since the transaction will revert in the end. But this gives users bad using experience. Similarly in `NFTAuction.sol`, two auctions for the same NFT can exist at the same time. The situation in `NFTAuction` is even worse since this will result a waste of gas from multiple parties. And the seller has to cancel an auction to return ether to the bidder if the token can no longer be minted. If the seller refuse to cancel the auction, the fund used for bid will be **locked** in the contract.

It is not clear which contracts will be registered as “full support contracts”, however the function `acceptOffer()` performs external calls to upon these contracts to invoke and `creatorProfitOf(uint256)`. If the contract is malicious, it may return profit values arbitrarily high.

External contracts are used throughout the project. If the external contracts do not behave as expected, an auction may be launched/finished/canceled without transferring the actual token (see lines 145 and 223, 441, 498, 525, 609, 687). Furthermore, the tokens may cause re-entrancy.

The clone-and-own approach involves copying and adjusting open source code at one's own discretion. From the development perspective, it is initially beneficial as it reduces the amount of effort. However, from the security perspective, it involves some risks as the code may not follow the best practices, may contain a security vulnerability, or may include intentionally or unintentionally modified upstream libraries. In particular, OpenZeppelins `ReentrancyGuard` [code](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/ReentrancyGuard.sol) as well as `Pausable` [code](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/Pausable.sol) is cloned-and-owned inside `NFTAuction.sol` and `NFTStore.sol`.

Functions `vipBuy()` and `Buy()` have the check `require(!_isContract(msg.sender), "Illegal operation from contract.");`. However, `_isContract()` will incorrectly return `false` for contracts calling from within the constructor, allowing them to bypass this check. The check should therefore not be relied upon as a security measure.

Functions `NFTAuction.setAuctionData()` and `NFTStore.setStoreData()` are having no further constraints on the `_storeProfit` other than 100%. Consequently, users can be subject to very high fees. This can subject users to high fees with no prior announcments.

`NFTAuction.sol` and `NFTStore` contracts inherit from `AccessControlUpgradeable` contract which is never initialized. Although the `__AccessControl_init` has no implementation but the contract is upgradable and might change in future.