Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The usage of `slot0` in the Real Wagmi codebase is vulnerable to manipulation due to its ease of mod. The usage of `slot0` in the Real Wagmi codebase is vulnerable to manipulation due to its ease of modification. As the most recent data point, `slot0` plays a crucial role in calculating various variables, including reserves. Specifically, the `getAmountsForLiquidity` function, which is called within...

Vulnerable code:
```\n(uint256 amount0, uint256 amount1) = \n    LiquidityAmounts.getAmountsForLiquidity(\n        slots[i].currentSqrtRatioX96,\n        TickMath.getSqrtRatioAtTick(position.lowerTick),\n        TickMath.getSqrtRatioAtTick(position.upperTick),\n        liquidity\n    );\n```\n```\nreserve0 += amount0;\nreserve1 += amount1;\n```
MEDIUM severity: The TokenFaucet smart contract contains redundant and duplicate checks, which can lead to unnecessar. The TokenFaucet smart contract contains redundant and duplicate checks, which can lead to unnecessary computational overhead and potential security vulnerabilities. Specifically, the `require` statements in the `setDripRatePerSecond` function and the `drip` function are identical, checking if the `_...

Vulnerable code:
```\nrequire(_dripRatePerSecond > 0, "TokenFaucet/dripRate-gt-zero");\n\nasset = _asset;\nmeasure = _measure;\nsetDripRatePerSecond(_dripRatePerSecond);\n```\n```\nfunction setDripRatePerSecond(uint256 _dripRatePerSecond) public onlyOwner {\n    require(_dripRatePerSecond > 0, "TokenFaucet/dripRate-gt-zero");\n```\n```\nfunction drip() public returns (uint256) {\n    uint256 currentTimestamp = _currentTime();\n\n    // this should only run once per block.\n    if (lastDripTimestamp == uint32(currentTimestamp)) {\n        return 0;\n    }\n\n    uint256 newSeconds = currentTimestamp.sub(lastDripTimestamp);\n\n    if (measureTotalSupply > 0 && availableTotalSupply > 0 && newSeconds > 0) {\n        uint256 indexDeltaMantissa = measureTotalSupply > 0? FixedPoint.calculateMantissa(newTokens, measureTotalSupply) : 0;\n    }\n```
MEDIUM severity: The `claim` function in the code lacks essential input validation and state changes, leaving it vuln. The `claim` function in the code lacks essential input validation and state changes, leaving it vulnerable to potential errors and security breaches. The function's implementation is currently scattered across other contracts or off-chain processes, making it challenging to identify and address pote...

Vulnerable code:
```\nfunction claim(\n    uint256 policyIndex_,\n    uint256 amount_,\n    address recipient_\n) external onlyPoolManager {\n```
MEDIUM severity: The vulnerability arises from the unnecessary implementation of interfaces in Solidity smart contrac. The vulnerability arises from the unnecessary implementation of interfaces in Solidity smart contracts. Specifically, the code snippet `IAssimilator constant iAsmltr = IAssimilator(address(0));` demonstrates this issue. In this example, the `IAssimilator` interface is being implemented, but its sele...

Vulnerable code:
```\nIAssimilator constant iAsmltr = IAssimilator(address(0));\n```
MEDIUM severity: The `ConvexPositionHandler._claimReweds` function is responsible for harvesting Convex reward tokens. The `ConvexPositionHandler._claimReweds` function is responsible for harvesting Convex reward tokens and extracting the generated yield in ETH from the Curve pool. To achieve this, it calculates the difference in LP token price between the current and previous shares, and then multiplies this differ...

Vulnerable code:
```\nuint256 currentSharePrice = ethStEthPool.getVirtualPrice();\nif (currentSharePrice > prevSharePrice) {\n    // claim any gain on lp token yields\n    uint256 contractLpTokenBalance = lpToken.balanceOf(address(this));\n    uint256 totalLpBalance = contractLpTokenBalance + \n        baseRewardPool.balanceOf(address(this));\n    uint256 yieldEarned = (currentSharePrice - prevSharePrice) * \n        totalLpBalance;\n}\n```\n```\nuint256 lpTokenEarned = yieldEarned / NORMALIZATION_FACTOR;\n```
MEDIUM severity: The `getAccountPrimeDebtBalance()` function, responsible for retrieving the current debt balance of . The `getAccountPrimeDebtBalance()` function, responsible for retrieving the current debt balance of a specified account and currency, contains a critical error. Specifically, the assignment statement `debtBalance = cashBalance < 0? debtBalance : 0;` is incorrect and always returns a value of 0, rega...

Vulnerable code:
```\nfunction getAccountPrimeDebtBalance(uint16 currencyId, address account) external view override returns (int256 debtBalance) {\n    mapping(address => mapping(uint256 => BalanceStorage)) storage store = LibStorage.getBalanceStorage();\n    BalanceStorage storage balanceStorage = store[account][currencyId];\n    int256 cashBalance = balanceStorage.cashBalance;\n\n    debtBalance = cashBalance < 0? cashBalance : 0;\n}\n```
MEDIUM severity: The `D3VaultFunding.userWithdraw()` function is vulnerable to a sandwich attack due to its direct us. The `D3VaultFunding.userWithdraw()` function is vulnerable to a sandwich attack due to its direct use of the `_getExchangeRate` function without considering the `mindTokenAmount`. This allows an attacker to manipulate the exchange rate and potentially cause significant slippage.\n\nThe `_getExchange...

Vulnerable code:
```\nfunction userWithdraw(address to, address user, address token, uint256 dTokenAmount) external nonReentrant allowedToken(token) returns(uint256 amount) {\n    accrueInterest(token);\n    AssetInfo storage info = assetInfo[token];\n    require(dTokenAmount <= IDToken(info.dToken).balanceOf(msg.sender), Errors.DTOKEN_BALANCE_NOT_ENOUGH);\n\n    amount = dTokenAmount * _getExchangeRate(token);\n\n    IDToken(info.dToken).burn(msg.sender, dTokenAmount);\n    IERC20(token).safeTransfer(to, amount);\n    info.balance = info.balance - amount;\n\n    emit UserWithdraw(msg.sender, user, token, amount);\n}\n```\n```\nfunction _getExchangeRate(address token) internal view returns (uint256) {\n    AssetInfo storage info = assetInfo[token];\n    uint256 cash = getCash(token);\n    uint256 dTokenSupply = IERC20(info.dToken).totalSupply();\n    if (dTokenSupply == 0) {\n        return 1e18;\n    }\n    return (cash + info.totalBorrows - (info.totalReserves - info.withdrawnReserves)).div(dTokenSupply);\n}\n```
MEDIUM severity: The `rebalanceAll` function, responsible for rebalancing liquidity across pools and positions, lacks. The `rebalanceAll` function, responsible for rebalancing liquidity across pools and positions, lacks essential slippage protection mechanisms. Specifically, when withdrawing liquidity from pools and depositing it into new positions, there is no safeguard against potential slippage.\n\nThe `rebalance...

Vulnerable code:
```\n_withdraw(_totalSupply, _totalSupply)\n```\n```\n_deposit(reserve0, reserve1, _totalSupply, slots);\n```
MEDIUM severity: The `_calculate_leverage` function in the provided code calculates the leverage by using the sum of . The `_calculate_leverage` function in the provided code calculates the leverage by using the sum of `_debt_value` and `_margin_value` as the numerator, which is incorrect. This can lead to unfair liquidations or over-leveraged positions, depending on the price movements of the underlying assets.\n\n...

Vulnerable code:
```\ndef _calculate_leverage(\n    _position_value: uint256, \n    _debt_value: uint256, \n    _margin_value: uint256\n) -> uint256:\n    if _position_value <= _debt_value:\n        return max_value(uint256)\n\n    return (\n        PRECISION\n        * (_debt_value + _margin_value)\n        / (_position_value - _debt_value)\n        / PRECISION\n    )\n```
MEDIUM severity: The vulnerability in the Router.sol contract lies in its pool address check mechanism, which is susc. The vulnerability in the Router.sol contract lies in its pool address check mechanism, which is susceptible to address collisions. The issue arises from the use of the create2 opcode, which truncates the hash output to 160 bits, reducing the collision resistance to 2^160. This limitation allows an a...

Vulnerable code:
```\nrequire(\n  msg.sender == address(_getPool(tokenIn, tokenOut, fee)),\n  'Router: invalid callback sender'\n);\n```\n```\nfunction _getPool(\n    address tokenA,\n    address tokenB,\n    uint24 fee\n) private view returns (IPool) {\n    return IPool(\n        PoolAddress.computeAddress(\n            factory,\n            tokenA,\n            tokenB,\n            fee,\n            poolInitHash\n        )\n    );\n}\n```
MEDIUM severity: When a user deposits funds into a pool, the current multiplier associated with that pool is stored l. When a user deposits funds into a pool, the current multiplier associated with that pool is stored locally for that specific deposit. This stored value is then used during the withdrawal process, rather than the updated multiplier value that may have been changed by a subsequent call to the `governo...

Vulnerable code:
```\nfunction governorAddPoolMultiplier(\n    uint256 _pid,\n    uint64 lockLength,\n    uint64 newRewardsMultiplier\n) external onlyGovernor {\n    PoolInfo storage pool = poolInfo[_pid];\n    uint256 currentMultiplier = rewardMultipliers[_pid][lockLength];\n\n    if (newRewardsMultiplier < currentMultiplier) {\n        pool.unlocked = true;\n    }\n\n    rewardMultipliers[_pid][lockLength] = newRewardsMultiplier;\n\n    emit LogPoolMultiplier(_pid, lockLength, newRewardsMultiplier);\n}\n```
MEDIUM severity: The vulnerability arises from the potential for Chainlink multisignature entities to intentionally b. The vulnerability arises from the potential for Chainlink multisignature entities to intentionally block access to price feeds, leading to a chainlink revert. This scenario can occur in extreme cases, such as when oracles are taken offline or token prices fall to zero. In these situations, the `late...

Vulnerable code:
```\n(\n    uint80 baseRoundID,\n    int256 basePrice,\n    uint256 baseTimeStamp\n) = baseOracle.latestRoundData();\n```
MEDIUM severity: The `claimSigner()` function is designed to manage the addition of new signers to a safe, ensuring t. The `claimSigner()` function is designed to manage the addition of new signers to a safe, ensuring that the maximum number of signers is not exceeded. When a new user attempts to claim a signer, the function checks if there are already the maximum number of owners on the safe. If there are, it itera...

Vulnerable code:
```\nif (ownerCount >= maxSigs):\n    bool swapped = _swapSigner(owners, ownerCount, maxSigs, currentSignerCount, msg.sender)\n    if not swapped:\n        if there are no invalid owners, we can't add a new signer, so we revert\n        revert NoInvalidSignersToReplace()\n```\n```\nfunction _swapSigner(\n    address[] memory _owners,\n    uint256 _ownerCount,\n    uint256 _maxSigners,\n    uint256 _currentSignerCount,\n    address _signer\n) internal returns (bool success) {\n    address ownerToCheck;\n    bytes memory data;\n\n    for (uint256 i = 0; i < _ownerCount - 1; ) {\n        ownerToCheck = _owners[i];\n\n        if (!isValidSigner(ownerToCheck)) {\n            data = abi.encodeWithSignature(\n                "swapOwner(address,address,address)",\n                _findPrevOwner(_owners, ownerToCheck),\n                ownerToCheck,\n                _signer\n            );\n\n            success = safe.execTransactionFromModule(\n                address(safe),\n                0,\n                data,\n                Enum.Operation.Call\n            );\n\n            if (!success) {\n                revert FailedExecRemoveSigner();\n            }\n\n            if (_currentSignerCount < _maxSigners) {\n                _currentSignerCount++;\n            }\n            break;\n        }\n        i++;\n    }\n}\n```
MEDIUM severity: The liquidation process in the system is vulnerable to manipulation, allowing an attacker to take co. The liquidation process in the system is vulnerable to manipulation, allowing an attacker to take control of a user's entire collateral and underlying tokens for a fraction of the correct price. This occurs when a user has multiple types of debt, and the liquidator calculates the proportion of colla...

Vulnerable code:
```\nuint256 oldShare = pos.debtShareOf[debtToken];\n(uint256 amountPaid, uint256 share) = repayInternal(\n    positionId,\n    debtToken,\n    amountCall\n);\n\nuint256 liqSize = (pos.collateralSize * share) / oldShare;\nuint256 uTokenSize = (pos.underlyingAmount * share) / oldShare;\nuint256 uVaultShare = (pos.underlyingVaultShare * share) / oldShare;\n\npos.collateralSize -= liqSize;\npos.underlyingAmount -= uTokenSize;\npos.underlyingVaultShare -= uVaultShare;\n\ntransfer liqSize wrapped LP Tokens and uVaultShare underlying vault shares to the liquidator\n```\n```\nuint256 liqSize = (pos.collateralSize * share) / oldShare;\nuint256 uTokenSize = (pos.underlyingAmount * share) / oldShare;\nuint256 uVaultShare = (pos.underlyingVaultShare * share) / oldShare;\n```
MEDIUM severity: The vulnerability allows an attacker to create a bid for a non-existent market, which can then be ac. The vulnerability allows an attacker to create a bid for a non-existent market, which can then be accepted when the market is created. This creates a loan that cannot be defaulted, liquidated, or repaid. The issue arises from the lack of verification that the market exists when submitting a bid. The...

Vulnerable code:
```\nFile: TellerV2.sol\n\nif (bidDefaultDuration[_bidId] == 0)\n    return false;\n```\n```\nuint256 owedAmount = (maxCycleOwed * owedTime) / \n    _bid.terms.paymentCycle;\n```\n```\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport { UpgradeableBeacon } from "@openzeppelin/contracts/proxy/beacon/UpgradeableBeacon.sol";\nimport { TellerV2 } from "../contracts/TellerV2.sol";\nimport { CollateralManager } from "../contracts/CollateralManager.sol";\nimport { LenderCommitmentForwarder } from "../contracts/LenderCommitmentForwarder.sol";\nimport { CollateralEscrowV1 } from "../contracts/escrow/CollateralEscrowV1.sol";\nimport { MarketRegistry } from "../contracts/MarketRegistry.sol";\nimport { ReputationManagerMock } from "../contracts/mock/ReputationManagerMock.sol";\nimport { LenderManagerMock } from "../contracts/mock/LenderManagerMock.sol";\nimport { TellerASMock } from "../contracts/mock/TellerASMock.sol";\nimport { TestERC20Token } from "./tokens/TestERC20Token.sol";\nimport "lib/forge-std/src/Test.sol";\nimport "lib/forge-std/src/StdAssertions.sol";\n\ncontract LoansTest is Test {\n    MarketRegistry public marketRegistry;\n    TellerV2 public tellerV2;\n\n    TestERC20Token public principalToken;\n\n    address public alice = address(0x1111);\n    address public bob = address(0x2222);\n    address public owner = address(0x3333);\n\n    function setUp() public {\n        tellerV2 = new TellerV2(address(0));\n\n        marketRegistry = new MarketRegistry();\n        TellerASMock tellerAs = new TellerASMock();\n        marketRegistry.initialize(tellerAs);\n\n        LenderCommitmentForwarder lenderCommitmentForwarder = \n            new LenderCommitmentForwarder(address(tellerV2), address(marketRegistry));\n        CollateralManager collateralManager = new CollateralManager();\n        collateralManager.initialize(address(new UpgradeableBeacon(address(new CollateralEscrowV1()))),\n            address(tellerV2));\n        address rm = address(new ReputationManagerMock());\n        address lm = address(new LenderManagerMock());\n        tellerV2.initialize(0, address(marketRegistry), rm, address(lenderCommitmentForwarder),\n            address(collateralManager), lm);\n\n        principalToken = new TestERC20Token("Principal Token", "PRIN", 12e18, 18);\n    }\n\n    function testSubmitBidForNonExistingMarket() public {\n        uint256 amount =\n```
MEDIUM severity: The `_validateCommitment` function in the collateral token implementation fails to properly validate. The `_validateCommitment` function in the collateral token implementation fails to properly validate the commitment when an approved operator is involved. Specifically, when a collateral token owner approves another user as an operator for all their tokens using the `setApprovalForAll` method, the v...

Vulnerable code:
```\nif (msg.sender!= holder):\n    require(msg.sender == operator, "invalid request")\n```
MEDIUM severity: The Silo module in the Beanstalk protocol is not designed to accommodate tokens that utilize fee-on-. The Silo module in the Beanstalk protocol is not designed to accommodate tokens that utilize fee-on-transfer (FoT) or rebasing mechanisms. This limitation arises from the fact that the Silo's accounting functions, such as `deposit`, `depositWithBDV`, `addDepositToAccount`, and `removeDepositFromAcco...

Vulnerable code:
```\nAdditional tokens may be added to the Deposit Whitelist via Beanstalk governance. In order for a token to be added to the Deposit Whitelist, Beanstalk requires:\n\n    1. The token address;\n    2. A function to calculate the Bean Denominated Value (BDV) of the token (see Section 14.2 of the whitepaper for complete formulas); and\n    3. The number of Stalk and Seeds per BDV received upon Deposit.\n```
MEDIUM severity: The Wormhole CCTP integration contract's `Governance::registerEmitterAndDomain` function allows for . The Wormhole CCTP integration contract's `Governance::registerEmitterAndDomain` function allows for the registration of an emitter address and its corresponding CCTP domain on a given foreign chain. However, the current implementation lacks a mechanism to update this registered state, making any mis...

Vulnerable code:
```\nfunction registerEmitterAndDomain(bytes memory encodedVaa) public {\n    /* parsing of Governance VAA payload */\n\n    registeredEmitters[foreignChain] = foreignAddress;\n\n    getChainToDomain()[foreignChain] = cctpDomain;\n    getDomainToChain()[cctpDomain] = foreignChain;\n}\n```
MEDIUM severity: The `MultiInvoker` liquidation action is vulnerable to incorrect calculation of the `closable` amoun. The `MultiInvoker` liquidation action is vulnerable to incorrect calculation of the `closable` amount when dealing with invalid oracle versions. This occurs due to a discrepancy in the logic used to update the `latestPosition` when an invalid oracle version is encountered.\n\nIn the `_latest` functi...

Vulnerable code:
```\nif (!version.valid):\n    context.latestPosition.local.invalidate(newPosition)\nnewPosition.adjust(context.latestPosition.local)\ncontext.latestPosition.local.update(newPosition)\n```\n```\nif (!oracleVersion.valid):\n    latestPosition.invalidate(pendingPosition)\nlatestPosition.update(pendingPosition)\n```\n```\npreviousMagnitude = latestPosition.magnitude();\nclosableAmount = previousMagnitude\n```\n```\nmarket.update(\n    account,\n    currentPosition.maker.isZero()? UFixed6Lib.ZERO : currentPosition.maker.sub(closable),\n    currentPosition.long.isZero()? UFixed6Lib.ZERO : currentPosition.long.sub(closable),\n    currentPosition.short.isZero()? UFixed6Lib.ZERO : currentPosition.short.sub(closable),\n    Fixed6Lib.from(-1, liquidationFee),\n    true\n);\n```\n```\nif (protected && (\n   !closableAmount.isZero() ||\n    context.latestPosition.local.maintained(\n        context.latestVersion,\n        context.riskParameter,\n        collateralAfterFees.sub(collateral)\n    ) ||\n    collateral.lt(Fixed6Lib.from(-1, _liquidationFee(context, newOrder)))\n)) {\n    revert MarketInvalidProtectionError();\n}\n```
MEDIUM severity: The vulnerability lies in the price calculation module's reliance on multiple price feeds, which can. The vulnerability lies in the price calculation module's reliance on multiple price feeds, which can be manipulated by an attacker to gain an advantage. The module iterates through available price feeds, gathers prices from non-revertible feeds, and applies a strategy to calculate the final asset pr...

Vulnerable code:
```\n(\n    (, int24 currentTick,,,,, bool unlocked) = params.pool.slot0();\n\n    if (unlocked == false) {\n        revert UniswapV3_PoolReentrancy(address(params.pool));\n    }\n```\n```\nVaultReentrancyLib.ensureNotInVaultContext(balVault)\n```\n```\n_validateReserves(\n    _getBunniKey(token),\n    lens,\n    params.twapMaxDeviationsBps,\n    params.twapObservationWindow\n)\n```\n```\nif (asset.useMovingAverage) {\n    prices[numFeeds] = asset.cumulativeObs / asset.numObservations;\n}\n```
MEDIUM severity: The vulnerability arises from the lack of stringent requirements when selecting unique settings keys. The vulnerability arises from the lack of stringent requirements when selecting unique settings keys in the DAO protocol's rewards claimer settings. Specifically, the `setSettingRewardsClaimer` function allows a malicious user to craft a proposal that sets a rewards claimer for a specific contract,...

Vulnerable code:
```\nfunction setSettingRewardsClaimer(string memory _contractName, uint256 _perc) override public onlyDAOProtocolProposal {\n    uint256 percTotal = getRewardsClaimersPercTotal();\n    uint256 percTotalUpdate = percTotal.add(_perc).sub(getRewardsClaimerPerc(_contractName));\n    require(percTotalUpdate <= 1 ether, "Claimers cannot total more than 100%");\n    setUint(keccak256(abi.encodePacked("rewards.claims", "group.totalPerc")), percTotalUpdate);\n    setUint(keccak256(abi.encodePacked("rewards.claims", "group.amount", _contractName)), _perc);\n    setUint(keccak256(abi.encodePacked("rewards.claims", "group.amount.updated.time", _contractName)), block.timestamp);\n}\n```
MEDIUM severity: The `LiquidityMiningNFT` contract's `mintNFTsForLM` method allows any user to mint NFTs without any . The `LiquidityMiningNFT` contract's `mintNFTsForLM` method allows any user to mint NFTs without any restrictions on the number of tokens that can be minted. This method is vulnerable to abuse, as it does not enforce any access controls or rate limiting, allowing an attacker to mint an unlimited numb...

Vulnerable code:
```\nfunction mintNFTsForLM(address _liquidiyMiningAddr) external {\n    uint256[] memory _ids = new uint256[](NFT_TYPES_COUNT);\n    uint256[] memory _amounts = new uint256[](NFT_TYPES_COUNT);\n\n    _ids[0] = 1;\n    _amounts[0] = 5;\n\n    _ids[1] = 2;\n    _amounts[1] = LEADERBOARD_SIZE;\n\n    _ids[2] = 3;\n    _amounts[2] = 3 * LEADERBOARD_SIZE;\n\n    _ids[3] = 4;\n    _amounts[3] = 6 * LEADERBOARD_SIZE;\n\n    _mintBatch(_liquidiyMiningAddr, _ids, _amounts, "");\n}\n```