Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `FiatTokenV1` contract, a descendant of `BlacklistableV1` and `RescuableV1`, inherits the `_disa. The `FiatTokenV1` contract, a descendant of `BlacklistableV1` and `RescuableV1`, inherits the `_disableInitializers` mechanism from its parent contracts. This mechanism is intended to prevent malicious actors from initializing the contracts before they are fully deployed, thereby preventing potentia...

Vulnerable code:
```\nconstructor() {\n    _disableInitializers();\n}\n```
MEDIUM severity: The vulnerability lies in the implementation of the FootiumPlayer and FootiumClub contracts, which a. The vulnerability lies in the implementation of the FootiumPlayer and FootiumClub contracts, which allows users to bypass the royalty fees associated with EIP2981-compliant marketplaces. Specifically, the FootiumPlayer contract implements the EIP2981 standard, which enables fees to be charged when b...

Vulnerable code:
```\ncontract FootiumPlayer is\n    ERC721Upgradeable,\n    AccessControlUpgradeable,\n    ERC2981Upgradeable,\n    PausableUpgradeable,\n    ReentrancyGuardUpgradeable,\n    OwnableUpgradeable {\n```\n```\ncontract FootiumClub is\n    ERC721Upgradeable,\n    AccessControlUpgradeable,\n    PausableUpgradeable,\n    ReentrancyGuardUpgradeable,\n    OwnableUpgradeable {\n```
MEDIUM severity: The `DnGmxJuniorVaultManager#harvestFees` function allows the senior vault to indirectly gain value . The `DnGmxJuniorVaultManager#harvestFees` function allows the senior vault to indirectly gain value by increasing the debt of the junior vault. This is achieved by converting the WETH owed to the senior vault into USDC and staking it directly into the Aave protocol. The junior vault's total borrow a...

Vulnerable code:
```\nif (_seniorVaultWethRewards > state.wethConversionThreshold) {\n    uint256 minUsdcAmount = _getTokenPriceInUsdc(state, state.weth).mulDivDown(\n        _seniorVaultWethRewards * (MAX_BPS - state.slippageThresholdSwapEthBps),\n        MAX_BPS * PRICE_PRECISION\n    );\n\n    (uint256 aaveUsdcAmount, ) = state._swapToken(\n        address(state.weth),\n        _seniorVaultWethRewards,\n        minUsdcAmount\n    );\n\n    state._executeSupply(address(state.usdc), aaveUsdcAmount);\n\n    state.seniorVaultWethRewards = 0;\n}\n```\n```\nfunction getUsdcBorrowed() public view returns (uint256 usdcAmount) {\n    return uint256(\n        state.aUsdc.balanceOf(address(this)).toInt256() -\n        state.dnUsdcDeposited -\n        state.unhedgedGlpInUsdc.toInt256()\n    );\n}\n```\n```\nfunction availableBorrow(address borrower) public view returns (uint256 availableAUsdc) {\n    uint256 availableBasisCap = borrowCaps[borrower] - IBorrower(borrower).getUsdcBorrowed();\n    uint256 availableBasisBalance = aUsdc.balanceOf(address(this));\n\n    availableAUsdc = availableBasisCap < availableBasisBalance\n       ? availableBasisCap\n        : availableBasisBalance;\n}\n```
MEDIUM severity: The `MainVault.rebalanceXChain` function does not verify that the total underlying amount saved (`sa. The `MainVault.rebalanceXChain` function does not verify that the total underlying amount saved (`savedTotalUnderlying`) is greater than or equal to the reserved funds (`reservedFunds`) before sending funds to the xController. This oversight can lead to a shortage of underlying assets in the vault,...

Vulnerable code:
```\nfunction rebalanceXChain(uint256 _slippage, uint256 _relayerFee) external payable {\n    require(state == State.SendingFundsXChain, stateError);\n\n    if (amountToSendXChain > getVaultBalance()) {\n        pullFunds(amountToSendXChain);\n        if (amountToSendXChain > getVaultBalance()) {\n            amountToSendXChain = getVaultBalance();\n        }\n    }\n\n    vaultCurrency.safeIncreaseAllowance(xProvider, amountToSendXChain);\n    IXProvider(xProvider).xTransferToController{value: msg.value}(\n        vaultNumber,\n        amountToSendXChain,\n        address(vaultCurrency),\n        _slippage,\n        _relayerFee\n    );\n\n    emit RebalanceXChain(vaultNumber, amountToSendXChain, address(vaultCurrency));\n\n    amountToSendXChain = 0;\n    settleReservedFunds();\n}\n```\n```\nif (amountToSendXChain > getVaultBalance()):\n    pullFunds(amountToSendXChain)\nif amountToSendXChain > getVaultBalance():\n    amountToSendXChain = getVaultBalance()\n```
MEDIUM severity: The vulnerability lies in the PerpDepository.sol contract's deposit function, which allows users to . The vulnerability lies in the PerpDepository.sol contract's deposit function, which allows users to mint UXD tokens based on the amount of vUSD gained from selling deposited ETH. This approach is problematic because Perp Protocol operates as a derivative market, not a spot market, which means that p...

Vulnerable code:
```\nfunction deposit(\n    address asset,\n    uint256 amount\n) external onlyController returns (uint256) {\n    if (asset == assetToken) {\n        _depositAsset(amount);\n        (, uint256 quoteAmount) = _openShort(amount);\n        return quoteAmount;\n    } else if (asset == quoteToken) {\n        return _processQuoteMint(amount);\n    } else {\n        revert UnsupportedAsset(asset);\n    }\n}\n```
MEDIUM severity: The vulnerability in the smart contract's initialization process allows a malicious actor to manipul. The vulnerability in the smart contract's initialization process allows a malicious actor to manipulate the share price, potentially leading to a denial-of-service (DOS) attack on subsequent buyShares operations. This is achieved by exploiting the calculation of shares during the first deposit, whic...

Vulnerable code:
```\nfunction buyShares(address to) {\n    // rest of code\n    // case 1. initial supply\n    // The shares will be minted to user\n    shares = quoteBalance < DecimalMath.mulFloor(baseBalance, _I_) \n       ? DecimalMath.divFloor(quoteBalance, _I_)\n        : baseBalance; // <= FOUND\n    // The target will be updated\n    _BASE_TARGET_ = uint112(shares);\n    // rest of code\n}\n```\n```\n// File: dodo-gassaving-pool/contracts/GasSavingPool/impl/GSPFunding.sol\n\nfunction buyShares(address to) {\n    // rest of code\n\n    uint256 baseInputRatio = DecimalMath.divFloor(baseInput, baseReserve);\n    uint256 quoteInputRatio = DecimalMath.divFloor(quoteInput, quoteReserve);\n    uint256 mintRatio = quoteInputRatio < baseInputRatio? quoteInputRatio : baseInputRatio; // <= FOUND: mintRatio below 1001wad if input amount smaller than reserves * 1001\n    // The shares will be minted to user\n    shares = DecimalMath.mulFloor(totalSupply, mintRatio); // <= FOUND: the manipulated totalSupply of 1wei requires a mintRatio of greater than 1000 for a successful _mint()\n    // rest of code\n}\n\n// File: dodo-gassaving-pool/contracts/GasSavingPool/impl/GSPVault.sol\n\nfunction _mint(address user, uint256 value) internal {\n    require(value > 1000, "MINT_AMOUNT_NOT_ENOUGH"); // <= FOUND: next buyShares with volume less than 1001 x attacker balance will revert here\n    // rest of code\n}\n```\n```\nfunction test_mint1weiShares_DOSx1000DonationVolume() public {\n    GSP gspTest = new GSP();\n    gspTest.init(\n        MAINTAINER,\n        address(mockBaseToken),\n        address(mockQuoteToken),\n        0,\n        0,\n        1000000,\n        500000000000000,\n        false\n    );\n\n    vm.startPrank(USER);\n    mockBaseToken.transfer(address(gspTest), 1001);\n    mockQuoteToken.transfer(address(gspTest), 1001 * gspTest._I_() / 1e18);\n    gspTest.buyShares(USER);\n    assertEq(gspTest.balanceOf(USER), 1001);\n\n    gspTest.sellShares(1000, USER, 0, 0, "", block.timestamp);\n    assertEq(gspTest.balanceOf(USER), 1);\n\n    uint256 donationAmount = 1000e18;\n    mockBaseToken.transfer(address(gspTest), donationAmount);\n    mockQuoteToken.transfer(address(gspTest), donationAmount * gspTest._I_() / 1e18);\n    gspTest.sync();\n    vm.stopPrank();\n\n    uint256 dosAmount = donationAmount * 1001;\n    mockBaseToken.mint(OTHER, type(uint256).max);\n    mockQuoteToken.mint(OTHER, type(uint256).max);\n\n    vm.startPrank(OTHER);\n    mockBaseToken.transfer(address(gspTest), dosAmount);\n    mockQuoteToken.transfer(address(gspTest), dosAmount * gspTest._I_() / 1e18);\n\n    vm.expectRevert("MINT_AMOUNT_NOT_ENOUGH");\n    gspTest.buyShares(OTHER);\n    vm.stopPrank();\n}\n```
MEDIUM severity: The OperationalStaking mechanism in the contract is vulnerable to a rounding error that can result i. The OperationalStaking mechanism in the contract is vulnerable to a rounding error that can result in users withdrawing more than their intended amount of CQT. This occurs when the `_sharesToTokens` and `_tokensToShares` functions round down instead of rounding off against the user. This can lead to...

Vulnerable code:
```\nfunction _tokensToShares(\n    uint128 amount,\n    uint128 rate\n) internal view returns (uint128) {\n    return uint128((uint256(amount) * DIVIDER) / uint256(rate));\n}\n```\n```\nfunction _sharesToTokens(\n    uint128 sharesN,\n    uint128 rate\n) internal view returns (uint128) {\n    return uint128((uint256(sharesN) * uint256(rate)) / DIVIDER);\n}\n```\n```\nrequire(\n    effectiveAmount >= REWARD_REDEEM_THRESHOLD,\n    "Requested amount must be higher than redeem threshold"\n);\n```
MEDIUM severity: The `updateTransferWhitelist` function is designed to manage the whitelist of addresses that are all. The `updateTransferWhitelist` function is designed to manage the whitelist of addresses that are allowed to transfer tokens. However, the implementation contains a critical flaw that prevents the XMozToken from being added to its own whitelist. This is because the function checks if the account atte...

Vulnerable code:
```\nfunction updateTransferWhitelist(address account, bool add) external onlyMultiSigAdmin {\n    require(account!= address(this), "updateTransferWhitelist: Cannot remove xMoz from whitelist");\n    if (add) {\n        _transferWhitelist.add(account);\n    } else {\n        _transferWhitelist.remove(account);\n    }\n    emit SetTransferWhitelist(account, add);\n}\n```
MEDIUM severity: The `receiveFees` function in the Pool contract is designed to compensate for potential penalties or. The `receiveFees` function in the Pool contract is designed to compensate for potential penalties or slashing in the protocol by sending LYX back to the pool without minting sLYX. However, this function lacks proper access control, allowing anyone to send LYX to the pool, which can potentially disru...

Vulnerable code:
```\nfunction receiveFees() external payable {\n    override\n}\n```\n```\nfunction receiveWithoutActivation() external payable override {\n    require(msg.sender == address(stakedLyxToken) || hasRole(DEFAULT_ADMIN_ROLE, msg.sender), "Pool: access denied");\n}\n```
MEDIUM severity: The `lockQuote()` function in the provided code contains a vulnerability in its handling of the `inc. The `lockQuote()` function in the provided code contains a vulnerability in its handling of the `increaseNonce` parameter. When `increaseNonce` is set to `true`, the function attempts to increment the `partyBNonces` mapping using the `quote.partyB` value. However, this operation is executed before t...

Vulnerable code:
```\nfunction lockQuote(uint256 quoteId, SingleUpnlSig memory upnlSig, bool increaseNonce) internal {\n    QuoteStorage.Layout storage quoteLayout = QuoteStorage.layout();\n    AccountStorage.Layout storage accountLayout = AccountStorage.layout();\n\n    Quote storage quote = quoteLayout.quotes[quoteId];\n    LibMuon.verifyPartyBUpnl(upnlSig, msg.sender, quote.partyA);\n    checkPartyBValidationToLockQuote(quoteId, upnlSig.upnl);\n    if (increaseNonce) {\n        accountLayout.partyBNonces[quote.partyB][quote.partyA] += 1;\n    }\n    quote.modifyTimestamp = block.timestamp;\n    quote.quoteStatus = QuoteStatus.LOCKED;\n    quote.partyB = msg.sender;\n    // lock funds for partyB\n    accountLayout.partyBPendingLockedBalances[msg.sender][quote.partyA].addQuote(quote);\n    quoteLayout.partyBPendingQuotes[msg.sender][quote.partyA].push(quote.id);\n```
MEDIUM severity: The `emergency_shutdown` role is not sufficient for emergency shutdown due to a role restriction in . The `emergency_shutdown` role is not sufficient for emergency shutdown due to a role restriction in the `defund` function. The `defund` function, which is called within the `emergencyShutdown` function, is protected by the `onlyRole("cooler_overseer")` modifier. This means that only users with the `...

Vulnerable code:
```\nfunction emergencyShutdown() external onlyRole("emergency_shutdown") {\n    active = false;\n\n    uint256 sdaiBalance = sdai.balanceOf(address(this));\n    if (sdaiBalance!= 0) {\n        defund(sdai, sdaiBalance);\n    }\n\n    uint256 daiBalance = dai.balanceOf(address(this));\n    if (daiBalance!= 0) {\n        defund(dai, daiBalance);\n    }\n\n    emit Deactivated();\n}\n```\n```\nfunction defund(ERC20 token_, uint256 amount_) public onlyRole("cooler_overseer") {\n    // Code here\n}\n```\n```\nrolesAdmin.grantRole("cooler_overseer", overseer);\nrolesAdmin.grantRole("emergency_shutdown", overseer);\n```\n```\nforge test --match-test test_emergencyShutdown\n```
MEDIUM severity: The `resolveQueuedTrades()` function in the smart contract calls the `_openQueuedTrade()` function, . The `resolveQueuedTrades()` function in the smart contract calls the `_openQueuedTrade()` function, which does not adhere to the "Checks-Effects-Interactions" principle. This can lead to a re-entry vulnerability, allowing an attacker to steal funds.\n\nThe `_openQueuedTrade()` function is responsibl...

Vulnerable code:
```\nfunction _openQueuedTrade(uint256 queueId, uint256 price) internal {\n    if (revisedFee < queuedTrade.totalFee) {\n        tokenX.transfer(\n            queuedTrade.user,\n            queuedTrade.totalFee - revisedFee\n        );\n    }\n\n    queuedTrade.isQueued = false;\n}\n```
MEDIUM severity: The `matchOrders()` function is vulnerable to front-running attacks, which can lead to gas auctions . The `matchOrders()` function is vulnerable to front-running attacks, which can lead to gas auctions and render the function unusable. This vulnerability arises from the fact that the caller only pays protocol and transaction fees, making it profitable for an attacker to execute the same `matchOrders...

Vulnerable code:
```\nfunction matchOrders(\n    LibOrder.Order memory leftOrder,\n    LibOrder.Order memory rightOrder,\n    bytes memory leftSignature,\n    bytes memory rightSignature\n)\n```
MEDIUM severity: The `QVSimpleStrategy` contract contains a vulnerability in its `_allocate` function, which fails to. The `QVSimpleStrategy` contract contains a vulnerability in its `_allocate` function, which fails to update the `allocator.voiceCredits` variable. This variable is used to track the total voice credits allocated to a recipient. The `_allocate` function checks if the recipient has sufficient voice cr...

Vulnerable code:
```\nfunction _allocate(bytes memory _data, address _sender) internal virtual override {\n   ...\n\n    if (!_hasVoiceCreditsLeft(voiceCreditsToAllocate, allocator.voiceCredits)) {\n        revert INVALID();\n    }\n\n    _qv_allocate(allocator, recipient, recipientId, voiceCreditsToAllocate, _sender);\n}\n```\n```\nfunction _hasVoiceCreditsLeft(uint256 _voiceCreditsToAllocate, uint256 _allocatedVoiceCredits)\n    internal\n    view\n    override\n    returns (bool)\n{\n    return _voiceCreditsToAllocate + _allocatedVoiceCredits <= maxVoiceCreditsPerAllocator;\n}\n```
MEDIUM severity: The `_calcSpotPrice` function in the BalancerSpotPrice contract and the `_calcSpotPrice` function in. The `_calcSpotPrice` function in the BalancerSpotPrice contract and the `_calcSpotPrice` function in the StableMath contract exhibit discrepancies in their implementation, which may lead to an incorrect computation of the spot price. This vulnerability has the potential to cause significant financia...

Vulnerable code:
```\nFile: BalancerSpotPrice.sol\n\nfunction _calculateStableMathSpotPrice(\n    // Apply scale factors\n    uint256 secondary = balances[index2] * scalingFactors[index2] / BALANCER_PRECISION;\n\n    uint256 invariant = StableMath._calculateInvariant(\n        ampParam, \n        StableMath._balances(scaledPrimary, secondary), \n        true // round up\n    );\n\n    spotPrice = StableMath._calcSpotPrice(ampParam, invariant, scaledPrimary, secondary);\n```\n```\nFile: StableMath.sol\n\n/**\n * @dev Calculates the spot price of token Y in token X.\n */\nfunction _calcSpotPrice(\n    uint256 amplificationParameter,\n    uint256 invariant,\n    uint256 balanceX,\n    uint256 balanceY\n) internal pure returns (uint256) {\n    /**************************************************************************************************************\n    // spot price Y/X = - dx/dy = -----------------------\n    // 2.a.x.y + a.y^2 + b.y\n    // spot price Y/X = - dx/dy = -----------------------\n    // 2.a.x.y + a.x^2 + b.x\n    // n = 2\n    // a = amp param * n\n    // b = D + a.(S - D)\n    // D = invariant\n    // S = sum of balances but x,y = 0 since x  and y are the only tokens\n    **************************************************************************************************************/\n\n    unchecked {\n        uint256 a = (amplificationParameter * 2) / _AMP_PRECISION;\n        uint256 b = Math.mul(invariant, a).sub(invariant);\n\n        uint256 axy2 = Math.mul(a * 2, balanceX).mulDown(balanceY); // n = 2\n\n        // dx = a.x.y.2 + a.y^2 - b.y\n        uint256 derivativeX = axy2.add(Math.mul(a, balanceY).mulDown(balanceY)).sub(b.mulDown(balanceY));\n\n        // dy = a.x.y.2 + a.x^2 - b.x\n        uint256 derivativeY = axy2.add(Math.mul(a, balanceX).mulDown(balanceX)).sub(b.mulDown(balanceX));\n\n        // The rounding direction is irrelevant as we're about to introduce a much larger error when converting to log\n        // space. We use `divUp` as it prevents the result from being zero, which would make the logarithm revert. A\n        // result of zero is therefore only possible with zero balances, which are prevented via other means.\n        return derivativeX.divUp(derivativeY);\n    }\n}\n```\n```\nuint256 b = Math.mul(invariant, a).sub(invariant);\n```
MEDIUM severity: The LootBox system, which is deployed by the LootBoxController, is vulnerable to an unauthenticated . The LootBox system, which is deployed by the LootBoxController, is vulnerable to an unauthenticated self-destruct attack. This is due to the fact that the LootBox implementation contract is not protected, allowing any actor on the blockchain to access and manipulate its functionality. Specifically,...

Vulnerable code:
```\nconstructor() public {\n    lootBoxActionInstance = new LootBox();\n    lootBoxActionBytecode = MinimalProxyLibrary.minimalProxy(address(lootBoxActionInstance));\n}\n```\n```\nfunction destroy(address payable to) external {\n    selfdestruct(to);\n}\n```\n```\ncontract CounterfactualAction {\n    function depositTo(address payable user, PrizePool prizePool, address output, address referrer) external {\n        IERC20 token = IERC20(prizePool.token());\n        uint256 amount = token.balanceOf(address(this));\n        token.approve(address(prizePool), amount);\n        prizePool.depositTo(user, amount, output, referrer);\n        selfdestruct(user);\n    }\n\n    function cancel(address payable user, PrizePool prizePool) external {\n        IERC20 token = IERC20(prizePool.token());\n        token.transfer(user, token.balanceOf(address(this)));\n        selfdestruct(user);\n    }\n}\n```
MEDIUM severity: The `outdated` variable in the `ChainlinkOraclePivot` contract is used to check the timeliness of tw. The `outdated` variable in the `ChainlinkOraclePivot` contract is used to check the timeliness of two price feeds, MATIC/ETH and ETH/USD, on the Polygon mainnet. However, this approach is ineffective due to the different update frequencies of the two price feeds.\n\nThe `outdated` variable is used a...

Vulnerable code:
```\ntry priceFeedA.latestRoundData() returns (\n    uint80,\n    int256 price,\n    uint256,\n    uint256 updatedAt,\n    uint80\n) {\n    require(\n        block.timestamp - updatedAt <= outdated,\n        "ChainLinkOracle: priceFeedA outdated."\n    );\n\n    priceA = SafeCast.toUint256(price);\n}\n\ncatch {\n    revert("ChainLinkOracle: price feed A call failed.");\n}\n\ntry priceFeedB.latestRoundData() returns (\n    uint80,\n    int256 price,\n    uint256,\n    uint256 updatedAt,\n    uint80\n) {\n    require(\n        block.timestamp - updatedAt <= outdated,\n        "ChainLinkOracle: priceFeedB outdated."\n    );\n\n    priceB = SafeCast.toUint256(price);\n}\n\ncatch {\n    revert("ChainLinkOracle: price feed B call failed.");\n}\n```
MEDIUM severity: The FundraisingMultisigTemplate's permission assignment mechanism is vulnerable to potential securit. The FundraisingMultisigTemplate's permission assignment mechanism is vulnerable to potential security risks due to its temporary assignment of permissions to itself. This is achieved through the use of either `acl.createPermission(address(this), app, role, manager)` or the `_createPermissionForTempl...

Vulnerable code:
```\nacl.createPermission(this, controller, controller.ADD_COLLATERAL_TOKEN_ROLE(), this);\n```
MEDIUM severity: The `keep-tecdsa - withdraw should check for zero value transfer` vulnerability occurs when the `wit. The `keep-tecdsa - withdraw should check for zero value transfer` vulnerability occurs when the `withdraw` function in the `KeepBonding` and `BondedECDSAKeep` contracts fails to validate the withdrawal amount before processing the transfer. Specifically, the function does not check if the requested...

Vulnerable code:
```\nfunction withdraw(uint256 amount, address payable destination) public {\n    require(unbondedValue[msg.sender] >= amount, "Insufficient unbonded value");\n\n    unbondedValue[msg.sender] -= amount;\n\n    (bool success, ) = destination.call.value(amount)("");\n    require(success, "Transfer failed");\n}\n```\n```\nfunction withdraw(address _member) external {\n    uint256 value = memberETHBalances[_member];\n    memberETHBalances[_member] = 0;\n\n    (bool success,) = tokenStaking.magpieOf(_member).call.value(value)("");\n    require(success, "Transfer failed");\n```
MEDIUM severity: The vulnerability lies in the implementation of initialization functions in the contracts, which are. The vulnerability lies in the implementation of initialization functions in the contracts, which are designed to be used with a proxy pattern. The initialization functions are not protected, allowing anyone to call them, potentially leading to unauthorized access and manipulation of the contracts. T...

Vulnerable code:
```\nfunction initialize_1(\n    address _admin,\n    address _treasury,\n    address _depositContract,\n    address _elDispatcher,\n    address _clDispatcher,\n    address _feeRecipientImplementation,\n    uint256 _globalFee,\n    uint256 _operatorFee,\n    uint256 globalCommissionLimitBPS,\n    uint256 operatorCommissionLimitBPS\n) external init(1) {\n```\n```\nfunction init(address _dispatcher, bytes32 _publicKeyRoot) external {\n    if (initialized) {\n        revert AlreadyInitialized();\n    }\n    initialized = true;\n    dispatcher = IFeeDispatcher(_dispatcher);\n    publicKeyRoot = _publicKeyRoot;\n    stakingContract = msg.sender; // The staking contract always calls init\n}\n```\n```\nfunction init(address _dispatcher, bytes32 _publicKeyRoot) external {\n    if (initialized) {\n        revert AlreadyInitialized();\n    }\n    initialized = true;\n    dispatcher = IFeeDispatcher(_dispatcher);\n    publicKeyRoot = _publicKeyRoot;\n}\n```