NextGenMinterContract::mint can be reentered for sales option 3 to mint many NFTs in a single period and bypass viewMaxAllowance for any sales option

Lines of code Vulnerability details Impact The reentrancy vulnerability in the NextGenMinterContract::mint function allows an attacker to bypass the restriction of minting only one NFT per period. The reentrencies can be achieved from the safeMint in the function NextGenCore::mintProcessing to ca...

Incorrect indexing in constructor of Curve Adapters causes both contracts to assume xToken and lpToken to be the same token

Lines of code Vulnerability details Impact Curve Adapter contracts are unusable, as the protocol won't be able to tell the difference between which token USDC/USDT or lpToken is intended on being used for the transaction. Vulnerability details In the constructors of the Curve2PoolAdapter.sol and...

An attacker can mint more than they are allowed due to MinterContract.sol#mint() reentrancy vulnerability

Lines of code Vulnerability details Bug Description mintProcessing in NextGenCore.sol calls OpenZeppelin’s safeMint from their ERC721 contract to mint a token. safeMint checks if the target address is a contract by calling checkOnERC721Received to ensure it supports receiving NFTs. If the target...

Reentrancy in mint function allows minting above the limit allowed per address / allowlisted address

Lines of code Vulnerability details Impact The mint function in NextGenCore.sol doesn't follow the checks-effects-interactions pattern and can be reentered through the onERC721Received function, if the receiver is a contract. The state variables written after the call are...

imbalanced or invalid liquidity additions/removals could happen

Lines of code Vulnerability details Impact Potential for loss of funds or manipulation of the pool prices. Specifically: • By allowing deposit from only one of the xToken or yToken, it enables manipulating the price ratio between the tokens in the pool. This could benefit one token over the other...

Usage of _safeMint in NextGenCore@_mintProcessing allows an attacker to reenter when onERC721Received is called

Lines of code Vulnerability details Impact An attacker can : Exceed the per address allowance in Fixed Price Sale, Exponential Descending Sale and Linear Descending Sale modes. Cause a loss for another user in Burn-to-Mint mode by accepting an offer when onERC721Received is triggered. Proof of...

Fee on transfer tokens are not accounted for in any way

Lines of code Vulnerability details Impact Fee on transfer or other unique tokens are not properly accounted for. This could lead to wrong accounting within The Ocean and eventual losses for the protocol. Proof of Concept The Ocean doesn't keep track of its balances when a user is wrapping a toke...

Ocean cannot _mintBatch() as onERC1155BatchRecieved() not implemeneted on the Ocean contract when batch transferring to itself

Lines of code Vulnerability details The comment @ Ocean L348 states: The Ocean never initiates ERC1155 Batch Transfers. This is untrue, note the following callstack: Ocean.doMultipleInteractions | Ocean.forwardedDoMultipleInteractions Ocean.doMultipleInteractions calls mintBatch @ L560...

Slippage Handling

Lines of code Vulnerability details Impact The primitiveOutputAmount function reverts the transaction if the output amount is less than the minimumOutputAmount, which is a strict slippage protection. This could lead to failed transactions due to normal price fluctuations in the Curve pool. Proof ...

Multiple re-entrancy issues allowing stealing of funds and bypassing protocol mint limits

Lines of code Vulnerability details Impact Multiple re-entrancy issues exist in the codebase, that break core functionality and allow stealing of user funds. In AuctionDemo.sol contract re-entrancy in cancelBid and cancelAllBids allows stealing of user funds. There are multiple attack surfaces,...

Handling Potential Slippage Due to Truncation

Lines of code Vulnerability details Impact The potential slippage issue arises from the precision loss during decimal conversion in the primitiveOutputAmount function. When interacting with the Curve Tricrypto Pool, especially involving tokens with different decimal precisions, truncation can lea...

Unwrap Fee Rounding Down: Revenue Loss, User Unfairness, and Reduced Confidence

Lines of code Vulnerability details Impact The issue with the unwrap fee rounding down can have several detrimental impacts on the Ocean protocol: 1. Revenue Loss: Due to rounding down, the contract loses out on potential unwrap fees, particularly for smaller unwrap amounts. This can significantl...

Ocean.doMultipleInteractions() cannot wrap ether

Lines of code Vulnerability details Bug Description doMultipleInteractions in Ocean.sol attempts to wrap ether but reverts due to a logical error. The internal helper function, doMultipleInteractions, includes the following: if msg.value != 0 balanceDeltas.increaseBalanceDeltaWRAPPEDETHERID,...

Wrapping ether with Ocean.doMultipleInteractions() reverts

Lines of code Vulnerability details Summary Wrapping ether with doMultipleInteractions reverts. This is the case if one or more of the interactions is handling ether. If we look at the internal helper function, doMultipleInteractions, it includes the following: if msg.value != 0...

Batch Execution Failure

Lines of code Vulnerability details Impact A failure in one interaction could potentially cause the entire batch to fail, affecting subsequent interactions. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates...

An attacker can manipulate the preDepositvePrice to steal from other users.

Lines of code Vulnerability details Impact The first user that stakes can manipulate the total supply of sfTokens and by doing so create a rounding error for each subsequent user. In the worst case, an attacker can steal all the funds of the next user. Proof of Concept When the first user enters...

Users can fail to unstake and lose their deserved ETH because malfunctioning or untrusted derivative cannot be removed. Users can fail to unstake and lose their deserved ETH because malfunctioning or untrusted derivative cannot be removed.

Lines of code Vulnerability details Potest egreditur posses torrens fugamque ignavis Ubi spectemur patent prominet tenebat ait est Lorem markdownum vitam, unus cum quaeque bellique portante et siccis intremuere nondum pascere vidit. In mihi cara terra, sui regni meritasque nescia, litora vocatum...

Some functions that call Exchange.getMarkPrice function do not check if Exchange.getMarkPrice function's returned markPrice is 0

Lines of code Vulnerability details Vulnerability details Impact The following Exchange.getMarkPrice function uses pool.baseAssetPrice's returned baseAssetPrice, which is spotPrice returned by perpMarket.assetPrice, to calculate and return the markPrice. When such spotPrice is 0, this function...

latestAnswer() may return stale values

Lines of code 121, 122, 123, 124, 51 Vulnerability details latestAnswer only returns the latest answer or zero, and thus there is no way to tell whether the value is stale or not. Use latestRoundData instead, and check whether the latest timestamp is within your protocol's limits. File:...

_safeMint() should be used rather than _mint() wherever possible

Lines of code 139, 178, 204 Vulnerability details mint is discouraged in favor of safeMint which ensures that the recipient is either an EOA or implements IERC721Receiver. Both OpenZeppelin and solmate have versions of this function. In the cases below, mint does not call...

Calls to get_virtual_price() are vulnerable to read-only reentrancy

Lines of code 117 Vulnerability details getvirtualprice was originally considered to be a manipulation-resistant price - suitable as a price oracle, but it was later found to be vulnerable to a read-only reentrancy attack, where the Curve contract could be put into a partially-modified state, and...

addRewardToken() does note remove old entries before adding new ones

Lines of code 455, 280, 378, 411 Vulnerability details Each time addRewardToken is called, new entries are added to the array, but doing so does not remove any old entries. By calling the function multiple times, an attacker can can increase their voting power indefinitely, without having to...

Array is push()ed but not pop()ed, and is iterated over

Lines of code 96, 485, 485, 485, 485, 485, 485, 485, 485, 485, 485https://github.com/Tapioca-DAO/ta...

Upgraded Q -> 2 from #776 [1701452999417]

Judge has assessed an item in Issue 776 as 2 risk. The relevant finding follows: Low-01 No minimum AmountrsETH receive parameter absent in depositAsset Here we can see that User deposit asset via depositAsset which take asset address and asset depositAmount as parameter Then rsethAmountMinted...

Upgraded Q -> 2 from #776 [1701456793936]

Judge has assessed an item in Issue 776 as 2 risk. The relevant finding follows: Low-01 No minimum AmountrsETH receive parameter absent in depositAsset Here we can see that User deposit asset via depositAsset which take asset address and asset depositAmount as parameter Then rsethAmountMinted...

_safeMint() should be used rather than _mint() wherever possible

Lines of code 139, 178, 204 Vulnerability details mint is discouraged in favor of safeMint which ensures that the recipient is either an EOA or implements IERC721Receiver. Both OpenZeppelin and solmate have versions of this function. In the cases below, mint does not call...

Excess funds sent via msg.value not refunded

Lines of code 201 Vulnerability details The code below allows the caller to provide Ether, but does not refund the amount in excess of what's required, leaving funds stranded in the contract. The condition should be changed to check for equality, or the code should refund the excess. File:...

Contracts are vulnerable to fee-on-transfer accounting-related issues

Lines of code 359, 448, 509, 530, 42, 797, 162 Vulnerability details The functions below transfer funds from the caller to the receiver via transferFrom, but do not ensure that the actual number of tokens received is the same as the input amount to the transfer. If the token is a fee-on-transfer...

latestAnswer() may return stale values

Lines of code 121, 122, 123, 124, 51 Vulnerability details latestAnswer only returns the latest answer or zero, and thus there is no way to tell whether the value is stale or not. Use latestRoundData instead, and check whether the latest timestamp is within your protocol's limits. File:...

Calls to get_virtual_price() are vulnerable to read-only reentrancy

Lines of code 117 Vulnerability details getvirtualprice was originally considered to be a manipulation-resistant price - suitable as a price oracle, but it was later found to be vulnerable to a read-only reentrancy attack, where the Curve contract could be put into a partially-modified state, and...

addRewardToken() does note remove old entries before adding new ones

Lines of code 455, 280, 378, 411 Vulnerability details Each time addRewardToken is called, new entries are added to the array, but doing so does not remove any old entries. By calling the function multiple times, an attacker can can increase their voting power indefinitely, without having to...

Array is push()ed but not pop()ed, and is iterated over

Lines of code 96, 485, 485, 485, 485, 485, 485, 485, 485, 485, 485https://github.com/Tapioca-DAO/ta...

Proxy's logic contract relies on code in the constructor

Lines of code 122, 50, 25, 67, 98, 67, 22 Vulnerability details Impact Logic contracts cannot rely on code in their constructors, because proxy contracts do not re-execute the logic contract's constructor - only its initializer. Move all code in the constructor to the initializer function. File:...

Calls to get_virtual_price() are vulnerable to read-only reentrancy

Lines of code 117 Vulnerability details Impact getvirtualprice was originally considered to be a manipulation-resistant price - suitable as a price oracle, but it was later found to be vulnerable to a read-only reentrancy attack, where the Curve contract could be put into a partially-modified...

Return values of transfer()/transferFrom() not checked

Lines of code 377, 509, 491, 530, 42, 50 Vulnerability details Impact Not all IERC20 implementations revert when there's a failure in transfer/transferFrom. The function signature has a boolean return value and they indicate errors that way instead. By not checking the return value, operations th...

Unsafe usage of msg.value in a loop

Lines of code 140 Vulnerability details Impact The value of msg.value in a transaction's call never gets updated, even if the called contract ends up sending some or all of the Eth to another contract. This means that using msg.value in a for- or while-loop, without extra accounting logic, will...

Using block.timestamp as the deadline/expiry invites MEV

Lines of code 307 Vulnerability details Impact Passing block.timestamp as the expiry/deadline of an operation does not mean "require immediate execution" - it means "whatever block this transaction appears in, I'm comfortable with that block's timestamp". Providing this value means that a malicio...

Interface improperly implemented

Lines of code 34, 34, 34, 34, 30, 31, 32, 34, 35, 38https://github.com/Tapioca-DAO/tapioca-yieldbox-strategies-audi...

Unsafe use of approve() with IERC20

Lines of code 321, 215, 184, 450, 761, 217, 157, 234, 339, 386https://github.com/Tapioca-DAO/t...

Unchecked return value of low-level

Lines of code Vulnerability details Impact description of issue/finding Content includes @Audit stack and code example of the issue Assessed type other --- The text was updated successfully, but these errors were encountered: All reactions...

Excess funds sent via msg.value not refunded

Lines of code 201 Vulnerability details Impact The code below allows the caller to provide Ether, but does not refund the amount in excess of what's required, leaving funds stranded in the contract. The condition should be changed to check for equality, or the code should refund the excess. File:...

Unsafe use of transfer()/transferFrom() with IERC20

Lines of code 377, 509, 491, 530, 42, 50 Vulnerability details Impact Some tokens do not implement the ERC20 standard properly but are still accepted by most code that accepts ERC20 tokens. For example Tether USDT's transfer and transferFrom functions on L1 do not return booleans as the...

_safeMint() should be used rather than _mint() wherever possible

Lines of code 139, 178, 204 Vulnerability details Impact mint is discouraged in favor of safeMint which ensures that the recipient is either an EOA or implements IERC721Receiver. Both OpenZeppelin and solmate have versions of this function. In the cases below, mint does not call...

Fee-on-transfer/rebasing tokens will have problems when swapping

Lines of code 110 Vulnerability details Impact Uniswap v3 does not support rebasing or fee-on-transfer tokens so using these tokens with it will result funds getting stuck. With fee-on-transfer tokens, if the balance isn't checked, the wrong amount may be transferred out. With rebasing tokens, th...

Contracts are vulnerable to fee-on-transfer accounting-related issues

Lines of code 359, 448, 509, 530, 42, 797, 162 Vulnerability details Impact The functions below transfer funds from the caller to the receiver via transferFrom, but do not ensure that the actual number of tokens received is the same as the input amount to the transfer. If the token is a...

The owner is a single point of failure and a centralization risk

Lines of code 56, 109, 127, 172, 219, 250, 115, 131, 154, 116, 131https://github.com/Tapioca-DAO/tapiocaz-audit/blob/bcf61f79464cfdc0484aa272f9f6e28d...

Upgraded Q -> 2 from #776 [1701285150754]

Judge has assessed an item in Issue 776 as 2 risk. The relevant finding follows: Low-01 No minimum AmountrsETH receive parameter absent in depositAsset Here we can see that User deposit asset via depositAsset which take asset address and asset depositAmount as parameter Then rsethAmountMinted...

Unchecked return value of low-level call()/delegatecall()

Lines of code 120, 141, 411, 184, 160, 189, 152, 444, 625, 638https://github.com/Tapioca-DAO/tapioca-bar-audit/blob/2286f80f928f41c8bc189d0657d74ba83286c668/contract...

Some tokens may revert when zero value transfers are made

Lines of code 356, 371, 145, 272, 252, 116, 445, 374, 506, 488https://github.com/Tapioca-DAO/tap-token-audit/blob/59749be5bc2286f0bdbf59d7ddc258ddafd49a9f/contracts/options/TapiocaOptionBroker...

Title of issue/finding

Lines of code , Vulnerability details Impact description for the issue found Content includes @Audit stack and code example of the issue Content includes @Audit stack and code example of the issue Assessed type other --- The text was updated successfully, but these errors were encountered: All...