Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The Balancer Oracle, used by the MetaStable2 balancer leverage vault, relies on infrequent updates t. The Balancer Oracle, used by the MetaStable2 balancer leverage vault, relies on infrequent updates to provide accurate price information. The pool processes an average of only 1.5 transactions per day, resulting in an average update interval of approximately 16 hours. Moreover, there are days with o...

Vulnerable code:
```\nFile: TwoTokenPoolUtils.sol\n\nfunction _getOraclePairPrice(\n    TwoTokenPoolContext memory poolContext,\n    OracleContext memory oracleContext,\n    ITradingModule tradingModule\n) internal view returns (uint256 oraclePairPrice) {\n    uint256 balancerWeightedPrice;\n    if (oracleContext.balancerOracleWeight > 0) {\n        uint256 balancerPrice = BalancerUtils._getTimeWeightedOraclePrice(\n            address(poolContext.basePool.pool),\n            IPriceOracle.Variable.PAIR_PRICE,\n            oracleContext.oracleWindowInSeconds\n        );\n\n        if (poolContext.primaryIndex == 1) {\n            // If the primary index is the second token, we need to invert\n            // the balancer price.\n            balancerPrice = BalancerConstants.BALANCER_PRECISION_SQUARED / balancerPrice;\n        }\n\n        balancerWeightedPrice = balancerPrice * oracleContext.balancerOracleWeight;\n    }\n\n    uint256 chainlinkWeightedPrice;\n    if (oracleContext.balancerOracleWeight < BalancerConstants.BALANCER_ORACLE_WEIGHT_PRECISION) {\n        (int256 rate, int256 decimals) = tradingModule.getOraclePrice(\n            poolContext.primaryToken, poolContext.secondaryToken\n        );\n        require(rate > 0);\n        require(decimals >= 0);\n\n        if (uint256(decimals)!= BalancerConstants.BALANCER_PRECISION) {\n            rate = (rate * int256(BalancerConstants.BALANCER_PRECISION)) / decimals;\n        }\n\n        // No overflow in rate conversion, checked above\n        chainlinkWeightedPrice = uint256(rate) * \n            (BalancerConstants.BALANCER_ORACLE_WEIGHT_PRECISION - oracleContext.balancerOracleWeight);\n    }\n\n    oraclePairPrice = (balancerWeightedPrice + chainlinkWeightedPrice) / \n        BalancerConstants.BALANCER_ORACLE_WEIGHT_PRECISION;\n```\n```\nFile: BalancerUtils.sol\n\nfunction _getTimeWeightedOraclePrice(\n    address pool,\n    IPriceOracle.Variable variable,\n    uint256 secs\n) internal view returns (uint256) {\n    IPriceOracle.OracleAverageQuery[] memory queries = new IPriceOracle.OracleAverageQuery[](1);\n\n    queries[0].variable = variable;\n    queries[0].secs = secs;\n    queries[0].ago = 0; // now\n\n    return IPriceOracle(pool).getTimeWeightedAverage(queries)[0];\n}\n```
MEDIUM severity: The RLPReader's `toUint` method in the current implementation allows for multiple valid encodings of. The RLPReader's `toUint` method in the current implementation allows for multiple valid encodings of the same transaction data, leading to the creation of multiple unique IDs for the same data. This is due to the way the method decodes bytes, which can result in different interpretations of the same...

Vulnerable code:
```\nresult := mload(memPtr)\n```\n```\nreturn keccak256(abi.encodePacked(\n    _txBytes,\n    _outputIndex,\n    _utxoPosValue\n));\n```\n```\nreturn keccak256(abi.encodePacked(_txBytes, _outputIndex));\n```\n```\nbytes32 hashData = keccak256(abi.encodePacked(_txBytes, _utxoPos.value));\n```\n```\nreturn uint160(uint256(keccak256(_txBytes)) 105).setBit(151);\n```\n```\nbytes32 leafData = keccak256(data.txBytes);\n```
MEDIUM severity: The Liquidation Accountant's `claim()` function is responsible for updating the vault's y-intercept . The Liquidation Accountant's `claim()` function is responsible for updating the vault's y-intercept based on the balance of the contract after funds have been distributed. However, this calculation is performed after the balance has already been updated, resulting in an incorrect reduction of the y-...

Vulnerable code:
```\nPublicVault(VAULT()).decreaseYIntercept(\n  (expected - ERC20(underlying()).balanceOf(address(this))).mulDivDown(\n    1e18 - withdrawRatio,\n    1e18\n  )\n);\n```
MEDIUM severity: The `extendLock` function in the `veTRUF` contract allows the owner of an expired lock to extend its. The `extendLock` function in the `veTRUF` contract allows the owner of an expired lock to extend its duration. However, this functionality is vulnerable to abuse, as it does not check whether the lock has already ended or not. This means that an attacker can exploit this vulnerability by extending a...

Vulnerable code:
```\nfunction test_ExtendLock_AlreadyEnded() external {\n    uint256 amount = 100e18;\n    uint256 duration = 5 days;\n\n    _stake(amount, duration, alice, alice);\n\n    // 5 days later, lock is ended for Alice\n    skip(5 days + 1);\n\n    (,, uint128 _ends,,) = veTRUF.lockups(alice, 0);\n\n    // Alice's lock is indeed ended\n    assertTrue(_ends < block.timestamp, "lock is ended");\n\n    // 36 days passed\n    skip(36 days);\n\n    // Alice extends her already finished lock 30 more days\n    vm.prank(alice);\n    veTRUF.extendLock(0, 30 days);\n\n    (,, _ends,,) = veTRUF.lockups(alice, 0);\n\n    // Alice's lock can be easily unlocked right away\n    assertTrue(_ends < block.timestamp, "lock is ended");\n\n    // Alice unstakes her lock, basically alice can unstake her lock anytime she likes\n    vm.prank(alice);\n    veTRUF.unstake(0);\n}\n```
MEDIUM severity: The KeyManager's reentrancy protection mechanism, implemented through the `_nonReentrantBefore()` an. The KeyManager's reentrancy protection mechanism, implemented through the `_nonReentrantBefore()` and `_nonReentrantAfter()` functions, is designed to prevent recursive calls to the contract. However, an attacker can potentially bypass this protection by exploiting a third-party contract that has gr...

Vulnerable code:
```\nfunction _nonReentrantAfter() internal virtual {\n    _reentrancyStatus = false;\n}\n```
MEDIUM severity: The `withdrawDeposit` function in the `PaymentRegistry` is designed to ensure a 30-day waiting perio. The `withdrawDeposit` function in the `PaymentRegistry` is designed to ensure a 30-day waiting period before allowing the account owner to withdraw their deposited tokens. This waiting period is intended to prevent accidental or malicious withdrawals. However, a critical issue arises when the `withd...

Vulnerable code:
```\nif (lockedUntil!= 0 && lockedUntil <= now) {\n    deposits[owner].withdrawalLockedUntil[token] = 0;\n\n    address depositAccount = deposits[owner].account;\n    uint256 depositValue;\n\n    if (token == address(0)) {\n        depositValue = depositAccount.balance;\n    } else {\n        depositValue = ERC20Token(token).balanceOf(depositAccount);\n    }\n\n    _transferFromDeposit(\n        depositAccount,\n        owner,\n        token,\n        depositValue\n    );\n\n    emit DepositWithdrawn(\n        depositAccount,\n        owner,\n        token,\n        depositValue\n    );\n} else {\n    _deployDepositAccount(owner);\n\n    lockedUntil = now.add(depositWithdrawalLockPeriod);\n```
MEDIUM severity: The `changeTreasury` function in the `VaultFactoryV2` contract contains a critical misconfiguration.. The `changeTreasury` function in the `VaultFactoryV2` contract contains a critical misconfiguration. Specifically, the `setTreasury` subcall uses the `treasury` variable instead of the `_treasury` variable, which is the intended input parameter. This mistake causes the function to set the treasury f...

Vulnerable code:
```\nfunction changeTreasury(uint256 _marketId, address _treasury)\n    public\n    onlyTimeLocker\n{\n    if (_treasury == address(0)) {\n        revert AddressZero();\n    }\n\n    address[2] memory vaults = marketIdToVaults[_marketId];\n\n    if (vaults[0] == address(0) || vaults[1] == address(0)) {\n        revert MarketDoesNotExist(_marketId);\n    }\n\n    IVaultV2(vaults[0]).whiteListAddress(_treasury);\n    IVaultV2(vaults[1]).whiteListAddress(_treasury);\n    IVaultV2(vaults[0]).setTreasury(_treasury);\n    IVaultV2(vaults[1]).setTreasury(_treasury);\n\n    emit AddressWhitelisted(_treasury, _marketId);\n}\n```\n```\npremiumVault.sendTokens(_epochId, premiumFee, treasury);\npremiumVault.sendTokens(\n    _epochId,\n    premiumTVL - premiumFee,\n    address(collateralVault)\n);\n\ncollateralVault.sendTokens(_epochId, collateralFee, treasury);\ncollateralVault.sendTokens(\n    _epochId,\n    collateralTVL - collateralFee,\n    address(premiumVault)\n);\n```
MEDIUM severity: The UniProxy.depositSwap function in the provided code snippet appears to be vulnerable to a potenti. The UniProxy.depositSwap function in the provided code snippet appears to be vulnerable to a potential reentrancy attack. The function calls the Router.exactInput method without first ensuring that the tokens have been approved. This is a critical oversight, as the exactInput method requires the sen...

Vulnerable code:
```\nrouter = ISwapRouter(_router);\n\nuint256 amountOut;\nuint256 swap;\n\nif (swapAmount < 0) {\n    // swap token1 for token0\n\n    swap = uint256(swapAmount * -1);\n    IHypervisor(pos).token1().transferFrom(msg.sender, address(this), deposit1 + swap);\n    amountOut = router.exactInput(\n        ISwapRouter.ExactInputParams(\n            path,\n            address(this),\n            block.timestamp + swapLife,\n            swap,\n            deposit0\n        )\n    );\n} else {\n    // swap token1 for token0\n    swap = uint256(swapAmount);\n    IHypervisor(pos).token0().transferFrom(msg.sender, address(this), deposit0 + swap);\n\n    amountOut = router.exactInput(\n        ISwapRouter.ExactInputParams(\n            path,\n            address(this),\n            block.timestamp + swapLife,\n            swap,\n            deposit1\n        )\n    );\n}\n```
MEDIUM severity: The vulnerability lies in the insecure initialization of proxy contracts, which can be exploited by . The vulnerability lies in the insecure initialization of proxy contracts, which can be exploited by third-party actors. This occurs when the `initialize` function is not properly protected or is not initialized immediately after deployment. As a result, the implementation contract, intended to be us...

Vulnerable code:
```\nconstructor() public {\n    instance = new MultipleWinners();\n}\n```\n```\nconstructor() public {\n    erc721ControlledInstance = new ERC721Controlled();\n    erc721ControlledBytecode = MinimalProxyLibrary.minimalProxy(address(erc721ControlledInstance));\n}\n```\n```\nconstructor() public {\n    lootBoxActionInstance = new LootBox();\n    lootBoxActionBytecode = MinimalProxyLibrary.minimalProxy(address(lootBoxActionInstance));\n}\n```
MEDIUM severity: The `provideFundingECDSAFraudProof` function in the tbtc system is vulnerable to a potential fund-bu. The `provideFundingECDSAFraudProof` function in the tbtc system is vulnerable to a potential fund-burning issue. The function was designed to ensure that funders have a minimum financial stake in the system, thereby preventing denial-of-service (DoS) attacks. However, the recent change in the fundin...

Vulnerable code:
```\nif (block.timestamp > _d.fundingProofTimerStart + TBTCConstants.getFundingTimeout()) {\n    address(0).transfer(address(this).balance);\n    _d.setFailedSetup();\n```
MEDIUM severity: The `sellCollateral` function in the BBLeverage contract is responsible for selling a user's collate. The `sellCollateral` function in the BBLeverage contract is responsible for selling a user's collateral to obtain YieldBox shares of the asset and repay the user's loan. However, a critical issue arises when the `_repay` action is executed. The `from` parameter, which is set to the user's address, i...

Vulnerable code:
```\nif (memoryData.shareOwed <= memoryData.shareOut) {\n    _repay(from, from, memoryData.partOwed);\n} else {\n    uint256 partOut = totalBorrow.toBase(amountOut, false);\n    _repay(from, from, partOut);\n}\n```\n```\nfunction _repay(address from, address to, uint256 part) internal returns (uint256 amount) {\n    yieldBox.withdraw(assetId, from, address(this), amount, 0);\n}\n```
MEDIUM severity: The `wfCashERC4626` vulnerability arises when the `wfCash` vault, which is designed to mint and rede. The `wfCashERC4626` vulnerability arises when the `wfCash` vault, which is designed to mint and redeem shares of a fee-on-transfer token, fails to accurately account for the underlying asset's fee structure. Specifically, when the vault mints shares to a depositor, it credits the depositor with less...

Vulnerable code:
```\nif (maxFCash < fCashAmount) {\n    uint256 fCashAmountExternal = fCashAmount * precision / uint256(Constants.INTERNAL_TOKEN_PRECISION);\n    require(fCashAmountExternal <= depositAmountExternal);\n\n    // Residual (depositAmountExternal - fCashAmountExternal) will be transferred\n    // back to the account\n    NotionalV2.depositUnderlyingToken{value: msgValue}(address(this), currencyId, fCashAmountExternal);\n} else if (isETH || hasTransferFee || getCashBalance() > 0) {\n```\n```\nelse {\n    actualTransferExternal = GenericToken.safeTransferIn(\n        underlying.tokenAddress, account, underlyingExternalDeposit\n    ).toInt();\n}\n\nnetPrimeSupplyChange = _postTransferPrimeCashUpdate(\n    account, currencyId, actualTransferExternal, underlying, primeRate\n);\n```\n```\n_Mint(receiver, fCashAmount);\n```
MEDIUM severity: The vulnerability lies in the L2 → L1 messaging mechanism, where the prover, a single entity owned b. The vulnerability lies in the L2 → L1 messaging mechanism, where the prover, a single entity owned by Linea, has the capability to manipulate the Merkle tree construction process. Specifically, the prover can intentionally skip messages when building the tree, which would result in the user being un...

Vulnerable code:
```\naddL2MerkleRoots(_finalizationData.l2MerkleRoots, _finalizationData.l2MerkleTreesDepth);\nanchorL2MessagingBlocks(_finalizationData.l2MessagingBlocksOffsets, lastFinalizedBlock);\n```
MEDIUM severity: The MiniGovernance's `changeMaintainer` function allows the controller to modify the maintainer of a. The MiniGovernance's `changeMaintainer` function allows the controller to modify the maintainer of an entity with an ID. This function is designed to ensure that the controller has the authority to make changes to the maintainer, which is typically used for operational purposes. The function is acce...

Vulnerable code:
```\nfunction changeMaintainer(\n    bytes calldata password,\n    bytes32 newPasswordHash,\n    address newMaintainer\n)\n    external\n    virtual\n    override\n    onlyPortal\n    whenNotPaused\n    returns (bool success)\n{\n    require(\n        SELF.PASSWORD_HASH == bytes32(0) ||\n        SELF.PASSWORD_HASH ==\n        keccak256(abi.encodePacked(SELF.ID, password))\n    );\n    SELF.PASSWORD_HASH = newPasswordHash;\n\n    _refreshSenate(newMaintainer);\n\n    success = true;\n}\n```
MEDIUM severity: The `MetaSwap` contract does not verify the existence of an adapter before invoking the `Spender` co. The `MetaSwap` contract does not verify the existence of an adapter before invoking the `Spender` contract's `swap` function. This oversight can lead to unexpected behavior and potential reverts when the `Spender` contract attempts to perform the swap operation with an invalid adapter address.\n\nWh...

Vulnerable code:
```\nfunction swap(\n    string calldata aggregatorId,\n    IERC20 tokenFrom,\n    uint256 amount,\n    bytes calldata data\n) external payable whenNotPaused nonReentrant {\n    Adapter storage adapter = adapters[aggregatorId];\n\n    if (address(tokenFrom)!= Constants.ETH) {\n        tokenFrom.safeTransferFrom(msg.sender, address(spender), amount);\n    }\n\n    spender.swap{value: msg.value}(\n        adapter.addr,\n        tokenFrom,\n        amount,\n        data\n    );\n}\n```\n```\nfunction swap(address adapter, bytes calldata data) external payable {\n    require(adapter!= address(0), "ADAPTER_NOT_SUPPORTED");\n```
MEDIUM severity: The Hats protocol's `mintTopHat()` function allows anyone to mint a top hat by assigning a unique id. The Hats protocol's `mintTopHat()` function allows anyone to mint a top hat by assigning a unique identifier. The top hats are structured with the top 32 bits representing a domain ID, and the lower 224 bits cleared. This design choice enables the creation of up to 2^32, or approximately 4 billion,...

Vulnerable code:
```\nuint32 lastTopHatId;\nuint256 topHatId = uint256(++lastTopHatId) << 224;\n```
MEDIUM severity: The vulnerability lies in the way oDAO members' votes are handled when they leave the organization. . The vulnerability lies in the way oDAO members' votes are handled when they leave the organization. Specifically, the system does not account for the reduction in the total number of oDAO members when a member is kicked or leaves. This allows malicious actors to exploit the situation by voting for a...

Vulnerable code:
```\nRocketDAONodeTrustedInterface rocketDAONodeTrusted = RocketDAONodeTrustedInterface(getContractAddress("rocketDAONodeTrusted"));\n\nif (calcBase.mul(submissionCount).div(rocketDAONodeTrusted.getMemberCount()) >= rocketDAOProtocolSettingsNetwork.getNodeConsensusThreshold()) {\n    updatePrices(_block, _rplPrice);\n}\n```\n```\nfunction executeUpdatePrices(uint256 _block, uint256 _rplPrice) override external onlyLatestContract("rocketNetworkPrices", address(this)) {\n    // Check settings\n    // This comment is not describing the code, so it's removed\n}\n```\n```\nRocketDAONodeTrustedSettingsMinipoolInterface rocketDAO_node_trusted_settings_minipool = \n    RocketDAONodeTrustedSettingsMinipoolInterface(getContractAddress("rocketDAONodeTrustedSettingsMinipool"));\nuint256 quorum = rocketDAO_node.getMemberCount().mul(rocketDAO_node_trusted_settings_minipool.getCancelBondReductionQuorum()).div(calcBase);\nbytes32 totalCancelVotesKey = keccak256(abi.encodePacked("minipool.bond.reduction.vote.count", _minipoolAddress));\nuint256 totalCancelVotes = getUint(totalCancelVotesKey).add(1);\nif (totalCancelVotes > quorum) {\n```\n```\nRocketDAONodeTrustedInterface rocketDAONodeTrusted = RocketDAONodeTrustedInterface(getContractAddress("rocketDAONodeTrusted"));\n\nif (calcBase.mul(submissionCount).div(rocketDAONodeTrusted.getMemberCount()) >= rocketDAOProtocolSettingsNetwork.getNodePenaltyThreshold()) {\n    setBool(executedKey, true);\n    incrementMinipoolPenaltyCount(_minipoolAddress);\n}\n```\n```\nfunction executeUpdatePenalty(address _minipoolAddress, uint256 _block) override external onlyLatestContract("rocketNetworkPenalties", address(this)) {\n    RocketDAOProtocolSettingsNetworkInterface rocketDAOProtocolSettingsNetwork = RocketDAOProtocolSettingsNetworkInterface(getContractAddress("rocketDAOProtocolSettingsNetwork"));\n    rocketDAOProtocolSettingsNetwork.getSubmissionKeys(_minipoolAddress, _block, \n        function (bytes32[] memory _submissionKeys) {\n            // Executes incrementMinipoolPenaltyCount if consensus threshold is reached\n            if (_submissionKeys.length >= rocketDAOProtocolSettingsNetwork.getConsensusThreshold()) {\n                incrementMinipoolPenaltyCount(_minipoolAddress);\n            }\n        }\n    );\n}\n```
MEDIUM severity: When a tophat is unlinked from its admin, it is intended to regain its status as a self-sovereign en. When a tophat is unlinked from its admin, it is intended to regain its status as a self-sovereign entity. However, due to the retention of the `linkedTreeRequests` value, an independent tophat can still be vulnerable to takeover by another admin. This vulnerability arises from the fact that the `lin...

Vulnerable code:
```\nfunction requestLinkTopHatToTree(uint32 _topHatDomain, uint256 _requestedAdminHat) external {\n    uint256 fullTopHatId = uint256(_topHatDomain) << 224; \n    // (256 - TOPHAT_ADDRESS_SPACE);\n\n    _checkAdmin(fullTopHatId);\n\n    linkedTreeRequests[_topHatDomain] = _requestedAdminHat;\n    emit TopHatLinkRequested(_topHatDomain, _requestedAdminHat);\n}\n```\n```\nfunction approveLinkTopHatToTree(uint32 _topHatDomain, uint256 _newAdminHat) external {\n    if (getHatLevel(_newAdminHat) < MAX_LEVELS) {\n        _checkAdmin(buildHatId(_newAdminHat, 1));\n    } else {\n        _checkAdminOrWearer(_newAdminHat);\n    }\n\n    if (_newAdminHat!= linkedTreeRequests[_topHatDomain]) {\n        revert LinkageNotRequested();\n    }\n\n    delete linkedTreeRequests[_topHatDomain];\n\n    _linkTopHatToTree(_topHatDomain, _newAdminHat);\n}\n```\n```\nfunction unlinkTopHatFromTree(uint32 _topHatDomain) external {\n    uint256 fullTopHatId = uint256(_topHatDomain) << 224;\n    _checkAdmin(fullTopHatId);\n\n    delete linkedTreeAdmins[_topHatDomain];\n    emit TopHatLinked(_topHatDomain, 0);\n}\n```
MEDIUM severity: The `Pool.buy` function is susceptible to a price manipulation vulnerability, where users may inadve. The `Pool.buy` function is susceptible to a price manipulation vulnerability, where users may inadvertently pay more than intended for insurance coverage due to changes in the `weeklyPremium` policy. This occurs when a pending `buy` transaction is front-run by another transaction that increases the...

Vulnerable code:
```\nuint256 premium = amount.mul(policy.weeklyPremium).div(RATIO_BASE);\nuint256 allPremium = premium.mul(toWeek.sub(fromWeek));\n```
MEDIUM severity: The Yearn vault contract's `supplyTokenTo` function is vulnerable to partial deposit processing issu. The Yearn vault contract's `supplyTokenTo` function is vulnerable to partial deposit processing issues. When a deposit exceeds the vault's token capacity, the function only processes a portion of the tokens, leaving the remaining amount unprocessed. This behavior is problematic because the function...

Vulnerable code:
```\nreturn v.deposit()\n```\n```\nfunction supplyTokenTo(uint256 _amount, address to) override external {\n    uint256 shares = _tokenToShares(_amount);\n\n    _mint(to, shares);\n\n    // we have to deposit after calculating shares to mint\n    token.safeTransferFrom(msg.sender, address(this), _amount);\n\n    _depositInVault();\n\n    emit SuppliedTokenTo(msg.sender, shares, _amount, to);\n}\n```
MEDIUM severity: The "Unregulated joining fees" vulnerability refers to a security issue in the `join` function of a . The "Unregulated joining fees" vulnerability refers to a security issue in the `join` function of a smart contract, which allows an attacker to manipulate the joining fee to an arbitrary value, potentially resulting in the majority of the deposited amount being redirected to the contract's owner. \n...

Vulnerable code:
```\nfunction join(uint256 amount) external override joiningNotPaused {\n    uint256 fee = amount.mul(joiningFee).div(BASIS_PRECISION);\n    uint256 mintedAmount = mint(amount.sub(fee));\n    claimableFees = claimableFees.add(fee);\n\n    latestJoinBlock[msg.sender] = block.number;\n    token.safeTransferFrom(msg.sender, address(this), amount);\n\n    emit Joined(msg.sender, amount, mintedAmount);\n}\n```\n```\nfunction setJoiningFee(uint256 fee) external onlyOwner {\n    require(fee <= BASIS_PRECISION, "TrueFiPool: Fee cannot exceed transaction value");\n    joiningFee = fee;\n    emit JoiningFeeChanged(fee);\n}\n```\n```\nuint256 private constant BASIS_PRECISION = 10000;\n```