Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The vulnerability in the 0x Adaptor (ZeroExAdapter) allows an attacker to manipulate the recipient o. The vulnerability in the 0x Adaptor (ZeroExAdapter) allows an attacker to manipulate the recipient of the output/purchased tokens during the emergency vault settlement process. This is because the `from` parameter of the `getExecutionData` function is ignored, giving the attacker the flexibility to...

Vulnerable code:
```\nFile: UniV2Adapter.sol\n\nfunction getExecutionData(address from, Trade calldata trade)\n    {\n        executionCallData = abi.encodeWithSelector(\n            IUniV2Router2.swapExactTokensForTokens.selector,\n            trade.amount,\n            trade.limit,\n            data.path,\n            from,\n            trade.deadline\n        );\n    }\n```\n```\nFile: ZeroExAdapter.sol\n\nlibrary ZeroExAdapter {\n    function getExecutionData(address from, Trade calldata trade)\n        internal view returns (\n            address spender,\n            address target,\n            uint256,\n            bytes memory executionCallData\n        ) {\n        spender = Deployments.ZERO_EX;\n        target = Deployments.ZERO_EX;\n        executionCallData = trade.exchangeData;\n    }\n}\n```\n```\nfunction sellToLiquidityProvider(\n    IERC20TokenV06 inputToken,\n    IERC20TokenV06 outputToken,\n    ILiquidityProvider provider,\n    address recipient,\n    uint256 sellAmount,\n    uint256 minBuyAmount,\n    bytes calldata auxiliaryData\n) {\n    /// @param inputToken The token being sold.\n    /// @param outputToken The token being bought.\n    /// @param provider The address of the on-chain liquidity provider\n    ///        to trade with.\n    /// @param recipient The recipient of the bought tokens. If equal to\n    ///        address(0), `msg.sender` is assumed to be the recipient.\n    /// @param sellAmount The amount of `inputToken` to sell.\n    /// @param minBuyAmount The minimum acceptable amount of `outputToken` to\n    ///        buy. Reverts if this amount is not satisfied.\n    /// @param auxiliaryData Auxiliary data supplied to the `provider` contract.\n    /// @return boughtAmount The amount of `outputToken` bought.\n```\n```\nfunction sellTokenForTokenToUniswapV3(\n    bytes memory encodedPath,\n    uint256 sellAmount,\n    uint256 minBuyAmount,\n    address recipient\n) {\n    /// @dev Sell a token for another token directly against uniswap v3.\n    /// @param encodedPath Uniswap-encoded path.\n    /// @param sellAmount amount of the first token in the path to sell.\n    /// @param minBuyAmount Minimum amount of the last token in the path to buy.\n    /// @param recipient The recipient of the bought tokens. Can be zero for sender.\n    /// @return buyAmount Amount of the last token in the path bought.\n    // Code here\n```
MEDIUM severity: The smart contract's default gauge point function, `defaultGaugePointFunction`, fails to properly ha. The smart contract's default gauge point function, `defaultGaugePointFunction`, fails to properly handle a specific scenario where the percentage of the Base Deposited Value (BDV) equals the optimal percentage (`optimalPercentDepositedBdv`). This oversight results in an unintended reduction of gauge...

Vulnerable code:
```\nfunction testnew_GaugePointAdjustment() public {\n    uint256 currentGaugePoints = 1189;\n    uint256 optimalPercentDepositedBdv = 64;\n    uint256 percentOfDepositedBdv = 64;\n\n    uint256 newGaugePoints = gaugePointFacet.defaultGaugePointFunction(\n        currentGaugePoints,\n        optimalPercentDepositedBdv,\n        percentOfDepositedBdv\n    );\n\n    assertTrue(newGaugePoints <= MAX_GAUGE_POINTS, "New gauge points exceed the maximum allowed");\n    assertEq(newGaugePoints, currentGaugePoints, "Gauge points adjustment does not match expected outcome");\n}\n```
MEDIUM severity: The `updatePool()` function in the provided code is susceptible to a potential overflow issue in the. The `updatePool()` function in the provided code is susceptible to a potential overflow issue in the `accRewardPerShare` variable, which is allocated only 128 bits in the `PoolInfo` struct. This limited allocation size can lead to an overflow condition when the counter is continuously incremented, p...

Vulnerable code:
```\nstruct PoolInfo {\n    uint128 accRewardPerShare;\n    uint64 lastRewardTime;\n    uint64 allocPoint;\n}\n```
MEDIUM severity: The RocketDAO stores personally identifiable member information (PII), including email addresses, on. The RocketDAO stores personally identifiable member information (PII), including email addresses, on the blockchain. This sensitive data is accessible to anyone, allowing potential attackers to de-pseudonymize users and correlate Ethereum addresses with email addresses. This vulnerability poses a si...

Vulnerable code:
```\nreturn MemberDetails{\n    Address: memberAddress,\n    Exists: exists,\n    ID: id,\n    Email: email,\n    JoinedBlock: joinedBlock,\n    LastProposalBlock: lastProposalBlock,\n    RPLBondAmount: rplBondAmount,\n    UnbondedValidatorCount: unbondedValidatorCount,\n}, nil\n```\n```\nfunction getMemberEmail(address _nodeAddress) public view returns (string memory) {\n    return getString(keccak256(abi.encodePacked(daoNameSpace, "member.email", _nodeAddress)));\n}\n```
MEDIUM severity: The `RocketStorage` contract's deployment process involves multiple transactions, which leaves the c. The `RocketStorage` contract's deployment process involves multiple transactions, which leaves the contract in an unprotected state on the blockchain for a brief period. During this window, an attacker can exploit the vulnerability by monitoring the mempool for new deployments of the `RocketStorage`...

Vulnerable code:
```\nmodifier onlyLatestRocketNetworkContract() {\n    if (boolStorage[keccak256(abi.encodePacked("contract.storage.initialised"))] == true) {\n        require(boolStorage[keccak256(abi.encodePacked("contract.exists", msg.sender))], "Invalid or outdated network contract");\n    }\n}\n```
MEDIUM severity: The `setIncentiveSettings` function can be halted indefinitely during a rebalance operation when the. The `setIncentiveSettings` function can be halted indefinitely during a rebalance operation when the supply cap is reached at Aave. This occurs when the rebalance process requires borrowing more assets than the maximum trade size, causing the `twapLeverageRatio` to be set to the targeted leverage. H...

Vulnerable code:
```\nfunction setIncentiveSettings(IncentiveSettings memory _newIncentiveSettings) external onlyOperator noRebalanceInProgress {\n    incentive = _newIncentiveSettings;\n\n    _validateNonExchangeSettings(methodology, execution, incentive);\n\n    emit IncentiveSettingsUpdated(\n        incentive.etherReward,\n        incentive.incentivizedLeverageRatio,\n        incentive.incentivizedSlippageTolerance,\n        incentive.incentivizedTwapCooldownPeriod\n    );\n}\n```
MEDIUM severity: This vulnerability allows a blacklisted creditor to block all repayments besides emergency closure. . This vulnerability allows a blacklisted creditor to block all repayments besides emergency closure. The issue arises in the repayment process, where the code directly transfers tokens from the vault to the creditor. If the creditor is blacklisted for the `holdToken`, the transfer operation will reve...

Vulnerable code:
```\naddress creditor = underlyingPositionManager.ownerOf(loan.tokenId);\n// Increase liquidity and transfer liquidity owner reward\n_increaseLiquidity(cache.saleToken, cache.holdToken, loan, amount0, amount1);\n\nuint256 liquidityOwnerReward = FullMath.mulDiv(\n    params.totalFeesOwed,\n    cache.holdTokenDebt,\n    params.totalBorrowedAmount\n) / Constants.COLLATERAL_BALANCE_PRECISION;\n\nVault(VAULT_ADDRESS).transferToken(cache.holdToken, creditor, liquidityOwnerReward);\n```
MEDIUM severity: The vulnerability lies in the initialization logic of the `ERC20WrapperGluwacoin` contract, which is. The vulnerability lies in the initialization logic of the `ERC20WrapperGluwacoin` contract, which is an upgradeable contract that inherits from multiple contracts in its hierarchy. The `__C_init_unchained` function is responsible for initializing the contract, but it is not properly chained in the c...

Vulnerable code:
```\nfunction __ERC20WrapperGluwacoin_init(\n    string memory name,\n    string memory symbol,\n    IERC20 token\n) internal initializer {\n    __Context_init_unchained();\n    __ERC20_init_unchained(name, symbol);\n    __ERC20ETHless_init_unchained();\n    __ERC20Reservable_init_unchained();\n    __AccessControlEnumerable_init_unchained();\n    __ERC20Wrapper_init_unchained(token);\n    __ERC20WrapperGluwacoin_init_unchained();\n}\n```\n```\nERC20WrapperGluwacoin\nERC20Reservable\nERC20ETHless\nERC20Wrapper\nERC20Upgradeable\nIERC20MetadataUpgradeable\nIERC20Upgradeable\nAccessControlEnumerableUpgradeable\nAccessControlUpgradeable\nERC165Upgradeable\nIERC165Upgradeable\nIAccessControlEnumerableUpgradeable\nIAccessControlUpgradeable\nContextUpgradeable\nInitializable\n```
MEDIUM severity: The vulnerability lies in the lack of deposit count validation in the `depositETHIntoMultipleRounds(. The vulnerability lies in the lack of deposit count validation in the `depositETHIntoMultipleRounds()` function and the `rolloverETH()` function. This allows the number of deposits in a round to exceed the maximum allowed limit, `MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND`. \n\nWhen the current round's de...

Vulnerable code:
```\nif (\n    _shouldDrawWinner(\n        startingRound.numberOfParticipants,\n        startingRound.maximumNumberOfParticipants,\n        startingRound.deposits.length\n    )\n) {\n    _drawWinner(startingRound, startingRoundId);\n}\n```\n```\n_startRound({\n    _roundsCount: roundId\n})\n```\n```\nif (\n   !paused() &&\n    _shouldDrawWinner(numberOfParticipants, round.maximumNumberOfParticipants, round.deposits.length)\n) {\n    _drawWinner(round, roundId);\n}\n```\n```\nfunction test_audit_deposit_more_than_max() public {\n    address alice = makeAddr("Alice");\n    address bob = makeAddr("Bob");\n\n    vm.deal(alice, 2 ether);\n    vm.deal(bob, 2 ether);\n\n    uint256[] memory amounts = new uint256[](2);\n    amounts[0] = 0.01 ether;\n    amounts[1] = 0.01 ether;\n\n    uint256 MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND = 100;\n    for (uint i = 0; i < MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND / 2; i++) {\n        vm.prank(alice);\n        yolo.depositETHIntoMultipleRounds{value: 0.02 ether}(amounts);\n\n        vm.prank(bob);\n        yolo.depositETHIntoMultipleRounds{value: 0.02 ether}(amounts);\n    }\n\n    vm.prank(owner);\n    yolo.togglePaused();\n\n    vm.prank(VRF_COORDINATOR);\n    uint256[] memory randomWords = new uint256[](1);\n    uint256 randomWord = 123;\n    randomWords[0] = randomWord;\n    yolo.rawFulfillRandomWords(FULFILL_RANDOM_WORDS_REQUEST_ID, randomWords);\n\n    vm.prank(owner);\n    yolo.togglePaused();\n\n    amounts = new uint256[](1);\n    amounts[0] = 0.01 ether;\n    vm.prank(bob);\n    yolo.depositETHIntoMultipleRounds{value: 0.01 ether}(amounts);\n\n    (\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n        YoloV2.Deposit[] memory round2Deposits\n    ) = yolo.getRound(2);\n\n    assertEq(round2Deposits.length, MAXIMUM_NUMBER_OF_DEPOSITS_PER_ROUND + 1);\n}\n```
MEDIUM severity: The Staking#_unstake function in the smart contract allows any msg.sender to unstake tokens for any . The Staking#_unstake function in the smart contract allows any msg.sender to unstake tokens for any owner that has approved them. However, when msg.sender is not the owner, the votes are removed from msg.sender instead of the owner. This vulnerability can be exploited to hijack or damage voting powe...

Vulnerable code:
```\naddress owner = ownerOf(_tokenId);\nif (msg.sender!= owner &&!isApprovedForAll[owner][msg.sender] && msg.sender!= getApproved[_tokenId]) {\n    revert NotAuthorized();\n```\n```\nuint lostVotingPower;\n\nfor (uint i = 0; i < numTokens; i++) {\n    lostVotingPower += _unstakeToken(_tokenIds[i], _to);\n}\n\nvotesFromOwnedTokens[msg.sender] -= lostVotingPower;\n\ntokenVotingPower[getDelegate(msg.sender)] -= lostVotingPower;\ntotalTokenVotingPower -= lostVotingPower;\n```
MEDIUM severity: The `calcBase` variable is declared multiple times within various methods in the `RocketAuctionManag. The `calcBase` variable is declared multiple times within various methods in the `RocketAuctionManager` contract, which poses a risk of inconsistencies and potential errors. This is because if the value of `calcBase` is ever updated, it may not be reflected uniformly across all instances where it is...

Vulnerable code:
```\nfunction getLotPriceByTotalBids(uint256 _index) override public view returns (uint256) {\n    uint256 calcBase = 1 ether;\n    return calcBase.mul(getLotTotalBidAmount(_index)).div(getLotTotalRPLAmount(_index));\n}\n```\n```\nfunction getLotClaimedRPLAmount(uint256 _index) override public view returns (uint256) {\n    uint256 calcBase = 1 ether;\n    return calcBase.mul(getLotTotalBidAmount(_index)).div(getLotCurrentPrice(_index));\n}\n```\n```\nuint256 calcBase = 1 ether;\n```\n```\nuint256 bidAmount = msg.value;\nuint256 calcBase = 1 ether;\n```\n```\nuint256 calcBase = 1 ether;\nuint256 rplAmount = calcBase.mul(bidAmount).div(currentPrice);\n```
MEDIUM severity: This vulnerability allows an attacker to immediately claim rewards belonging to others after staking. This vulnerability allows an attacker to immediately claim rewards belonging to others after staking. The issue arises when a new user, Bob, mints 100 shares of LMPVault or DV. The `_mint` function increases Bob's balance and triggers the `_afterTokenTransfer` hook, which automatically stakes the ne...

Vulnerable code:
```\nFile: ERC20.sol\n\nfunction _mint(address account, uint256 amount) internal virtual {\n    _beforeTokenTransfer(address(0), account, amount);\n\n    _totalSupply += amount;\n    unchecked {\n        _balances[account] += amount;\n    }\n\n    _afterTokenTransfer(address(0), account, amount);\n}\n```\n```\nFile: LMPVault.sol\n\nfunction _afterTokenTransfer(address from, address to, uint256 amount) internal virtual override {\n    if (to!= address(0)) {\n        rewarder.stake(to, amount);\n    }\n}\n```\n```\nFile: MainRewarder.sol\n\nfunction stake(address account, uint256 amount) public onlyStakeTracker {\n    _updateReward(account);\n    _stake(account, amount);\n\n    for (uint256 i = 0; i < extraRewards.length; i++) {\n        IExtraRewarder(extraRewards[i]).stake(account, amount);\n    }\n}\n```\n```\nfunction _updateReward(address account) internal {\n    uint256 earnedRewards = 0;\n    rewardPerTokenStored = rewardPerToken();\n    lastUpdateBlock = lastBlockRewardApplicable();\n\n    if (account!= address(0)) {\n        earnedRewards = earned(account);\n        rewards[account] = earnedRewards;\n        userRewardPerTokenPaid[account] = rewardPerTokenStored;\n    }\n\n    emit UserRewardUpdated(account, earnedRewards, rewardPerTokenStored, lastUpdateBlock);\n}\n\nfunction balanceOf(address account) public view returns (uint256) {\n    return stakeTracker.balanceOf(account);\n}\n\nfunction earned(address account) public view returns (uint256) {\n    return (balanceOf(account) * (rewardPerToken() - userRewardPerTokenPaid[account]) / 1e18) + rewards[account];\n}\n```
MEDIUM severity: The vulnerability allows an attacker to manipulate the unclaimed yield of a user's account, potentia. The vulnerability allows an attacker to manipulate the unclaimed yield of a user's account, potentially leading to a loss of assets. Specifically, an attacker can convert the unclaimed yield from the target token to PT + YT, which may have a lower market value than the target token. This can occur w...

Vulnerable code:
```\nfunction issue(\n    address to,\n    uint256 underlyingAmount\n) external nonReentrant whenNotPaused notExpired returns (uint256 issued) {\n    lscales[to] = _maxscale;\n    delete unclaimedYields[to];\n\n    uint256 yBal = _yt.balanceOf(to);\n\n    if (_lscale!= 0) {\n        accruedInTarget += _computeAccruedInterestInTarget(_maxscale, _lscale, yBal);\n    }\n\n    uint256 sharesUsed = sharesMinted + accruedInTarget;\n    uint256 fee = sharesUsed.mulDivUp(issuanceFeeBps, MAX_BPS);\n    issued = (sharesUsed - fee).mulWadDown(_maxscale);\n\n    issuanceFees += fee;\n    _mint(to, issued);\n    _yt.mint(to, issued);\n}\n```
MEDIUM severity: The system's centralized power structure initially allows the `unregisterKey` (creator of the contra. The system's centralized power structure initially allows the `unregisterKey` (creator of the contract) to remove nodes in the `Stages.Active` state from the registry within the first year after deployment. This is achieved through the `removeNodeFromRegistry` function, which can only be called duri...

Vulnerable code:
```\nfunction removeNodeFromRegistry(address _signer)\n    external\n    onlyActiveState(_signer)\n{\n    require(block.timestamp < (blockTimeStampDeployment + YEAR_DEFINITION), "only in 1st year");\n    require(msg.sender == unregisterKey, "only unregisterKey is allowed to remove nodes");\n\n    SignerInformation storage si = signerIndex[_signer];\n    In3Node memory n = nodes[si.index];\n\n    unregisterNodeInternal(si, n);\n}\n```
MEDIUM severity: The `slash` and `seize` functions in the Keep protocol's specification are intended to penalize misb. The `slash` and `seize` functions in the Keep protocol's specification are intended to penalize misbehaving operators by deducting a specified amount or their remaining stake, whichever is lower. However, the current implementation fails to adhere to this specification. When attempting to slash or s...

Vulnerable code:
```\n/**\n * @dev Slash provided token amount from every member in the misbehaved operators array and burn 100% of all the tokens.\n * @param amount Token amount to slash from every misbehaved operator.\n * @param misbehavedOperators Array of addresses to seize the tokens from.\n */\nfunction slash(uint256 amount, address[] memory misbehavedOperators)\n    public\n    onlyApprovedOperatorContract(msg.sender) {\n    for (uint i = 0; i < misbehavedOperators.length; i++) {\n        address operator = misbehavedOperators[i];\n        require(authorizations[msg.sender][operator], "Not authorized");\n        operators[operator].amount = operators[operator].amount.sub(amount);\n    }\n\n    token.burn(misbehavedOperators.length.mul(amount));\n}\n\n/**\n * @dev Seize provided token amount from every member in the misbehaved operators array. The tattletale is rewarded with 5% of the total seized amount scaled by the reward adjustment parameter and the rest 95% is burned.\n * @param amount Token amount to seize from every misbehaved operator.\n * @param rewardMultiplier Reward adjustment in percentage. Min 1% and 100% max.\n * @param tattletale Address to receive the 5% reward.\n * @param misbehavedOperators Array of addresses to seize the tokens from.\n */\nfunction seize(\n    uint256 amount,\n    uint256 rewardMultiplier,\n    address tattletale,\n    address[] memory misbehavedOperators\n) public onlyApprovedOperatorContract(msg.sender) {\n    for (uint i = 0; i < misbehavedOperators.length; i++) {\n        address operator = misbehavedOperators[i];\n        require(authorizations[msg.sender][operator], "Not authorized");\n        operators[operator].amount = operators[operator].amount.sub(amount);\n    }\n\n    uint256 total = misbehavedOperators.length.mul(amount);\n    uint256 tattletaleReward = (total.mul(5).div(100)).mul(rewardMultiplier).div(100);\n\n    token.transfer(tattletale, tattletaleReward);\n    token.burn(total.sub(tattletaleReward));\n}\n```
MEDIUM severity: The `init` function in the `zAuction` contract is vulnerable to fron-running attacks due to its unpr. The `init` function in the `zAuction` contract is vulnerable to fron-running attacks due to its unprotected initialization mechanism. This method, intended to be executed only once, can be called by anyone, allowing an attacker to monitor the mempool for new deployments of the contract and potential...

Vulnerable code:
```\nfunction init(address accountantAddress) external {\n    require(!initialized);\n    initialized = true;\n    accountant = zAuctionAccountant(accountantAddress);\n}\n```
MEDIUM severity: The `recreateBlockheaders` function in the BlockhashRegistry contract is vulnerable to an invalid pa. The `recreateBlockheaders` function in the BlockhashRegistry contract is vulnerable to an invalid parent hash attack. Specifically, it allows an attacker to inject an invalid parent hash, which can be extracted from a blockheader with a zero hash, into the trust chain. This is because the `reCalcula...

Vulnerable code:
```\nfor (uint i = 0; i < _blockheaders.length; i++) {\n    (calcParent, calcBlockhash) = getParentAndBlockhash(_blockheaders[i]);\n    if (calcBlockhash!= currentBlockhash) {\n        return 0x0;\n    }\n    currentBlockhash = calcParent;\n}\n```
MEDIUM severity: The `_removeFromQueue` function is responsible for removing a specified number of elements from the . The `_removeFromQueue` function is responsible for removing a specified number of elements from the `withdrawalQueue` array. However, the implementation of this function is gas-greedy, which can lead to unintended consequences. The function iterates over the entire `withdrawalQueue` array, even when...

Vulnerable code:
```\nfunction _removeFromQueue(uint256 _countToRemove) internal {\n    for (uint256 i = 0; i < _countToRemove; i++) {\n        delete withdrawalsInfo[withdrawalQueue[i]];\n    }\n\n    if (_countToRemove == withdrawalQueue.length) {\n        delete withdrawalQueue;\n    } else {\n        uint256 _remainingArrLength = withdrawalQueue.length.sub(_countToRemove);\n        address[] memory _remainingArr = new address[](_remainingArrLength);\n\n        for (uint256 j = 0; j < _remainingArrLength; j++) {\n            _remainingArr[j] = withdrawalQueue[j + _countToRemove];\n        }\n\n        withdrawalQueue = _remainingArr;\n    }\n}\n```