Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The eMode implementation in the Aave protocol is severely flawed, as it fails to utilize the higher . The eMode implementation in the Aave protocol is severely flawed, as it fails to utilize the higher LTV (Loan-to-Value) ratio enabled by eMode. This is due to incorrect calls to the Aave V3 pool, which always returns the default settings instead of the adjusted eMode settings. As a result, the pool...

Vulnerable code:
```\nfunction _calculateMaxBorrowCollateral(\n    ActionInfo memory _actionInfo,\n    bool _isLever\n) internal view returns (uint256) {\n    (\n       ,\n        uint256 maxLtvRaw,\n        uint256 liquidationThresholdRaw,\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n       ,\n    ) = strategy.aaveProtocolDataProvider.getReserveConfigurationData(address(strategy.collateralAsset));\n\n    if (_isLever) {\n        uint256 netBorrowLimit = _actionInfo.collateralValue\n           .preciseMul(maxLtvRaw.mul(10 ** 14))\n           .preciseMul(PreciseUnitMath.preciseUnit().sub(execution.unutilizedLeveragePercentage));\n\n        return netBorrowLimit\n           .sub(_actionInfo.borrowValue)\n           .preciseDiv(_actionInfo.collateralPrice);\n    }\n```\n```\nfunction getReserveConfigurationData(\n  address asset\n)\n  external\n  view\n  override\n  returns (\n    (DataTypes.ReserveConfigurationMap memory configuration = IPool(ADDRESSES_PROVIDER.getPool())\n     .getConfiguration(asset),\n    (ltv, liquidationThreshold, liquidationBonus, decimals, reserveFactor) = configuration.getParams()\n  )\n{\n}\n```
MEDIUM severity: The vulnerability allows an attacker to re-enter the `takeOverDebt()` function during the liquidatio. The vulnerability allows an attacker to re-enter the `takeOverDebt()` function during the liquidation process, enabling them to steal vault funds. This is achieved by creating a custom token that allows the attacker to take control of the transaction and prevent liquidation. The attacker then funds...

Vulnerable code:
```\n_v3SwapExactInput(\n    v3SwapExactInputParams({\n        fee: params.fee,\n        tokenIn: cache.holdToken,\n        tokenOut: cache.saleToken,\n        amountIn: holdTokenAmountIn,\n        amountOutMinimum: (\n            saleTokenAmountOut * params.slippageBP1000\n        ) / Constants.BPS\n    }))\n```\n```\n_removeKeysAndClearStorage(borrowing.borrower, params.borrowingKey, loans);\n\n_pay(borrowing.holdToken, address(this), msg.sender, holdTokenBalance);\n_pay(borrowing.saleToken, address(this), msg.sender, saleTokenBalance);\n\nemit Repay(borrowing.borrower, msg.sender, params.borrowingKey);\n```\n```\nfunction removeKey(bytes32[] storage self, bytes32 key) internal {\n    uint256 length = self.length;\n    for (uint256 i = 0; i < length; ) {\n        if (self[i].value == key) {\n            self[length - 1].value = self[i].value;\n            self.pop();\n            break;\n        }\n        i++;\n    }\n}\n```\n```\nnewBorrowing.accLoanRatePerSeconds = oldBorrowing.accLoanRatePerSeconds;\n    _pay(oldBorrowing.holdToken, msg.sender, VAULT_ADDRESS, collateralAmt + feesDebt);\n    emit TakeOverDebt(oldBorrowing.borrower, msg.sender, borrowingKey, newBorrowingKey);\n```\n```\nVault(VAULT_ADDRESS).transferToken(\n    borrowing.holdToken,\n    address(this),\n    borrowing.borrowedAmount + liquidationBonus\n);\n```
MEDIUM severity: The `SocketGateway` contract's `executeRoutes` function is designed to process multiple arrays of da. The `SocketGateway` contract's `executeRoutes` function is designed to process multiple arrays of data in a batched manner, allowing users to execute routes and batch calls between them in a single transaction. This functionality is achieved by iterating over the arrays using a shared index. However...

Vulnerable code:
```\nfunction executeRoutes(\n    uint32[] calldata routeIds,\n    bytes[] calldata dataItems,\n    bytes[] calldata eventDataItems\n) external payable {\n    uint256 routeIdslength = routeIds.length;\n    for (uint256 index = 0; index < routeIdslength; index++) {\n        (bool success, bytes memory result) = addressAt(routeIds[index])\n           .delegatecall(dataItems[index]);\n\n        if (!success) {\n            assembly {\n                revert(add(result, 32), mload(result))\n            }\n        }\n\n        emit SocketRouteExecuted(routeIds[index], eventDataItems[index]);\n    }\n}\n```
MEDIUM severity: The `onERC721Received()` callback is not properly invoked when new tokens are minted in the `Erc721F. The `onERC721Received()` callback is not properly invoked when new tokens are minted in the `Erc721Facet` contract, violating the ERC721 standard. Specifically, when a user interacts with the `mintNFT()` function, the callback is not triggered, as expected. This oversight may lead to unintended cons...

Vulnerable code:
```\nfunction mintNFT(address asset, uint8 shortRecordId)\n    external\n    isNotFrozen(asset)\n    nonReentrant\n    onlyValidShortRecord(asset, msg.sender, shortRecordId)\n{\n    if (shortRecordId == Constants.SHORT_MAX_ID) {\n        revert Errors.CannotMintLastShortRecord();\n    }\n    STypes.ShortRecord storage short = \n        s.shortRecords[asset][msg.sender][shortRecordId];\n\n    if (short.tokenId!= 0) \n        revert Errors.AlreadyMinted();\n\n    s.nftMapping[s.tokenIdCounter] = \n        STypes.NFT({\n            owner: msg.sender,\n            assetId: s.asset[asset].assetId,\n            shortRecordId: shortRecordId\n        });\n\n    short.tokenId = s.tokenIdCounter;\n\n    s.tokenIdCounter += 1;\n}\n```
MEDIUM severity: The Geode Finance codebase allows planet maintainers to enable or disable multiple contracts, which . The Geode Finance codebase allows planet maintainers to enable or disable multiple contracts, which can lead to unpredictable and potentially catastrophic consequences. The contracts share balances but not allowances, making it difficult to predict the outcomes of interactions between them.\n\nWhen...

Vulnerable code:
```\nmapping(uint256 => mapping(address => uint256)) private _balances;\n```\n```\nmapping(address => mapping(address => uint256)) private _allowances;\n```
MEDIUM severity: The `managerFeeBPS` variable, which determines the percentage of fees allocated to the manager, can . The `managerFeeBPS` variable, which determines the percentage of fees allocated to the manager, can be manipulated by the manager at any time. This is achieved through the `setManagerFeeBPS()` function, which can be called by the manager to update the `managerFeeBPS` value. \n\nOnce updated, the new...

Vulnerable code:
```\nfunction _applyFees(uint256 fee0_, uint256 fee1_) internal {\n    uint16 mManagerFeeBPS = managerFeeBPS;\n    managerBalance0 += (fee0_ * mManagerFeeBPS) / hundredPercent;\n    managerBalance1 += (fee1_ * mManagerFeeBPS) / hundredPercent;\n}\n```\n```\nfunction setManagerFeeBPS(uint16 managerFeeBPS_) external onlyManager {\n    require(managerFeeBPS_ <= 10000, "MFO");\n    managerFeeBPS = managerFeeBPS_;\n    emit LogSetManagerFeeBPS(managerFeeBPS_);\n}\n```
MEDIUM severity: The `Deployments.sol` contract contains a critical error in its implementation, which causes all Uni. The `Deployments.sol` contract contains a critical error in its implementation, which causes all Uniswap V2 calls to fail. Specifically, the constant `UNIV2_ROUTER` is incorrectly set to the address of the Uniswap V3 router (`0xE592427A0AEce92De3Edee1F18E0157C05861564`). This mistake is significant...

Vulnerable code:
```\nIUniV2Router2 internal constant UNIV2_ROUTER = \nIUniV2Router2(0xE592427A0AEce92De3Edee1F18E0157C05861564);\n```
MEDIUM severity: This vulnerability is a discrepancy between the code and comments in a specific section of the codeb. This vulnerability is a discrepancy between the code and comments in a specific section of the codebase. The code snippet in question is a conditional statement that checks if the `weightSum` variable falls within a specific range, specifically between 1e18 and 4e18. The comment above this code bloc...

Vulnerable code:
```\nrequire(weightSum >= 1e18 && weightSum <= 4e18)\n  "Basket weight must be >= 100 && <= 400"\n```\n```\n@dev\n    Throws if the total Basket weight does not sum to 100\n```
MEDIUM severity: The `getLpTokenAmount` function in the `GMXOracle` oracle is responsible for calculating the LP toke. The `getLpTokenAmount` function in the `GMXOracle` oracle is responsible for calculating the LP token amount required for a given value. This function is used in the keeper script to determine the LP token amount for a specified USD value. The function takes several parameters, including the given v...

Vulnerable code:
```\n/**\n * @notice Get token A and token B's LP token amount required for a given value\n * @param givenValue Given value needed, expressed in 1e30\n * @param marketToken LP token address\n * @param indexToken Index token address\n * @param longToken Long token address\n * @param shortToken Short token address\n * @param isDeposit Boolean for deposit or withdrawal\n * @param maximize Boolean for minimum or maximum price\n * @return lpTokenAmount Amount of LP tokens; expressed in 1e18\n*/\n\nfunction getLpTokenAmount(\n    uint256 givenValue,\n    address marketToken,\n    address indexToken,\n    address longToken,\n    address shortToken,\n    bool isDeposit,\n    bool maximize\n) public view returns (uint256) {\n    uint256 _lpTokenValue = getLpTokenValue(\n        marketToken,\n        indexToken,\n        longToken,\n        shortToken,\n        isDeposit,\n        maximize\n    );\n\n    return givenValue * SAFE_MULTIPLIER / _lpTokenValue;\n}\n```
MEDIUM severity: This vulnerability allows a malicious operator to manipulate the Linea chain by adding and finalizin. This vulnerability allows a malicious operator to manipulate the Linea chain by adding and finalizing block data from a forked chain, effectively allowing the attacker to steal funds from the main chain (L1). The malicious operator can achieve this by creating a forked chain, sending the forked chai...

Vulnerable code:
```\nuint256 publicInput = uint256(\n    keccak256(\n        abi.encode(\n            snarf,\n            _finalizationData.parentStateRootHash,\n            _finalizationData.lastFinalizedTimestamp,\n            _finalizationData.finalBlockNumber,\n            _finalizationData.finalTimestamp,\n            _finalizationData.l1RollingHash,\n            _finalizationData.l1RollingHashMessageNumber,\n            keccak256(abi.encodePacked(_finalizationData.l2MerkleRoots))\n        )\n    )\n);\n```\n```\naddL2MerkleRoots(_finalizationData.l2MerkleRoots, _finalizationData.l2MerkleTreesDepth);\n```
MEDIUM severity: The `Vault` can experience prolonged downtime periods due to the potential for the Chainlink price t. The `Vault` can experience prolonged downtime periods due to the potential for the Chainlink price to remain outside the defined boundaries for up to 24 hours. This occurs when the balancer pool spot price is not within the specified `THRESHOLD` range relative to the last fetched Chainlink price. Th...

Vulnerable code:
```\nreturn (\n    amount_ * \n    stethPerWsteth * \n    stethUsd * \n    decimalAdjustment\n) / (\n    ohmEth * \n    ethUsd * \n    1e18\n)\n```
MEDIUM severity: The vulnerability audit reveals a potential issue with overflow/underflow protection in the smart co. The vulnerability audit reveals a potential issue with overflow/underflow protection in the smart contract's arithmetic operations. This is a common problem in smart contracts, which can be mitigated by utilizing `SafeMath` or upgrading to Solidity version 0.8 or higher, where arithmetic operations...

Vulnerable code:
```\nuint totalGenesisTribe = tribeBalance() - totalCommittedTribe;\n```
MEDIUM severity: The vulnerability arises when the `transferAmount` exceeds the combined total of all `lien.amount`s.. The vulnerability arises when the `transferAmount` exceeds the combined total of all `lien.amount`s. This can lead to incorrect fees being charged, as the `initiatorPayment` is calculated based on the full `transferAmount`, rather than the actual amount used to settle the liens.\n\nIn the `_handleIn...

Vulnerable code:
```\nuint256 initiatorPayment = transferAmount.mulDivDown(\n    auction.initiatorFee,\n    100\n);\n```\n```\nif (transferAmount >= lien.amount) {\n    payment = lien.amount;\n    transferAmount -= payment;\n} else {\n    payment = transferAmount;\n    transferAmount = 0;\n}\n\nif (payment > 0) {\n    LIEN_TOKEN.makePayment(tokenId, payment, lien.position, payer);\n}\n```
MEDIUM severity: The vulnerability allows an attacker to deliberately manipulate the deposit process by exploiting th. The vulnerability allows an attacker to deliberately manipulate the deposit process by exploiting the strict verification mechanism implemented in the Vault's deposit function. Specifically, the function checks that the proportion of tokens inserted to the vault matches the current vault token balan...

Vulnerable code:
```\nuint256[] memory balances = vlt.balances();\nrequire(functions.ratiosMatch(balances, amts), "ratios don't match");\n```\n```\nfor (uint256 i = 0; i < sourceRatios.length; i++) {\n    if (targetRatios[i]!= Arithmetic.overflowResistantFraction(targetRatios[greatestIndex], sourceRatios[i], greatest)) {\n        return false;\n    }\n}\n```
MEDIUM severity: The `DepositVault` contract contains three functions: `deposit`, `withdraw`, and `withdrawDeposit`, . The `DepositVault` contract contains three functions: `deposit`, `withdraw`, and `withdrawDeposit`, which are currently declared as `public`. This allows any external contract or entity to access and manipulate these functions, potentially leading to unintended consequences.\n\nIn a well-designed co...

Vulnerable code:
```\nfunction deposit(uint256 amount, address tokenAddress) public payable {\n    //...\n}\n\nfunction withdraw(uint256 amount, uint256 nonce, bytes memory signature, address payable recipient) public {\n    //...\n}\n\nfunction withdrawDeposit(uint256 depositIndex) public {\n    //...\n}\n```
MEDIUM severity: The `XChainController::sendFundsToVault` function can be exploited by repeatedly calling the functio. The `XChainController::sendFundsToVault` function can be exploited by repeatedly calling the function with the same vault number, allowing an attacker to manipulate the state of the `XChainController` and potentially leave it in a bad state. This vulnerability occurs during the rebalancing process,...

Vulnerable code:
```\nit('5) Grief xChainController send funds to vaults', async function () {\n  await xChainController.sendFundsToVault(vaultNumber, slippage, 10000, 0, { value: 0 });\n  await xChainController.sendFundsToVault(vaultNumber, slippage, 10000, 0, { value: 0 });\n  await xChainController.sendFundsToVault(vaultNumber, slippage, 10000, 0, { value: 0 });\n  await xChainController.sendFundsToVault(vaultNumber, slippage, 10000, 0, { value: 0 });\n\n  expect(await xChainController.getFundsReceivedState(vaultNumber)).to.be.equal(0);\n\n  expect(await vault3.state()).to.be.equal(3);\n\n  await expect(xChainController.sendFundsToVault(vaultNumber, slippage, 1000, relayerFee, { value: parseEther('0.1') })).to.be.revertedWith('Not all funds received');\n});\n```
MEDIUM severity: The `FundraisingMultisigTemplate` vulnerability is characterized by a discrepancy between the commen. The `FundraisingMultisigTemplate` vulnerability is characterized by a discrepancy between the comment and the actual code implementation. Specifically, the comment suggests that the `ADD_PROTECTED_TOKEN_ROLE` permission is being created and granted, whereas the code actually creates and grants permi...

Vulnerable code:
```\nacl.createPermission(this, controller, controller.ADD_COLLATERAL_TOKEN_ROLE(), this);\n```\n```\n_transferPermissionFromTemplate(acl, controller, shareVoting, controller.ADD_COLLATERAL_TOKEN_ROLE(), shareVoting)\n```
MEDIUM severity: The `lockBounty` function in the provided code snippet is currently locking bounties for a fixed per. The `lockBounty` function in the provided code snippet is currently locking bounties for a fixed period of three months after the delegation start date. However, this approach may not be suitable for all scenarios, as it may not account for the token launch date.\n\nA more comprehensive approach wou...

Vulnerable code:
```\nskaleBalances.lockBounty(\n    shares[i].holder,\n    timeHelpers.addMonths(delegationStarted, 3)\n)\n```
MEDIUM severity: The presence of testnet code in the `initialize` function of the pSTAKE token contract poses a poten. The presence of testnet code in the `initialize` function of the pSTAKE token contract poses a potential risk. The function, which is intended to be used for testnet purposes only, currently mints a large quantity of tokens to the `msg.sender` address. However, the goal for the mainnet deployment is...

Vulnerable code:
```\nfunction initialize(address pauserAddress) public virtual initializer {\n    _ERC20_init("pSTAKE Token", "PSTAKE");\n    _AccessControl_init();\n    _Pausable_init();\n    _setupRole(DEFAULT_ADMIN_ROLE, _msgSender());\n    _setupRole(PAUSER_ROLE, pauserAddress);\n    _setupDecimals(18);\n    _mint(_msgSender(), 5000000000000000000000000);\n}\n```
MEDIUM severity: The vulnerability arises when a requested oracle version, which has expired, is committed by the kee. The vulnerability arises when a requested oracle version, which has expired, is committed by the keepers. In this scenario, the `commit` function sets the price of the previous valid version for the expired oracle version, instead of marking it as invalid. This is because the `commit` function only...

Vulnerable code:
```\nfunction _commitRequested(OracleVersion memory version) private returns (bool) {\n    if (block.timestamp <= (next() + timeout)) {\n        if (!version.valid) {\n            revert KeeperOracleInvalidPriceError();\n        }\n        _prices[version.timestamp] = version.price;\n    } else {\n        _prices[version.timestamp] = _prices[_global.latestVersion];\n    }\n    _global.latestIndex++;\n    return true;\n}\n```\n```\nfunction _processOrderGlobal(\n    Context memory context,\n    SettlementContext memory settlementContext,\n    uint256 newOrderId,\n    Order memory newOrder\n) private {\n    OracleVersion memory oracleVersion = oracle.at(newOrder.timestamp);\n\n    context.pending.global.sub(newOrder);\n    if (!oracleVersion.valid) {\n        newOrder.invalidate();\n    }\n```\n```\nfunction at(uint256 timestamp) public view returns (OracleVersion memory oracleVersion) {\n    (oracleVersion.timestamp, oracleVersion.price) = (timestamp, _prices[timestamp]);\n    oracleVersion.valid =!oracleVersion.price.isZero();\n}\n```
MEDIUM severity: The `OrchidDirectory` contract contains a vulnerability in its `step()` and `lift()` functions, whic. The `OrchidDirectory` contract contains a vulnerability in its `step()` and `lift()` functions, which accept a `uint128` parameter called `amount`. This `amount` is added to various struct fields, which are also of type `uint128`. The contract intentionally underflows this `amount` to represent nega...

Vulnerable code:
```\nlift(key, stake, -amount, stakee, staker);\n```\n```\nstep(key, stake, current.amount, current.parent);\n```
MEDIUM severity: This vulnerability involves two instances of the `transferFrom` function being called without proper. This vulnerability involves two instances of the `transferFrom` function being called without proper error handling. The `transferFrom` function is used to transfer tokens from a specific address to another, and it is crucial to verify the return value to ensure the transaction was successful.\n\nIn...

Vulnerable code:
```\nstakedToken.transferFrom(\n    from,\n    address(this),\n    amount\n)\n```\n```\nfei().transferFrom(\n    msg.sender,\n    address(pair),\n    amountFei\n)\n```
MEDIUM severity: The `lockCapital()` function in the ProtectionPool contract is responsible for locking funds for pro. The `lockCapital()` function in the ProtectionPool contract is responsible for locking funds for protections bought for a lending pool when a lending loan defaults. However, the function does not filter out expired protections before calculating the required locked amount. This can lead to a situati...

Vulnerable code:
```\nfunction lockCapital(address _lendingPoolAddress)\n    external\n    payable\n    override\n    onlyDefaultStateManager\n    whenNotPaused\n    returns (uint256 _lockedAmount, uint256 _snapshotId)\n{\n    _snapshotId = _snapshot();\n\n    uint256 _length = lendingPoolDetails[_lendingPoolAddress].activeProtectionIndexes.length();\n    uint256 _lockedAmount = 0;\n\n    for (uint256 i = 0; i < _length; i++) {\n        uint256 _protectionIndex = lendingPoolDetails[_lendingPoolAddress].activeProtectionIndexes.at(i);\n        ProtectionInfo storage protectionInfo = protectionInfos[_protectionIndex];\n\n        uint256 _remainingPrincipal = poolInfo.referenceLendingPools.calculateRemainingPrincipal(\n            _lendingPoolAddress,\n            protectionInfo.buyer,\n            protectionInfo.purchaseParams.nftLpTokenId\n        );\n\n        uint256 _protectionAmount = protectionInfo.purchaseParams.protectionAmount;\n        uint256 _lockedAmountPerProtection = _protectionAmount < _remainingPrincipal\n           ? _protectionAmount\n            : _remainingPrincipal;\n\n        _lockedAmount += _lockedAmountPerProtection;\n    }\n\n    if (totalSTokenUnderlying < _lockedAmount) {\n        _lockedAmount = totalSTokenUnderlying;\n        totalSTokenUnderlying = 0;\n    } else {\n        totalSTokenUnderlying -= _lockedAmount;\n    }\n\n    return (_lockedAmount, _snapshotId);\n}\n```
MEDIUM severity: The TokenBridge contract, as implemented in the pull request 71 with the final commit hash `8ebfd011. The TokenBridge contract, as implemented in the pull request 71 with the final commit hash `8ebfd011675ea318b7067af52637192aa1126acd`, defines a privileged role called Owner. However, the current implementation employs a single-step approach for ownership transfers, which can lead to unintended cons...

Vulnerable code:
```\ncontract TokenBridge is ITokenBridge, PausableUpgradeable, OwnableUpgradeable {\n    //...\n```
MEDIUM severity: The vulnerability allows an attacker to steal gas by manipulating the feeMultiplier variable, which . The vulnerability allows an attacker to steal gas by manipulating the feeMultiplier variable, which is used to calculate the total fee to be charged on a transaction. The feeMultiplier is set to 100% by default, but can be adjusted by the admin to either subsidize or upcharge for the automation serv...

Vulnerable code:
```\n/**\n * @notice feeMultiplier represents the total fee to be charged on the transaction\n * @dev In case feeMultiplier is less than BASE_BPS, fees charged will be less than 100%, subsidizing the transaction\n * In case feeMultiplier is greater than BASE_BPS, fees charged will be greater than 100%, charging the user for the transaction\n */\nuint16 public feeMultiplier = 10_000;\n\nif (feeToken == ETH) {\n    uint256 totalFee = (gasUsed + GAS_OVERHEAD_NATIVE) * tx.gasprice;\n    totalFee = _applyMultiplier(totalFee);\n    return (totalFee, recipient, TokenTransfer._nativeTransferExec(recipient, totalFee));\n} else {\n```
MEDIUM severity: The `GenesisGroup.emergencyExit` function is intended as a safety mechanism to allow users to exit t. The `GenesisGroup.emergencyExit` function is intended as a safety mechanism to allow users to exit the system in the event of a failure or freeze during the `launch` process. However, a critical issue arises when both `launch` and `emergencyExit` remain callable after a successful call to either met...

Vulnerable code:
```\nburnFrom(from, amountFGEN);\ncommittedFGEN[from] = 0;\n\npayable(to).transfer(total)\n```\n```\nuint amountFei = feiBalance() * totalCommittedFGEN / (totalSupply() + totalCommittedFGEN);\n\nif (amountFei!= 0) {\n    totalCommittedTribe = ido.swapFei(amountFei);\n}\n```