Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `update()` function in the CollateralizationOracleWrapper contract is designed to check for outd. The `update()` function in the CollateralizationOracleWrapper contract is designed to check for outdated data and update the cached values accordingly. The function returns a boolean flag indicating whether the update was performed on outdated data. This flag is used in the `updateIfOutdated()` func...

Vulnerable code:
```\nrequire(_validityStatus, "CollateralizationOracleWrapper: CollateralizationOracle is invalid");\n\n// Set cache variables\ncachedProtocolControlledValue = _protocolControlledValue;\ncachedUserCirculatingFei = _userCirculatingFei;\ncachedProtocolEquity = _protocolEquity;\n\n// Reset time\n_initTimed();\n\n// Emit event\nemit CachedValueUpdate(\n    msg.sender,\n    cachedProtocolControlledValue,\n    cachedUserCirculatingFei,\n    cachedProtocolEquity\n);\n\nreturn (\n    outdated\n    || _isExceededDeviationThreshold(cachedProtocolControlledValue, _protocolControlledValue)\n    || _isExceededDeviationThreshold(cachedUserCirculatingFei, _userCirculatingFei)\n);\n```
MEDIUM severity: The `NodeRegistry` allows for the registration of nodes with arbitrary URLs, which can be DNS resolv. The `NodeRegistry` allows for the registration of nodes with arbitrary URLs, which can be DNS resolvable names, IP addresses, localhost, or private subnets. This vulnerability enables a wide range of attacks, including:\n\n* Registering a node with an invalid or empty URL, causing the `in3-server` t...

Vulnerable code:
```\nconst config = nodes.nodes.find((_) => _.address.toLowerCase() === adr.toLowerCase())\n\nif (!config) {\n  throw new Error(`The ${adr} does not exist within the current registered active nodeList!`)\n}\n\nconst cachedSignatures: Signature[] = []\nconst blocksToRequest = blocks.filter((b) => {\n  const s = signatureCaches.get(b.hash)\n  return s? cachedSignatures.push(s) * 0 : true\n})\n\nlet response: RPCResponse\ntry {\n  response = (blocksToRequest.length\n   ? await handler.transport.handle(config.url, {\n        id: handler.counter++ || 1,\n        jsonrpc: '2.0',\n        method: 'in3_sign',\n        params: blocksToRequest,\n      })\n    : { result: [] }) as RPCResponse\n  if (response.error) {\n```
MEDIUM severity: The lifecycle of bids in the `zAuction` and `zNS` systems is unclear and has several flaws. Specific. The lifecycle of bids in the `zAuction` and `zNS` systems is unclear and has several flaws. Specifically, the inability to cancel bids once placed creates uncertainty and potential issues.\n\nIn the case of `zAuction`, when a bid is accepted and the asset is transferred to a new owner, the new owner...

Vulnerable code:
```\nfunction acceptBid(bytes memory signature, uint256 rand, address bidder, uint256 bid, address nftAddress, uint256 tokenid) external {\n    address recoveredBidder = recover(toEthSignedMessageHash(keccak256(abi.encode(rand, address(this), block.chainid, bid, nftAddress, tokenid))), signature);\n    require(bidder == recoveredBidder, 'zAuction: incorrect bidder');\n    require(!randUsed[rand], 'Random nonce already used');\n    randUsed[rand] = true;\n    IERC721 nftContract = IERC721(nftAddress);\n    accountant.Exchange(bidder, msg.sender, bid);\n    nftContract.transferFrom(msg.sender, bidder, tokenid);\n    emit BidAccepted(bidder, msg.sender, bid, nftAddress, tokenid);\n}\n```\n```\nfunction fulfillDomainBid(\n    uint256 parentId,\n    uint256 bidAmount,\n    uint256 royaltyAmount,\n    string memory bidIPFSHash,\n    string memory name,\n    string memory metadata,\n    bytes memory signature,\n    bool lockOnCreation,\n    address recipient\n) external {\n    bytes32 recoveredBidHash = createBid(parentId, bidAmount, bidIPFSHash, name);\n    address recoveredBidder = recover(recoveredBidHash, signature);\n    require(recipient == recoveredBidder, "ZNS: bid info doesn't match/exist");\n    bytes32 hashOfSig = keccak256(abi.encode(signature));\n    require(approvedBids[hashOfSig] == true, "ZNS: has been fulfilled");\n    infinity.safeTransferFrom(recoveredBidder, controller, bidAmount);\n    uint256 id = registrar.registerDomain(parentId, name, controller, recoveredBidder);\n    registrar.setDomainMetadataUri(id, metadata);\n    registrar.setDomainRoyaltyAmount(id, royaltyAmount);\n    registrar.transferFrom(controller, recoveredBidder, id);\n    if (lockOnCreation) {\n        registrar.lockDomainMetadataForOwner(id);\n    }\n    approvedBids[hashOfSig] = false;\n    emit DomainBidFulfilled(\n        metadata,\n        name,\n        recoveredBidder,\n        id,\n        parentId\n    );\n}\n```
MEDIUM severity: The `Pool` contract's threshold voting mechanism is vulnerable to manipulation due to the absence of. The `Pool` contract's threshold voting mechanism is vulnerable to manipulation due to the absence of sufficient validation checks during the execution phase. Specifically, the `_executeRemoveFromCommittee` and `_executeChangeCommitteeThreshold` functions lack crucial checks to ensure that the busine...

Vulnerable code:
```\nfunction _executeRemoveFromCommittee(address who_) private {\n    //...\n```\n```\nfunction _executeChangeCommitteeThreshold(uint256 threshold) private {\n    //...\n```
MEDIUM severity: The mintRollovers function in the smart contract is vulnerable to a potential issue where it does no. The mintRollovers function in the smart contract is vulnerable to a potential issue where it does not properly validate the entitled shares before performing a rollover. Specifically, the function only checks if the assets in the queue at the current index (`queue[index].assets`) are greater than or...

Vulnerable code:
```\nif (entitledShares > queue[index].assets) {\n    if (queue[index].assets < relayerFee) {\n        index++;\n        continue;\n    }\n```
MEDIUM severity: The vulnerability lies in the way the OHM token is minted and deposited in the BLVaultLido contract.. The vulnerability lies in the way the OHM token is minted and deposited in the BLVaultLido contract. The minting process relies on the on-chain oracle prices, which have a deviation threshold between the current price of the asset and the on-chain price. This deviation can be exploited by combining...

Vulnerable code:
```\nuint256 ohmWstethPrice = manager.getOhmTknPrice();\nuint256 ohmMintAmount = (amount_ * ohmWstethPrice) / _WSTETH_DECIMALS;\n\n// Block scope to avoid stack too deep\n{\n    uint256 bptBefore = liquidityPool.balanceOf(address(this));\n\n    wsteth.safeTransferFrom(msg.sender, address(this), amount_);\n\n    manager.mintOhmToVault(ohmMintAmount);\n\n    _joinBalancerPool(ohmMintAmount, amount_, minLpAmount_);\n}\n```\n```\nuint256[] memory maxAmountsIn = new uint256[](2);\nmaxAmountsIn[0] = ohmAmount_;\nmaxAmountsIn[1] = wstethAmount_;\n\nJoinPoolRequest memory joinPoolRequest = JoinPoolRequest({\n    assets: assets,\n    maxAmountsIn: maxAmountsIn,\n    userData: abi.encode(1, maxAmountsIn, minLpAmount_),\n    fromInternalBalance: false\n});\n```
MEDIUM severity: The `keep-tecdsa` vulnerability is a security issue in the `submitSignatureFraud` function, which is. The `keep-tecdsa` vulnerability is a security issue in the `submitSignatureFraud` function, which is responsible for verifying the authenticity of a digital signature. The function takes in several parameters, including the public key, the signature, and the preimage, and returns a boolean indicatin...

Vulnerable code:
```\nfunction submitSignatureFraud(\n    uint8 _v,\n    bytes32 _r,\n    bytes32 _s,\n    bytes32 _signedDigest,\n    bytes calldata _preimage\n) external returns (bool _isFraud) {\n    require(publicKey.length!= 0, "Public key was not set yet");\n\n    bytes32 calculatedDigest = sha256(_preimage);\n    require(\n        _signedDigest == calculatedDigest,\n        "Signed digest does not match double sha256 hash of the preimage"\n    );\n\n    bool isSignatureValid = publicKeyToAddress(publicKey) ==\n        ecrecover(_signedDigest, _v, _r, _s);\n\n    require(isSignatureValid &&!digests[_signedDigest], "Signature is not fraudulent");\n\n    return true;\n}\n```
MEDIUM severity: The `SDLPool` contract's approval mechanism is vulnerable to unauthorized lock transfers due to the . The `SDLPool` contract's approval mechanism is vulnerable to unauthorized lock transfers due to the lack of revocation functionality. Specifically, once an approval is granted via the `approve` function, it cannot be revoked, even if the owner revokes the operator's permission using the `setApproval...

Vulnerable code:
```\nfunction setApprovalForAll(address _operator, bool _approved) external {\n    address owner = msg.sender;\n    if (owner == _operator) {\n        revert ApprovalToCaller();\n    }\n\n    operatorApprovals[owner][_operator] = _approved;\n    emit ApprovalForAll(owner, _operator, _approved);\n}\n```\n```\nfunction approve(address _to, uint256 _lockId) external {\n    address owner = ownerOf(_lockId);\n\n    if (_to == owner) {\n        revert ApprovalToCurrentOwner();\n    }\n    if (msg.sender!= owner &&!isApprovedForAll(owner, msg.sender)) {\n        revert SenderNotAuthorized();\n    }\n\n    tokenApprovals[_lockId] = _to;\n    emit Approval(owner, _to, _lockId);\n```
MEDIUM severity: Uniswap v3's callback mechanism, implemented in the `uniswapV3MintCallback` and `uniswapV3SwapCallba. Uniswap v3's callback mechanism, implemented in the `uniswapV3MintCallback` and `uniswapV3SwapCallback` functions, allows the `pool` contract to interact with the `Hypervisor` contract. The `pool` contract is responsible for calling these callback functions to facilitate token transfers. However, th...

Vulnerable code:
```\nfunction uniswapV3MintCallback(\n    uint256 amount0,\n    uint256 amount1,\n    bytes calldata data\n) external override {\n    require(msg.sender == address(pool));\n    address payer = abi.decode(data, (address));\n\n    if (payer == address(this)) {\n        if (amount0 > 0) {\n            token0.safeTransfer(msg.sender, amount0);\n        }\n        if (amount1 > 0) {\n            token1.safeTransfer(msg.sender, amount1);\n        }\n    } else {\n        if (amount0 > 0) {\n            token0.safeTransferFrom(payer, msg.sender, amount0);\n        }\n        if (amount1 > 0) {\n            token1.safeTransferFrom(payer, msg.sender, amount1);\n        }\n    }\n}\n\nfunction uniswapV3SwapCallback(\n    int256 amount0Delta,\n    int256 amount1Delta,\n    bytes calldata data\n) external override {\n    require(msg.sender == address(pool));\n    address payer = abi.decode(data, (address));\n\n    if (amount0Delta > 0) {\n        if (payer == address(this)) {\n            token0.safeTransfer(msg.sender, uint256(amount0Delta));\n        } else {\n            token0.safeTransferFrom(payer, msg.sender, uint256(amount0Delta));\n        }\n    } else if (amount1Delta > 0) {\n        if (payer == address(this)) {\n            token1.safeTransfer(msg.sender, uint256(amount1Delta));\n        } else {\n            token1.safeTransferFrom(payer, msg.sender, uint256(amount1Delta));\n        }\n    }\n}\n```
MEDIUM severity: The vulnerability allows suspended PartyBs to bypass the withdrawal restriction by exploiting the `f. The vulnerability allows suspended PartyBs to bypass the withdrawal restriction by exploiting the `fillCloseRequest` function. This allows them to transfer ill-gotten gains out of the protocol, resulting in a loss of assets for the protocol and its users.\n\nWhen a user is suspended, they are not pe...

Vulnerable code:
```\nfunction withdraw(uint256 amount) external whenNotAccountingPaused notSuspended(msg.sender) {\n    AccountFacetImpl.withdraw(msg.sender, amount);\n    emit Withdraw(msg.sender, msg.sender, amount);\n}\n\nfunction withdrawTo(\n    address user,\n    uint256 amount\n) external whenNotAccountingPaused notSuspended(msg.sender) {\n    AccountFacetImpl.withdraw(user, amount);\n    emit Withdraw(msg.sender, user, amount);\n}\n```\n```\nmodifier notSuspended(address user) {\n    require(\n       !AccountStorage.layout().suspendedAddresses[user],\n        "Accessibility: Sender is Suspended"\n    );\n    _\n}\n```
MEDIUM severity: The "Force traders to mint gas token" vulnerability occurs when an attacker, Mallory, exploits a wea. The "Force traders to mint gas token" vulnerability occurs when an attacker, Mallory, exploits a weakness in the Fairswap_iDOLvsEth exchange's gas management system. The attack scenario unfolds as follows: Alice initiates a large trade on the exchange, which temporarily ties up her iDOL tokens until...

Vulnerable code:
```\nfunction _transferETH(address _recipient, uint256 _amount) private {\n    // TO DO: implement the logic for transferring ETH\n}\n```
MEDIUM severity: The `validateCommitment` function in the `AstariaRouter` contract is responsible for verifying the c. The `validateCommitment` function in the `AstariaRouter` contract is responsible for verifying the commitment details provided by the borrower. The function checks various parameters, including the deadline for the lien request, but fails to verify the nonce of the strategist. The nonce is a critica...

Vulnerable code:
```\nfunction validateCommitment(IAstariaRouter.Commitment calldata commitment)\n    public\n    returns (bool valid, IAstariaRouter.LienDetails memory ld)\n{\n    require(\n        commitment.lienRequest.strategy.deadline >= block.timestamp,\n        "deadline passed"\n    );\n\n    require(\n        strategyValidators[commitment.lienRequest.nlrType]!= address(0),\n        "invalid strategy type"\n    );\n\n    bytes32 leaf;\n    (\n        leaf,\n        ld\n    ) = IStrategyValidator(\n        strategyValidators[commitment.lienRequest.nlrType]\n    ).validateAndParse(\n        commitment.lienRequest,\n        COLLATERAL_TOKEN.ownerOf(\n            commitment.tokenContract.computeId(commitment.tokenId)\n        ),\n        commitment.tokenContract,\n        commitment.tokenId\n    );\n\n    return (\n        MerkleProof.verifyCalldata(\n            commitment.lienRequest.merkle.proof,\n            commitment.lienRequest.merkle.root,\n            leaf\n        ),\n        ld\n    );\n}\n```
MEDIUM severity: The vulnerability arises from a type casting issue in the `Vault.storePriceAndRewards` function, whi. The vulnerability arises from a type casting issue in the `Vault.storePriceAndRewards` function, which can lead to an unsigned integer underflow exception when the current price of a locked token is lower than the last recorded price. This occurs when the `currentPrice` is subtracted from `lastPrice...

Vulnerable code:
```\nint256 priceDiff = int256(currentPrice - lastPrices[_protocolId]);\n```
MEDIUM severity: The `universalReceiver` function in the contract is responsible for handling transfers of vaults fro. The `universalReceiver` function in the contract is responsible for handling transfers of vaults from various sources. However, it appears to have a critical flaw in its logic. When a notifying contract does not support the LSP9 interface, but the `typeID` corresponds to an LSP9 transfer, the functi...

Vulnerable code:
```\nif (\n    mapPrefix == _LSP10_VAULTS_MAP_KEY_PREFIX &&\n    notifier.code.length > 0 &&\n   !notifier.supportsERC165InterfaceUnchecked(_INTERFACEID_LSP9)\n) {\n    return "LSP1: not an LSP9Vault ownership transfer";\n}\n```
MEDIUM severity: The AuraSpell contract's `closePositionFarm` function, specifically lines 227-247, contains a vulner. The AuraSpell contract's `closePositionFarm` function, specifically lines 227-247, contains a vulnerability that can result in unintended fee deductions for users. The function first calls `exitPool` to redeem the BLP, and then iterates through the reward tokens to swap each one for the debt token....

Vulnerable code:
```\nvoid doSomething() {\n    wAuraPools.getVault(lpToken).exitPool(\n        IBalancerPool(lpToken).getPoolId(),\n        address(this),\n        address(this),\n        IBalancerVault.ExitPoolRequest(\n            tokens,\n            minAmountsOut,\n            abi.encode(0, amountPosRemove, borrowTokenIndex),\n            false\n        )\n    );\n}\n\nuint256 rewardTokensLength = rewardTokens.length;\nfor (uint256 i = 0; i < rewardTokensLength; i++) {\n    address sellToken = rewardTokens[i];\n    if (sellToken == STASH_AURA) sellToken = AURA;\n    _doCutRewardsFee(sellToken);\n}\n```
MEDIUM severity: The `getReservedUsd` function, responsible for calculating the reserved USD value for a given market. The `getReservedUsd` function, responsible for calculating the reserved USD value for a given market, exhibits a critical flaw when dealing with markets that have the same collateral token for both long and short positions. Specifically, when the collateral token is the same for both long and short...

Vulnerable code:
```\nfunction getReservedUsd(\n    DataStore dataStore,\n    Market.Props memory market,\n    MarketPrices memory prices,\n    bool isLong\n) internal view returns (uint256) {\n    uint256 reservedUsd;\n\n    if (isLong) {\n        uint256 openInterestInTokens = getOpenInterestInTokens(dataStore, market, isLong);\n        reservedUsd = openInterestInTokens * prices.indexTokenPrice.max;\n    } else {\n        reservedUsd = getOpenInterest(dataStore, market, isLong);\n    }\n\n    return reservedUsd;\n}\n```
MEDIUM severity: The LiquidityMining codebase contains several methods that feature unbounded loops, which can lead t. The LiquidityMining codebase contains several methods that feature unbounded loops, which can lead to catastrophic consequences when dealing with large datasets. Specifically, the methods in question utilize `for` loops that iterate over arrays without imposing any bounds or termination conditions,...

Vulnerable code:
```\nfor (uint256 i = 0; i < _teamsNumber; i++) {\n```\n```\nfor (uint256 i = 0; i < _membersNumber; i++) {\n```\n```\nfor (uint256 i = 0; i < _usersNumber; i++) {\n```
MEDIUM severity: The `withdrawUnstakedTokens` function is responsible for processing unstaked tokens for a given stak. The `withdrawUnstakedTokens` function is responsible for processing unstaked tokens for a given staker. The function iterates over all batches of unstaked tokens, checking if the unstaking period has expired. If the period has passed, the function adds the corresponding balance to a running total an...

Vulnerable code:
```\nfunction withdrawUnstakedTokens(address staker)\n    public\n    virtual\n    override\n    whenNotPaused\n{\n    require(staker == _msgSender(), "LQ20");\n\n    uint256 _withdrawBalance;\n    uint256 _unstakingExpirationLength = _unstakingExpiration[staker].length;\n    uint256 _counter = _withdrawCounters[staker];\n\n    for (uint256 i = _counter; i < _unstakingExpirationLength; i = i.add(1)) {\n        (uint256 _getUnstakeTime,, ) = getUnstakeTime(_unstakingExpiration[staker][i]);\n        if (block.timestamp >= _getUnstakeTime) {\n            _withdrawBalance = _withdrawBalance.add(_unstakingAmount[staker][i]);\n            _unstakingExpiration[staker][i] = 0;\n            _unstakingAmount[staker][i] = 0;\n            _withdrawCounters[staker] = _withdrawCounters[staker].add(1);\n        }\n    }\n\n    require(_withdrawBalance > 0, "LQ21");\n    emit WithdrawUnstakeTokens(staker, _withdrawBalance, block.timestamp);\n    _uTokens.mint(staker, _withdrawBalance);\n}\n```
MEDIUM severity: The Moloch contract's use of a boolean array (`bool[6] flags`) to store multiple flags related to a . The Moloch contract's use of a boolean array (`bool[6] flags`) to store multiple flags related to a proposal is a potential source of confusion. The flags, which include sponsored, processed, didPass, cancelled, whitelist, and guildkick, are not explicitly defined within the code, making it challeng...

Vulnerable code:
```\nbool[6] flags; // flags for sponsored, processed, didPass, cancelled, whitelist, guildkick\n```\n```\nbool[6] memory flags = {0}; // [sponsored, processed, didPass, cancelled, whitelist, guildkick]\n```
MEDIUM severity: The `GMXVault` contract's setter functions for the `ExchangeRouter` and `GMXOracle` contracts are cr. The `GMXVault` contract's setter functions for the `ExchangeRouter` and `GMXOracle` contracts are crucial for maintaining the integrity of the state variables storing their addresses. This is because the GMX documentation explicitly states that these contracts' addresses will change as new logic is...

Vulnerable code:
```\nif using contracts such as the ExchangeRouter, Oracle or Reader:\n    do note that their addresses will change as new logic is added\n```
MEDIUM severity: The vulnerability arises when another module is added to the safe, bypassing the `enableNewModule()`. The vulnerability arises when another module is added to the safe, bypassing the `enableNewModule()` function that increments the `enabledModuleCount`. This manipulation disrupts the module validation process in `checkTransaction()` and `checkAfterExecution()`, potentially causing the safe to become...

Vulnerable code:
```\n(address[] memory modules) = safe.getModulesPaginated(SENTINEL_OWNERS, enabledModuleCount);\n_existingModulesHash = keccak256(abi.encode(modules));\n```\n```\n(address[] memory modules) = safe.getModulesPaginated(SENTINEL_OWNERS, enabledModuleCount + 1);\n\nif (keccak256(abi.encode(modules))!= _existingModulesHash) {\n    revert SignersCannotChangeModules();\n}\n```
MEDIUM severity: The codebase contains multiple functions with the same name, `reduce`, which are overloaded with dif. The codebase contains multiple functions with the same name, `reduce`, which are overloaded with different parameters. This can lead to decreased code readability and increased likelihood of bugs being missed. The multiple implementations of the `reduce` function, each with its own specific logic, c...

Vulnerable code:
```\nfunction reduce(PartialDifferencesValue storage sequence, uint amount, uint month) internal returns (Fraction memory) {\n    require(month.add(1) >= sequence.firstUnprocessedMonth, "Can't reduce value in the past");\n    if (sequence.firstUnprocessedMonth == 0) {\n        return createFraction(0);\n    }\n    uint value = getAndUpdateValue(sequence, month);\n    if (value == 0) {\n        return createFraction(0);\n    }\n\n    uint _amount = amount;\n    if (value < amount) {\n        _amount = value;\n    }\n\n    Fraction memory reducingCoefficient = createFraction(value.sub(_amount), value);\n    reduce(sequence, reducingCoefficient, month);\n    return reducingCoefficient;\n}\n\nfunction reduce(PartialDifferencesValue storage sequence, Fraction memory reducingCoefficient, uint month) internal {\n    reduce(sequence, sequence, reducingCoefficient, month, false);\n}\n\nfunction reduce(\n    PartialDifferencesValue storage sequence,\n    PartialDifferencesValue storage sumSequence,\n    Fraction memory reducingCoefficient,\n    uint month\n) internal {\n    reduce(sequence, sumSequence, reducingCoefficient, month, true);\n}\n\nfunction reduce(\n    PartialDifferencesValue storage sequence,\n    PartialDifferencesValue storage sumSequence,\n    Fraction memory reducingCoefficient,\n    uint month,\n    bool hasSumSequence\n) internal {\n    require(month.add(1) >= sequence.firstUnprocessedMonth, "Can't reduce value in the past");\n    if (hasSumSequence) {\n        require(month.add(1) >= sumSequence.firstUnprocessedMonth, "Can't reduce value in the past");\n    }\n    require(reducingCoefficient.numerator <= reducingCoefficient.denominator, "Increasing of values is not implemented");\n    if (sequence.firstUnprocessedMonth == 0) {\n        return;\n    }\n    uint value = getAndUpdateValue(sequence, month);\n    if (value == 0) {\n        return;\n    }\n\n    uint newValue = sequence.value.mul(reducingCoefficient.numerator).div(reducingCoefficient.denominator);\n    if (hasSumSequence) {\n        subtract(sumSequence, sequence.value.sub(newValue), month);\n    }\n    sequence.value = newValue;\n\n    for (uint i = month.add(1); i <= sequence.lastChangedMonth; ++i) {\n        uint newDiff = sequence.subtractDiff[i].mul(reducingCoefficient.numerator).div(reducingCoefficient.denominator);\n        if (hasSumSequence) {\n            sumSequence.subtractDiff[i] = sumSequence.subtractDiff[i\n```