Farseen0/scar-pairs huggingface dataset:
MEDIUM severity: The `checkAfterExecution` function, responsible for verifying the integrity of the Gnosis Safe's lin. The `checkAfterExecution` function, responsible for verifying the integrity of the Gnosis Safe's linkage with the Hierarchical Storage Guardian (HSG), contains a critical vulnerability. Specifically, it fails to check for the introduction of new modules to the safe, allowing malicious signers to exe...

Vulnerable code:
```\nfunction checkAfterExecution(bytes32, bool) external override {\n    if (abi.decode(StorageAccessible(address(safe)).getStorageAt(uint256(GUARD_STORAGE_SLOT), 1), (address)) \n       != address(this)) {\n        revert CannotDisableThisGuard(address(this));\n    }\n    if (!IAvatar(address(safe)).isModuleEnabled(address(this))) {\n        revert CannotDisableProtectedModules(address(this));\n    }\n    if (safe.getThreshold()!= _correctThreshold()) {\n        revert SignersCannotChangeThreshold();\n    }\n    // leave checked to catch underflows triggered by re-entry\n    attempts--;\n    --guardEntries;\n}\n```
MEDIUM severity: The `setOperatorAddresses` function in the provided code allows the Fee Recipient to modify the oper. The `setOperatorAddresses` function in the provided code allows the Fee Recipient to modify the operator address, which is an incorrect allocation of privileges. This vulnerability enables the Fee Recipient to intentionally disrupt the operator's functionality and exploit the system. \n\nThe functio...

Vulnerable code:
```\nfunction setOperatorAddresses(\n    uint256 _operatorIndex,\n    address _operatorAddress,\n    address _feeRecipientAddress\n) external onlyActiveOperatorFeeRecipient(_operatorIndex) {\n    _checkAddress(_operatorAddress);\n    _checkAddress(_feeRecipientAddress);\n    StakingContractStorageLib.OperatorsSlot storage operators = StakingContractStorageLib.getOperators();\n\n    operators.value[_operatorIndex].operator = _operatorAddress;\n    operators.value[_operatorIndex].feeRecipient = _feeRecipientAddress;\n    emit ChangedOperatorAddresses(_operatorIndex, _operatorAddress, _feeRecipientAddress);\n}\n```
MEDIUM severity: The codebase contains multiple instances of a vulnerability where pending allowances can be exploite. The codebase contains multiple instances of a vulnerability where pending allowances can be exploited. Specifically, several functions in the codebase allow for the transfer of assets without proper authorization checks. This allows an attacker to manipulate the flow of assets by exploiting the pend...

Vulnerable code:
```\nfunction approveBorrow(address spender, uint256 amount) external returns (bool) {\n    _approveBorrow(msg.sender, spender, amount);\n    return true;\n}\n```
MEDIUM severity: The `DynamicLiquidTokenConverter` contract's `isActive` method is currently set to return `true` as . The `DynamicLiquidTokenConverter` contract's `isActive` method is currently set to return `true` as soon as the anchor ownership is transferred, which allows the contract to be used before it is fully configured. This is a departure from the recommended best practice of only returning `true` once th...

Vulnerable code:
```\n/**\n * @dev returns true if the converter is active, false otherwise\n * @return true if the converter is active, false otherwise\n*/\nfunction isActive() public view virtual override returns (bool) {\n    return anchor.owner() == address(this);\n}\n```\n```\n/**\n * @dev returns true if the converter is active, false otherwise\n * @return true if the converter is active, false otherwise\n*/\nfunction isActive() public view override returns (bool) {\n    return super.isActive() && address(priceOracle)!= address(0);\n}\n```\n```\nfunction activate(\n    IERC20Token _primaryReserveToken,\n    IChainlinkPriceOracle _primaryReserveOracle,\n    IChainlinkPriceOracle _secondaryReserveOracle)\n    public\n    {\n    ownerOnly\n    validReserve(_primaryReserveToken)\n    notThis(address(_primaryReserveOracle))\n    notThis(address(_secondaryReserveOracle))\n    validAddress(address(_primaryReserveOracle))\n    validAddress(address(_secondaryReserveOracle))\n}\n```\n```\nmodifier ifActiveOnlyUpgrader() {\n    if (isActive()) {\n        require(owner == addressOf(CONVERTER_UPGRADER), "ERR_ACTIVE_NOT_UPGRADER");\n    }\n}\n```\n```\nuint32 public minimumWeight = 30000;\nuint32 public stepWeight = 10000;\nuint256 public marketCapThreshold = 10000 ether;\nuint256 public lastWeightAdjustmentMarketCap = 0;\n```\n```\nfunction setMarketCapThreshold(uint256 _marketCapThreshold)\n    public\n    ownerOnly\n    ifActiveOnlyUpgrader\n{\n    marketCapThreshold = _marketCapThreshold;\n    emit MarketCapThresholdUpdated(_marketCapThreshold);\n}\n```
MEDIUM severity: The liquidity provider may lose a significant amount of collateral when removing liquidity due to th. The liquidity provider may lose a significant amount of collateral when removing liquidity due to the modulo operation performed on the `shareAmount` when calculating the `amount` to be transferred. This operation discards the remainder of the division, which can result in a loss of up to `lotSize -...

Vulnerable code:
```\nuint256 liquidatableAmount = totalPositionSize.sub(totalPositionSize.mod(governance.lotSize));\nliquidatableAmount = liquidatableAmount.ceil(governance.lotSize).min(maxAmount).min(liquidatableAmount);\n```\n```\n} else if (key == "lotSize") {\n    require(\n        governance.tradingLotSize == 0 || governance.tradingLotSize.mod(value.toUint256()) == 0,\n        "require tls % ls == 0"\n    );\n\n    governance.lotSize = value.toUint256();\n\n} else if (key == "tradingLotSize") {\n    require(\n        governance.lotSize == 0 || value.toUint256().mod(governance.lotSize) == 0,\n        "require tls % ls == 0"\n    );\n\n    governance.tradingLotSize = value.toUint256();\n```\n```\nuint256 amount = shareAmount.wmul(oldPoolPositionSize).wdiv(shareToken.totalSupply());\namount = amount.sub(amount.mod(perpetualProxy.lotSize()));\n\nperpetualProxy.transferBalanceOut(trader, price.wmul(amount).mul(2));\nburnShareTokenFrom(trader, shareAmount);\nuint256 opened = perpetualProxy.trade(trader, LibTypes.Side.LONG, price, amount);\n```
MEDIUM severity: The VaultFactoryV2 contract, designed to ensure secure ownership transitions, is vulnerable to an im. The VaultFactoryV2 contract, designed to ensure secure ownership transitions, is vulnerable to an immediate ownership change bypass. This loophole allows the current owner to circumvent the intended timelock delay, which is intended to prevent rapid-fire changes to critical components, such as marke...

Vulnerable code:
```\n2) Admin can configure new markets and epochs on those markets,\n    Timelock can make critical changes like changing the oracle or whitelisting controllers.\n```\n```\nfunction changeOwner(address _owner) public onlyTimeLocker {\n    if (_owner == address(0)) {\n        revert AddressZero();\n    }\n    _transferOwnership(_owner);\n}\n```\n```\nfunction transferOwnership(address newOwner) public virtual onlyOwner {\n    require(newOwner!= address(0), "Ownable: new owner is the zero address");\n    _transferOwnership(newOwner);\n}\n```
MEDIUM severity: The `onlyMinipoolOwner` access control modifier in the `RocketMinipoolBase` module is inconsistent w. The `onlyMinipoolOwner` access control modifier in the `RocketMinipoolBase` module is inconsistent with its actual implementation and other similar declarations in the codebase. The modifier is intended to permit interactions with the function only by the node owner or the withdrawal address, but it...

Vulnerable code:
```\nmodifier onlyMinipoolOwner() {\n    address withdrawalAddress = rocketStorage.getNodeWithdrawalAddress(nodeAddress);\n    require(msg.sender == nodeAddress || msg.sender == withdrawalAddress, "Only the node operator can access this method");\n    _;\n}\n```\n```\nmodifier onlyMinipoolOwner() {\n    address withdrawalAddress = rocketStorage.getNodeWithdrawalAddress(nodeAddress);\n    require(msg.sender == nodeAddress || msg.sender == withdrawalAddress, "Only the node operator can access this method");\n}\n```\n```\nmodifier onlyMinipoolOwner(address _nodeAddress) {\n    require(_nodeAddress == nodeAddress, "Invalid minipool owner");\n    _\n}\n\nmodifier onlyMinipoolOwnerOrWithdrawalAddress(address _nodeAddress) {\n    require(_nodeAddress == nodeAddress || _nodeAddress == rocketStorage.getNodeWithdrawalAddress(nodeAddress), "Invalid minipool owner");\n    _\n}\n```\n```\nmodifier onlyMinipoolOwner(address _nodeAddress) {\n    require(_nodeAddress == nodeAddress, "Invalid minipool owner");\n    _\n}\n\nmodifier onlyMinipoolOwnerOrWithdrawalAddress(address _nodeAddress) {\n    require(_nodeAddress == nodeAddress || _nodeAddress == rocketStorage.getNodeWithdrawalAddress(nodeAddress), "Invalid minipool owner");\n    _\n}\n```
MEDIUM severity: The `deposit()` function in the `DepositVault.sol` contract does not adhere to the Correctness, Effi. The `deposit()` function in the `DepositVault.sol` contract does not adhere to the Correctness, Efficiency, and Integrity (CEI) pattern, which is a crucial consideration for secure and reliable smart contract development. Specifically, the function's implementation of token transfers does not follow...

Vulnerable code:
```\nDepositVault.sol\nfunction deposit(uint256 amount, address tokenAddress) public payable {\n    require(amount > 0 || msg.value > 0, "Deposit amount must be greater than 0");\n    if (msg.value > 0) {\n        require(tokenAddress == address(0), "Token address must be 0x0 for ETH deposits");\n        uint256 depositIndex = deposits.length;\n        deposits.push(Deposit(payable(msg.sender), msg.value, tokenAddress));\n        emit DepositMade(msg.sender, depositIndex, msg.value, tokenAddress);\n    } else {\n        require(tokenAddress!= address(0), "Token address must not be 0x0 for token deposits");\n        IERC20 token = IERC20(tokenAddress);\n        token.safeTransferFrom(msg.sender, address(this), amount);\n        uint256 depositIndex = deposits.length;\n        deposits.push(Deposit(payable(msg.sender), amount, tokenAddress));\n        emit DepositMade(msg.sender, depositIndex, amount, tokenAddress);\n    }\n}\n```
MEDIUM severity: The `liquidationInitiator` can indefinitely block the purchase of a deposit at an auction by intenti. The `liquidationInitiator` can indefinitely block the purchase of a deposit at an auction by intentionally rejecting the funds. This is achieved by raising an exception during the `initiator.transfer(contractEthBalance)` call, causing the auction to fail and the deposit to remain in a `*_liquidation...

Vulnerable code:
```\nfunction purchaseSignerBondsAtAuction(DepositUtils.Deposit storage _d) public {\n    bool _wasFraud = _d.inFraudLiquidationInProgress();\n    require(_d.inSignerLiquidation(), "No active auction");\n\n    _d.setLiquidated();\n    _d.logLiquidated();\n\n    address tdtHolder = _d.depositOwner();\n\n    TBTCToken _tbtcToken = TBTCToken(_d.TBTCToken);\n\n    uint256 lotSizeTbtc = _d.lotSizeTbtc();\n    require(_tbtcToken.balanceOf(msg.sender) >= lotSizeTbtc, "Not enough TBTC to cover outstanding debt");\n\n    if (tdtHolder == _d.VendingMachine) {\n        _tbtcToken.burnFrom(msg.sender, lotSizeTbtc);  // burn minimal amount to cover size\n    } else {\n        _tbtcToken.transferFrom(msg.sender, tdtHolder, lotSizeTbtc);\n    }\n\n    // Distribute funds to auction buyer\n    uint256 _valueToDistribute = _d.auctionValue();\n    msg.sender.transfer(_valueToDistribute);\n\n    // Send any TBTC left to the Fee Rebate Token holder\n    _d.distributeFeeRebate();\n\n    // For fraud, pay remainder to the liquidation initiator.\n    // For non-fraud, split 50-50 between initiator and signers. if the transfer amount is 1,\n    // division will yield a 0 value which causes a revert; instead, \n    // we simply ignore such a tiny amount and leave some wei dust in escrow\n    uint256 contractEthBalance = address(this).balance;\n    address payable initiator = _d.liquidationInitiator;\n\n    if (initiator == address(0)) {\n        initiator = address(0xdead);\n    }\n    if (contractEthBalance > 1) {\n        if (_wasFraud) {\n            initiator.transfer(contractEthBalance);\n        } else {\n            // There will always be a liquidation initiator.\n            uint256 split = contractEthBalance.div(2);\n            _d.pushFundsToKeepGroup(split);\n            initiator.transfer(split);\n        }\n    }\n}\n```
MEDIUM severity: The `_rebalanceNegativePnlWithSwap()` function in the PerpDepository contract is vulnerable to poten. The `_rebalanceNegativePnlWithSwap()` function in the PerpDepository contract is vulnerable to potential issues due to the repeated use of the `sqrtPriceLimitX96` parameter. This parameter is used to specify the maximum price limit for the Uniswap pool, but it is used twice in the function: once for...

Vulnerable code:
```\nfunction _rebalanceNegativePnlWithSwap(\n    uint256 amount,\n    uint256 amountOutMinimum,\n    uint160 sqrtPriceLimitX96,\n    uint24 swapPoolFee,\n    address account\n) private returns (uint256, uint256) {\n    uint256 normalizedAmount = amount.fromDecimalToDecimal(\n        ERC20(quoteToken).decimals(),\n        18\n    );\n\n    _checkNegativePnl(normalizedAmount);\n\n    bool isShort = false;\n    bool amountIsInput = true;\n\n    (uint256 baseAmount, uint256 quoteAmount) = _placePerpOrder(\n        normalizedAmount,\n        isShort,\n        amountIsInput,\n        sqrtPriceLimitX96\n    );\n\n    vault.withdraw(assetToken, baseAmount);\n\n    SwapParams memory params = SwapParams({\n        tokenIn: assetToken,\n        tokenOut: quoteToken,\n        amountIn: baseAmount,\n        amountOutMinimum: amountOutMinimum,\n        sqrtPriceLimitX96: sqrtPriceLimitX96,\n        poolFee: swapPoolFee\n    });\n\n    uint256 quoteAmountOut = spotSwapper.swapExactInput(params);\n```
MEDIUM severity: The vulnerability lies in the calculation of the wrapped token's scaling factor within the Boosted3T. The vulnerability lies in the calculation of the wrapped token's scaling factor within the Boosted3Token leverage vault. The scaling factor is used to normalize the balance of the wrapped token, allowing for accurate computations within the vault. However, the current implementation in the `getScali...

Vulnerable code:
```\nFile: Boosted3TokenPoolMixin.sol\n\nfunction _underlyingPoolContext(ILinearPool underlyingPool) private view returns (UnderlyingPoolContext memory) {\n    (uint256 lowerTarget, uint256 upperTarget) = underlyingPool.getTargets();\n    uint256 mainIndex = underlyingPool.getMainIndex();\n    uint256 wrappedIndex = underlyingPool.getWrappedIndex();\n\n    (\n        address[] memory tokens,\n        uint256[] memory underlyingBalances,\n        uint256 lastChangeBlock\n    ) = Deployments.BALANCER_VAULT.getPoolTokens(underlyingPool.getPoolId());\n\n    uint256[] memory underlyingScalingFactors = underlyingPool.getScalingFactors();\n    uint256 wrappedScaleFactor = underlyingScalingFactors[mainIndex] * underlyingPool.getWrappedTokenRate() / \n        BalancerConstants.BALANCER_PRECISION;\n\n    return UnderlyingPoolContext({\n        mainScaleFactor: underlyingScalingFactors[mainIndex],\n        mainBalance: underlyingBalances[mainIndex],\n        wrappedScaleFactor: wrappedScaleFactor,\n        wrappedBalance: underlyingBalances[wrappedIndex],\n        virtualSupply: underlyingPool.getVirtualSupply(),\n        fee: underlyingPool.getSwapFeePercentage(),\n        lowerTarget: lowerTarget,\n        upperTarget: upperTarget\n    });\n}\n```\n```\nscalingFactors[_wrappedIndex] = \n    _scalingFactorWrappedToken.mulDown(_getWrappedTokenRate());\n```\n```\nfunction _scalingFactor(IERC20 token) internal view virtual returns (uint256) {\n    if (token == _mainToken) {\n        return _scalingFactorMainToken;\n    } else if (token == _wrappedToken) {\n        return _scalingFactorWrappedToken.mulDown(_getWrappedTokenRate());\n    } else if (token == this) {\n        return FixedPoint.ONE;\n    } else {\n        _revert(Errors.INVALID_TOKEN);\n    }\n}\n\n/**\n * @notice Return the scaling factors for all tokens, including the BPT.\n */\nfunction getScalingFactors() public view virtual override returns (uint256[] memory) {\n    uint256[] memory scalingFactors = new uint256[](_TOTAL_TOKENS);\n\n    scalingFactors[_mainIndex] = _scalingFactorMainToken;\n    scalingFactors[_wrappedIndex] = _scalingFactorWrappedToken.mulDown(_getWrappedTokenRate());\n    scalingFactors[_BPT_INDEX] = FixedPoint.ONE;\n\n    return scalingFactors;\n}\n```
MEDIUM severity: The `RocketMinipoolDelegate` contract's `refund` function contains a redundant call to the `_refund`. The `RocketMinipoolDelegate` contract's `refund` function contains a redundant call to the `_refund` function when forcing finalization. This redundancy arises from the fact that the `_finalise` function, which is called when the minipool is distributed by a user, already performs a refund if there...

Vulnerable code:
```\nfunction refund() override external onlyMinipoolOwnerOrWithdrawalAddress(msg.sender) onlyInitialised {\n    require(nodeRefundBalance > 0, "No amount of the node deposit is available for refund");\n\n    if (!finalised && userDistributed) {\n        _finalise();\n    }\n\n    _refund();\n}\n```\n```\nfunction _finalise() private {\n    RocketMinipoolManagerInterface rocketMinipoolManager = RocketMinipoolManagerInterface(getContractAddress("rocketMinipoolManager"));\n\n    require(!finalised, "Minipool has already been finalised");\n\n    finalised = true;\n\n    if (nodeSlashBalance > 0) {\n        _slash();\n    }\n\n    if (nodeRefundBalance > 0) {\n        _refund();\n    }\n}\n```
MEDIUM severity: The `registerTemplate()` function in the `Factory.sol` contract is vulnerable to a logic error when . The `registerTemplate()` function in the `Factory.sol` contract is vulnerable to a logic error when registering a template with a version of 0. Specifically, when the `templateVersion` is 0, the `latestImplementation[templateName]` variable is not set, and the `_templateNames` array is duplicated.\n...

Vulnerable code:
```\nfunction _setTemplate(\n    string memory templateName,\n    uint256 templateVersion,\n    address implementationAddress\n) internal {\n    if (latestImplementation[templateName] == address(0)) {\n        _templateNames.push(templateName);\n    }\n\n    if (templateVersion > latestVersion[templateName]) {\n        latestVersion[templateName] = templateVersion;\n        if (templateVersion!= 0) {\n            latestImplementation[templateName] = implementationAddress;\n        }\n    }\n}\n```
MEDIUM severity: The `_withdraw` function in the Destination Vault rewards mechanism fails to accurately account for . The `_withdraw` function in the Destination Vault rewards mechanism fails to accurately account for rewards when the total assets pulled exceed the total assets to pull. This occurs when the `info.totalAssetsPulled` exceeds `info.totalAssetsToPull`, causing the `info.idleIncrease` to be set to the d...

Vulnerable code:
```\nuint256 assetPreBal = _baseAsset.balanceOf(address(this));\nuint256 assetPulled = destVault.withdrawBaseAsset(sharesToBurn, address(this));\n\ninfo.idleIncrease += _baseAsset.balanceOf(address(this)) - assetPreBal - assetPulled;\ninfo.totalAssetsPulled += assetPulled;\ninfo.debtDecrease += totalDebtBurn;\n\nif (info.totalAssetsPulled > info.totalAssetsToPull) {\n    info.idleIncrease = info.totalAssetsPulled - info.totalAssetsToPull;\n    info.totalAssetsPulled = info.totalAssetsToPull;\n    break;\n}\n```\n```\n// preBal == 100\n// pulled == 10\n// reward == 5\n// toPull == 6\n\n// idleIncrease = 115 - 100 - 10 == 5\n\n// totalPulled(0) += assetPulled\nif (assetPulled > toPull) {\n    // idleIncrease = totalPulled - toPull\n    if (idleIncrease < reward) {\n        // code\n    }\n}\n```
MEDIUM severity: The vulnerability arises when attempting to increase a leveraged position in a vault that requires b. The vulnerability arises when attempting to increase a leveraged position in a vault that requires borrowing a secondary currency to enter the position. Specifically, when an account initially opens a position in such a vault, the `VaultAccountSecondaryDebtShareStorage.maturity` is set to the maturi...

Vulnerable code:
```\nif (accountMaturity!= 0):\n    require(accountMaturity < maturity)\n```
MEDIUM severity: The CurveTricryptoOracle's `getPrice` function, specifically in the lines `L53-L63`, contains a crit. The CurveTricryptoOracle's `getPrice` function, specifically in the lines `L53-L63`, contains a critical flaw that can lead to inaccurate and inflated LP prices. The issue arises from the assumption that the third token in the pool, `tokens[2]`, is always WETH. However, this assumption is not always...

Vulnerable code:
```\nif (tokens.length == 3) {\n    uint256 ethPrice = base.getPrice(tokens[2]);\n    return (lpPrice(\n        virtualPrice,\n        base.getPrice(tokens[1]),\n        ethPrice,\n        base.getPrice(tokens[0])\n    ) * 1e18) / ethPrice;\n```\n```\n0x4ebdf703948ddcea3b11f675b4d1fba9d2414a14 - CRV\n0x5426178799ee0a0181a89b4f57efddfab49941ec - INV\n0x2889302a794da87fbf1d6db415c1492194663d13 - wstETH\n```
MEDIUM severity: The `LMPVault.updateDebtReporting` function is vulnerable to an integer underflow attack due to the . The `LMPVault.updateDebtReporting` function is vulnerable to an integer underflow attack due to the subtraction of `prevNTotalDebt` from `totalDebt` before adding `afterNTotalDebt`. This vulnerability arises from the calculation of `prevNTotalDebt` as `(destInfo.currentDebt * originalShares) / Math....

Vulnerable code:
```\nL292    totalDebtBurn = cachedCurrentDebt.mulDiv(sharesToBurn, cachedDvShares, Math.Round.Up);\n\nL440    uint256 currentDebt = (destInfo.currentDebt * originalShares) / Math.max(destInfo.ownedShares, 1);\n\nL448    totalDebtDecrease = currentDebt;\n```\n```\nif (currentDvDebtValue < updatedDebtBasis) {\n    currentDvDebtValue = currentDvDebtValue.mulDiv(userShares, totalVaultShares, Math.Rounding.Down);\n    currentDvShares = currentDvShares.mulDiv(userShares, totalVaultShares, Math.Rounding.Down);\n}\n\nif (currentDvDebtValue < maxAssetsToPull) {\n    maxAssetsToPull = currentDvDebtValue;\n}\n\nsharesToBurn = currentDvShares.mulDiv(maxAssetsToPull, currentDvDebtValue, Math.Rounding.Up);\n```
MEDIUM severity: The fee share calculation in the system is flawed, resulting in an incorrect allocation of shares to. The fee share calculation in the system is flawed, resulting in an incorrect allocation of shares to the fee recipient. The current equation used to calculate the shares is faulty, leading to an excessive issuance of shares, thereby granting the fee recipient more fees than they are entitled to.\n\n...

Vulnerable code:
```\n_supplied = 100\n_totalSupply = 100\n\n_interest = 10\nfee = 2\n```\n```\n_accuredFeeShares = fee * _totalSupply / supplied\n_accuredFeeShares = 2 * 100 / 100\n_accuredFeeShares = 2\n```\n```\n2 * 110 / 102 = 2.156\n```\n```\n_accuredFeeShares = (_totalSupply * fee) / (_supplied + _interest - fee)\n_accuredFeeShares = (2 * 100) / (100 + 10 - 2)\n_accuredFeeShares = 200 / 108\n_accuredFeeShares = 1.852\n\n1.852 * 110 / 101.852 = 2\n```
MEDIUM severity: The `Vulnerable GovernorVotesQuorumFraction` version of the protocol is susceptible to a known vulne. The `Vulnerable GovernorVotesQuorumFraction` version of the protocol is susceptible to a known vulnerability in the `UXDGovernor` contract, which inherits from the `GovernorVotesQuorumFraction` contract. This vulnerability was previously patched in version 4.7.2 of the OpenZeppelin contracts, but th...

Vulnerable code:
```\ncontract UXDGovernor is\n    ReentrancyGuard,\n    Governor,\n    GovernorVotes,\n    GovernorVotesQuorumFraction,\n    GovernorTimelockControl,\n    GovernorCountingSimple,\n    GovernorSettings\n```