Potential scenario where an attacker can steal a user's gas refund

Lines of code Vulnerability details Impact Anybody is allowed to add gas for a specific tx. I was trying to figure out whether the following scenarios are possible: 1. Alice sends a public tx where she deposits some gas and calls the gateway contract after 2. Bob, the attacker, catches that...

Anyone can self-destruct this contract.

Lines of code Vulnerability details Impact High Unprotected call to a function executing selfdestruct/suicide. Proof of Concept DepositHandler.destroyaddress contracts/DepositHandler.sol28-30 allows anyone to destruct the contract. Once the contract is unlocked through the noReenter modifier,...

Approval from non-zero to non-zero amount can lead to DoS

Lines of code Vulnerability details Impact Some tokens like USDT do not work when changing the allowance from an existing non-zero allowance value. They must first be approved by zero and then the actual allowance must be approved. Proof of Concept The following function use an unsafe approvement...

Wrong arithmetic operation upon filling a bid order, lead to lost amount of ether on user funds

Lines of code Vulnerability details Functions GolomTrader.solfillBid... and GolomTrader.solfillCriteriaBid... used to fill a signed order Golom order.orderType = 1 or = 2 by the buyer after he approved GolomTrader contract some wETH. However, in case that the signed order is of type ERC1155 where...

Impossible to add ve in RewardDistributor

Lines of code Vulnerability details Impact Starting from ve == 0, we call addVoteEscrow. function addVoteEscrowaddress voteEscrow external onlyOwner if addressve == address0 ve = VEpendingVoteEscrow; else voteEscrowEnableDate = block.timestamp + 1 days; pendingVoteEscrow = voteEscrow; The functio...

Misleading mapping delegates

Lines of code Vulnerability details The mapping delegates in VoteEscrowDelegation can be misleading it is not updated when a delegation is removed. If someone is relying on this value not the case here, because this mapping is never used in the contracts ?, but we can assume that it has / will ha...

Upgraded Q -> M from 268 [1659038665057]

Judge has assessed an item in Issue 268 as Medium risk. The relevant finding follows: The protocol does not support fee on transfer and other weird tokens, e.g.: IERC20rewardToken.safeTransferFrommsg.sender, addressthis, amount; rewardTokenInforewardToken.queuedRewards += amount; --- The text was...

High risk with links to code

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept. Tools Used Recommended Mitigation Steps --- The...

[PNM-004] An additional domain can be registered for free

Lines of code Vulnerability details Description The ETHRegistrarController added new functionality to support set multiple records while registering a ETH 2LD. It uses the following code to support this functionality. function setRecords address resolver, bytes32 label, bytes calldata data intern...

[PNM-001] PARENT_CANNOT_CONTROL can be bypassed by maliciously unwrapping parent node

Lines of code Vulnerability details Description By design, for any subdomain, as long as its PARENTCANNOTCONTROL fuse is burnt and does not expire, its parent should not be able to burn its fuses or change its owner. However, this contraint can be bypassed by a parent node maliciously unwrapping...

Users can skirt fuses on subnodes

Lines of code Vulnerability details Impact If users are granted subnode ownership through setSubnodeRecord or setSubnodeOwner in NameWrapper.sol, and that node is owned by the NameWrapper contract in the ENS registry and the unwrap fuse is not set, then attackers can reset flags and do whatever...

Incorrect implementation of RRUtils.serialNumberGte

Lines of code Vulnerability details Impact Comparing serial numbers should follow RFC1982 due to the possibility of numbers wrapping around. RRUtils.serialNumberGte tried to follow the RFC but failed to do so, leading to incorrect results in comparison. Proof of Concept For a serial number i1 to ...

DNSSECImpl.verifySignature compares strings incorrectly, allowing malicious zones to forge DNSSEC trust chain

Lines of code Vulnerability details Impact DNSSEC allows parent zones to sign for its child zones. To check validity of a signature, RFC4034 3.1.7 requires the Signer's Name in any RRSIG RDATA to contain the zone of covered RRset. This requirement is reasonable since any child zone should be...

Auctions can be started for same undercollateralized vault using different Witch contracts, which causes vault collateral loss

Lines of code Vulnerability details Impact Given that there are two deployed Witch contracts, two auctioneers are calling Witch 1 and Witch 2's auction functions for the same vault at similar times. Both transactions are included in the same block for which the governances of these Witch contract...

If baseJoin's available balance is greater than callers' amount no underlying will be transferred.

Lines of code Vulnerability details Impact If callers' amount is greater than baseJoin's available balance no underlying will be transferred but caller still gets liquidatorCut. This may also negatively impact the accounting since its updated under the assumption that the caller will transfer...

Incorrect amount of Collateral moves for Auction

Lines of code Vulnerability details Impact It was observed that the debt and collateral which moves for Auction is calculated incorrectly. In case where line.proportion is set to small value, chances are art will become lower than min debt. This causes whole collateral to go for auction, which wa...

auction.start might be zero after a new auction is created.

Lines of code Vulnerability details Impact Currently several functions consider the auction is valid when auction.start 0 and they don't work properly when auction.start = 0. Proof of Concept In this part, auction.start = 0 when block.timestamp = 232 exactly. Of course, this is an edge case and...

CHECK VALID ADDRESS for _auctionStarted

Lines of code%20internal%20virtual%20%7BL214 Vulnerability details Impact Should check for valid address before giving so it can revert if it isn't. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the...

Incorrect validation check results with always initial proportion to the liquidator.

Lines of code Vulnerability details Impact The liquidator will get the initial proportion of value irrespective how long the time passed. Proof of Concept if duration == typeuint32.max in above condition check need to be checked with "elapsed" not with "duration" . Since it was mentioned that...

Attacker Can Front-run auction() To Modify Auctioneer Reward Receiver Address

Lines of code Vulnerability details Impact An attacker can front-run the auctioneer’s call to auction with another address to to receive the auctioneer reward instead of the original caller. Proof of Concept 1. Alice wants to liquidate a specific vault. 2. Mallory observes Alice's auction...

Upgraded Q -> M from 233 [1657954928095]

Judge has assessed an item in Issue 233 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

With most functions in VaultTracker.sol, users can call them only once after maturity has been reached.

Lines of code Vulnerability details Impact With most functions in VaultTracker.sol, users can call them only once after maturity has been reached. So from the second call of any functions after maturity, it will revert and users might lose their funds or interests. Proof of Concept The main probl...

Swivel.setFee() is implemented wrongly.

Lines of code Vulnerability details Impact Swivel.setFee is implemented wrongly. Swivel.feenominators won't be set as expected. Proof of Concept This function has a parameter "i" for the index of the new fee denomination but it isn't used during the update. Tools Used Solidity Visual Developer of...

Upgraded Q -> M from 163 [1657895636410]

Judge has assessed an item in Issue 163 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

MarketPlace - authRedeem does not work

Lines of code Vulnerability details Impact The redeem process looks broken, impacting one of the core functionality of the protocol. Proof of Concept The redeem process is the following: User calls redeem or withdraw in ZcToken, which forwards the call to MarketPlace, which calls...

Upgraded Q -> M from 390 [1657876456166]

Judge has assessed an item in Issue 390 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

Allowance should always larger or equal to the transferred amount

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. Wrong operators are set. Proof of Concept Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept. Line 111 - 115 if allowe...

ERC20 Incorrect check on returnedAddress in permit() results in unlimited approval of zero address

Lines of code Vulnerability details Impact When creating ERC20.sol from Solmate, a require in permit was converted to a custom error incorrectly. It now reads: if recoveredAddress != address0 && recoveredAddress != owner revert Invalidmsg.sender, owner; So if the recoveredAddress is non-zero and...

# an attacker can block stuff from the users from being able to do a buyout or sell fractoins or just main functions ,causing grief of users money and time

Lines of code Vulnerability details details uint256 endTime = startTime + PROPOSALPERIOD; if block.timestamp endTime 1.end time is almost block.timestamp so when an user calls this function 2. an attacker can blockstuff and cause the main functions not to happen maybe causing the...

Anyone can call propose() and create a DOS

Lines of code Vulnerability details A denial of service can be initiated by anyone, since there is no check for any address, and also no Ether/ERC20 at stake. Impact Denial of service for vault migration Proof of Concept Contract : Migration.sol, function propose Recommended Mitigation Steps Make...

Buyout Module: redeeming before the update of totalSupply will make buyout's current state success

Lines of code Vulnerability details Impact MED - a hypothetical attack path with stated assumptions, but external requirements. Attacker can create a vault with successful buyout status and non zero supply. The attacker can sell the fractions and then simply withdraw the assets. Proof of Concept...

Buyout Module: ethBalance is not properly updated

Lines of code Vulnerability details Impact HIGH - Assets can be stolen directly. An attacker can steal eth from buyout module Proof of Concept proof of concept1: testCashSharepoc proof of concept2: testCashRepeatpoc The proof of concept1 shows that the same amount of fractions will result in...

Migration Module: Usage of withdrawContribution instead of leave before buyout

Lines of code Vulnerability details Impact HIGH - Assets can be compromised directly. One can use eth from the module for buyout process. Basically sending somebody else's eth from migration module to buyout module Proof of Concept proof of concept The proof of concepts shows a scenario where one...

call() should be used instead of transfer() on address payable

Lines of code Vulnerability details call should be used instead of transfer on address payable Impact The use of the deprecated transfer function for an address wll make the transaction fail when 1. The withdrawer smart contract does not implement a payable function. 2. The withdrawer smart...

User can block migration actions by starting buyout process

Lines of code Vulnerability details Impact All migration actions such as propose, join, leave, and commit require that the pool's buyout state is INACTIVE. At any point, a user can call buyout.Start to start the buyout process which will change the buyout state to LIVE. Proof of Concept...

Small scalar may make buyoutPrice calculation incorrectly

Lines of code Vulnerability details Impact In Buyout.start function, buyoutPrice is calculated using a scalar = 100. This small scalar and division rouding will reduce the precision of the formula significantly. Proof of Concept 1. Alice call start with msg.value = 1e18 and depositAmount = 4567...

oldToken.transferOwnership() to contract may be irreversible

Lines of code Vulnerability details oldToken.transferOwnership to contract may be irreversible Proof of Concept JBTokenStore.sol 265-266: if newOwner != address0 && oldToken != IJBTokenaddress0 oldToken.transferOwnershipprojectId, newOwner; OpenZeppelin library Ownerable.sol: function...

Issue with condition check handling

Lines of code Vulnerability details Impact It might cause data corruption, as most of the data handling is done in low level. Proof of Concept // Add up all the percents to make sure they cumulative are under 100%. uint256 percentTotal = 0; for uint256 i = 0; i typeuint56.max revert...

Distribution of reserved tokens may run out of gas

Lines of code Vulnerability details Impact If there are enough entries in the splits array, the function that distributes the reserved tokens will run out of gas, and the reserved tokens will be un-distributable until the current cycle is over, and the splits are changed. If cycles are long, the...

CreateFor#JBProjects.sol is vulnerable to reentrancy

Lines of code Vulnerability details Impact Reentrancy attack can trick users by spamming incorrect project Id event emission Proof of Concept The function createFor which uses safeMint is lacking any form a reentrancy protection. OZ Safe Mint implementation is function safeMint address to, uint25...

Upgraded Q -> M from 139 [1656985204675]

Judge has assessed an item in Issue 139 as Medium risk. The relevant finding follows: 1. Buyouts that occur during the timestamp wrap will have valuation errors The blockTimestamp has a modulo applied, so at some point, there will be a timestamp with a value close to 2^32, followed by a timestamp...

Problems with the access control of the fillOrder() function

Lines of code Vulnerability details Impact Detailed description of the impact of this finding. fillOrder does not check order.maker ! = caller, which means that mintorder.maker, uint256orderHash; & mintmsg.sender, positionId; can mint NFT to the same person and therefore may create unintended...

both order side positions don’t exist is not checked

Lines of code Vulnerability details Impact The flow in fillOrder as documented in expects the check order side positions doesn't exist . However the fillOrder function does not have a require check for this. This allows for the same side positions to be created multiple times leading to loss of...

Counter offer is not implemented correctly

Lines of code Vulnerability details Impact acceptCounterOffer is not verifying if the original order has already been filled. In case maker makes a counter offer and by the time counter offer is called, some user has already filled the original order then both original and counter offer will be...

Fee is being deducted when Put is expired and not when it is exercised.

Lines of code Vulnerability details Impact Fee is being deducted when Put is expired and not when it is exercised in PuttyV2.sol. Comment section of the setFee function mentions "fee rate that is applied on exercise" which signifies that the fee amount is meant to be deducted from strike only whe...

PUT short option is always in loss

Lines of code Vulnerability details Impact For a long PUT condition the party which is doing short will always be in loss Proof of Concept 1. Alice creates and signs a long put option order off-chain for 2 Bored Ape floors with a duration of 30 days, a strike of 124 WETH and a premium of 0.8 WETH...

Upgraded G -> M from 49 [1656600225781]

Judge has assessed an item in Issue 49 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded G -> M from 84 [1656428843011]

Judge has assessed an item in Issue 84 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from 413 [1656340156818]

Judge has assessed an item in Issue 413 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...

Upgraded Q -> M from 194 [1656339935656]

Judge has assessed an item in Issue 194 as Medium risk. The relevant finding follows: --- The text was updated successfully, but these errors were encountered: All reactions...