Farseen0/scar-pairs huggingface dataset:
HIGH severity: UN — The vulnerable provided a gateway for the attacker to manipulate the token's value. https://metatrust.io/blogs/post/unraveling-the-un-attack-a-flash-loan-exploits-flaw-in-token-contract

Vulnerable code:
} else if (from == swapPair) {
    uint256 every = amount.div(100);
    super._transfer(from, address(stake), every * 3);
    stake.sendReward(every * 3);
    super._transfer(from, address(this), every);
    super._transfer(from, market, every * 3);
    super._transfer(from, to, amount - every * 7);
} else if (to == swapPair) {

Vulnerability type: Flashloans
HIGH severity: MicDao — The MicDao exploit occurred due to a vulnerability in the private `_transfer()` function. This function burned MicDao tokens whenever triggered, allowing the attacker to artificially reduce the total supply and inflate the token price.. https://twitter.com/CertiKAlert/status/1714677875427684544 https://twitter.com/ChainAegis/status/1714837519488205276

Vulnerable code:
function _transfer(address sender, address recipient, uint256 amount) internal override {
    if (pairList[recipient] && !isDelivers[sender]) {
        uint256 toBurn = amount.mul(45).div(100);
        super._transfer(sender, address(1), toBurn);
        amount = amount.sub(toBurn);
    }
    super._transfer(sender, recipient, amount);
}

Vulnerability type: Price Manipulation
HIGH severity: Fortress Loans — Insufficient validation in submit() in chain contract. L142 was commented out. There is no verification to ensure the function call is triggered properly. Anyone can call submit function to manipulate price oracle.. L142 was commented out. There is no verification to ensure the function call is triggered properly. Anyone can call submit function to manipulate price oracle.

```solidity
function submit(
    uint32 _dataTimestamp,
    bytes32 _root,
    bytes32[] memory _keys,
    uint256[] memory _values,
    ui

Vulnerable code:
function submit(
    uint32 _dataTimestamp,
    bytes32 _root,
    bytes32[] memory _keys,
    uint256[] memory _values,
    uint8[] memory _v,
    bytes32[] memory _r,
    bytes32[] memory _s
  ) public {
... 
require(i >= requiredSignatures, "not enough signatures");
    // we turn on power once we have proper DPoS
    // require(power * 100 / staked >= 66, "not enough power was gathered");

Vulnerability type: MaliciosProposal
HIGH severity: HPAY — Incorrect access control. Due _addre is controllable. Attacker can call setToken() to set fake token created by self.
1.setToken to faketoken
2.Deposit faketoken
3.setToken to HPAY
3.withdraw.  over. Due _addre is controllable. Attacker can call setToken() to set fake token created by self.

1.setToken to faketoken
2.Deposit faketoken
3.setToken to HPAY
3.withdraw.  over

```solidity
function setToken(address _addr) public { //vulnerable point
        configuration.stakingToken = ERC20(_addr);

Vulnerable code:
function setToken(address _addr) public { //vulnerable point
        configuration.stakingToken = ERC20(_addr);
        configuration.rewardsToken = ERC20(_addr);
    }

Vulnerability type: Access Control, ERC20
HIGH severity: EFVault — Bad contract upgrades cause storage collision. The upgrade introduced new storage items, and modifications were made to the existing storage structure. The original storage order of variables was not maintained. The data storage structure of the old version was not taken into account, so when reading the `assetDecimal` variable in the new implementation contract, the data read is still the proxy contract slot, which is the value of the `maxDeposit` variable of the old version. Due to the Storage Collision, The value of maxDeposit was set to 5000000000000, which is much higher than the value it is expected to set. This results in the return value of the assetPerShare function being much larger and thus the value of assets becomes larger.. https://twitter.com/BeosinAlert/status/1630884733671579653

Vulnerable code:
function assetsPerShare() internal view returns (uint256) {
    return (IController(controller).totalAssets(false) * assetDecimal * 1e18) / totalSupply();
}

function redeem(uint256 shares, address receiver) public virtual nonReentrant unPaused onlyAllowed returns (uint256 assets) {
    require(shares > 0, "ZERO_SHARES");
    require(shares <= balanceOf(msg.sender), "EXCEED_TOTAL_BALANCE");
    assets = (shares * assetsPerShare()) / 1e24; // Miscalculation of assets
    require(assets <= maxWithdraw, "EXCEED_ONE_TIME_MAX_WITHDRAW");
    // Withdraw asset
    _withdraw(assets, shares, receiver);
}

Vulnerability type: Miscalculation, Storage collision, Upgradable
HIGH severity: Templedao — insufficient access control to the migrateStake function.. The `migrateStake` function did not have sufficient access control checks. This allowed an attacker to call the function and migrate funds from the old staking contract to the new contract without proper authorization.

Vulnerable code:
/**
      * @notice For migrations to a new staking contract:
      *         1. User/DApp checks if the user has a balance in the `oldStakingContract`
      *         2. If yes, user calls this function `newStakingContract.migrateStake(oldStakingContract, balance)`
      *         3. Staking balances are migrated to the new contract, user will start to earn rewards in the new contract.
      *         4. Any claimable rewards in the old contract are sent directly to the user's wallet.
      * @param oldStaking The old staking contract funds are being migrated from.
      * @param amount The amount to migrate - generally this would be the staker's balance
      */
    function migrateStake(address oldStaking, uint256 amount) external {. //vulnerable point
        StaxLPStaking(oldStaking).migrateWithdraw(msg.sender, amount);
        _applyStake(msg.sender, amount);
    }

Vulnerability type: Access Control, Yield
HIGH severity: DBW — The root cause is that the dividend awards are based on the percentage of LP currently owned by the user, and does not take into account multiple dividends after the transfer of LP.. https://twitter.com/BeosinAlert/status/1639655134232969216 https://twitter.com/AnciliaInc/status/1639289686937210880

Vulnerable code:
function getStaticIncome() public {
        if(!hasRole(VIP_ROLE, msg.sender)&&!_is_static_dynamic){
            _staticIncome_(msg.sender); //vulnerable point
        }
    }
...
function pledge_lp (uint256 count) public{
        require(!Address.isContract(msg.sender),"the address is contract");
        require(count > 0,"count > 0");
        uint256 _spend = IERC20(_lp).allowance(msg.sender,address(this));
        require(_spend >= count,"lp must be authorized first");
        uint256 _lpBalance = IERC20(_lp).balanceOf(msg.sender);
        require(_lpBalance >= count,"lp Insufficient balance");
        bool _isTransfer = IERC20(_lp).transferFrom(msg.sender,address(this),count);
        require(_isTransfer,"lp transfer err");
        _balances_lp[msg.sender] += count;
        _user_convertLPToDBW[msg.sender] = convertLPToDBW(_balances_lp[msg.sender]);
        ff_handling_fee_user[msg.sender] = _handling_fee;
        
        if(!isHaveLPuser(msg.sender)){
            lpUserCount++;
            lpUsers.push(msg.sender);
        }
    }
...
function redemption_lp (uint256 count) public{
        require(!Address.isContract(msg.sender),"the address is contract");
        require(count > 0,"count > 0");
        require(_balances_lp[msg.sender] >= count,"_balances_lp[msg.sender] >= count");
        
        bool _isTransfer = IERC20(_lp).transfer(msg.sender, count);
        require(_isTransfer,"not lp Transfer");
        _balances_lp[msg.sender] -= count;
        _user_convertLPToDBW[msg.sender] = convertLPToDBW(_balances_lp[msg.sender]);

        uint256 ff_count = getFFCount();
        if(ff_count > 0){
            _transfer(address(this), msg.sender, ff_count);
            //_user_dbw_lp[msg.sender]+=ff_count;
            ff_handling_fee_user[msg.sender] = _handling_fee;
        }
    }

Vulnerability type: Business Logic Flaw, Flashloans, Insufficient validation , Misconfiguration
HIGH severity: Pawnfi — A failure of the protocol to verify whether the NFT had actually been transferred when users used a specified NFT as collateral for borrowing.. https://blog.solidityscan.com/pawnfi-hack-analysis-38ac9160cbb4

Vulnerable code:
function depositAndBorrowAPEandStake(
        DepositInfo memory depositInfo,
        StakingInfo memory stakingInfo,
        IAPECoinStaking.SingleMint[] calldata _nfts,
        IApeCoinStaking.PairsList of paired NFT staking
    ) external nonReentrant {
        address userAddr = msg.sender;
        address ptokenStaking = _getTokenStaking(stakingInfo.nftAsset);
        if (stakingInfo.borrowAmount > 0) {
            uint256 borrowRate = ApePool(pools).borrowRatePerBlock;
            uint256 stakingRate = GetRewardRateBlock(stakingInfo.poolId, stakingInfo.borrowAmount);
            IAPE(pool). borrow(userAddr, stakingInfo.borrowAmount);
            IAPE(pool). safeTransferFrom(userAddr, ptokenStaking, stakingInfo.cashAmount);
        }

        _depositsInTokenHolding(userAddr, stakingInfo.nftAsset, depositInfo.mainTokenIds);
        _depositsInTokenHolding(BACK_ADDR, depositInfo.backTokenIds);
        // more code...
    }

Vulnerability type: Access Control, Incorrect logic
HIGH severity: FILX DN404 — After registering a token, the owner is set to the message sender. the attacker takes advantage of this in the withdraw function where it then withdraws an arbitrary token from the contract which is the FLIX token. which it then swaps out. vulnerable code snippet:
```solidity
function init(
        IERC20 initToken,
        uint256 initPeriods,
        uint256 initInterval
    ) public {
        token = initToken;
        periods = initPeriods;
        interval = initInterval;
        owner = _msgSender();
    }
```
```solidity
functi

Vulnerable code:
function init(
        IERC20 initToken,
        uint256 initPeriods,
        uint256 initInterval
    ) public {
        token = initToken;
        periods = initPeriods;
        interval = initInterval;
        owner = _msgSender();
    }
```
```solidity
function withdraw(
        IERC20 otherToken,
        uint256 amount,
        address receiver
    ) public virtual onlyOwner {
        uint256 currentBalance = otherToken.balanceOf(address(this));
        require(receiver != address(0), "receiver must not empty");
        require(currentBalance >= amount, "current balance insufficient");
        otherToken.safeTransfer(receiver, amount);
    }

Vulnerability type: Access Control
HIGH severity: DYNA — StakingDYNA contract does not handle the deposit time correctly. n the Contract, Users can deposit $DYNA to claim rewards, the interest is calculated based on the deposit duration. However, a vulnerability exists in the contract, as it fails to update the `lastProcessAt` parameter for any deposit. Consequently, the staking duration is miscalculated.. https://twitter.com/BeosinAlert/status/1628301635834486784 https://twitter.com/BlockSecTeam/status/1628319536117153794

Vulnerable code:
function deposit(uint256 _stakeAmount) external {
	require(enabled, "Staking is not enabled");
	require(
		_stakeAmount > 0,
		"StakingDYlA: stake amount must be greater than 0"
	);
	token.transferFrom(msg.sender, address(this), _stakeAmount);
	StakeDetail storage stakeDetail = stakers[msg.sender];
	if (stakeDetail.firstStakeAt == 0) {
		stakeDetail.principal = stakeDetail.principal.add(_stakeAmount);
		stakeDetail.firstStakeAt = stakeDetail.firstStakeAt == 0
			? block.timestamp
			: stakeDetail.firstStakeAt;
		StakeDetail.lastProcessAt = block.timestamp;
	} else {
		StakeDetail.principal = stakeDetail.principal.add(_stakeAmount); // Vulnerable Point: Does not update lastProcessAt.
	}
	emit Deposit(msg.sender, _stakeAmount);
}

Vulnerability type: Flashloans, Miscalculation, staking
HIGH severity: SocketGateway — The exploit originated from wallets with unlimited approvals to Socket contracts, allowing the attacker to exploit vulnerabilities in the protocol's `performAction` function. This flaw enabled a call injection attack by allowing the insertion of malicious code into the `call()` function, compromising the contract's state and enabling unauthorized fund withdrawals.. https://twitter.com/BeosinAlert/status/1747450173675196674

Vulnerable code:
function performAction(
        address fromToken,
        address toToken,
        uint256 amount,
        address receiverAddress,
        bytes32 metadata,
        bytes calldata swapExtraData
    ) external payable override returns (uint256) {
        uint256 _initialBalanceTokenOut;
        uint256 _finalBalanceTokenOut;

        // Swap Native to Wrapped Token
        if (fromToken == NATIVE_TOKEN_ADDRESS) {
            _initialBalanceTokenOut = ERC20(toToken).balanceOf(socketGateway);
            (bool success, ) = toToken.call{value: amount}(swapExtraData);

            if (!success) {
                revert SwapFailed();
            }

            _finalBalanceTokenOut = ERC20(toToken).balanceOf(socketGateway);

            require(
                (_finalBalanceTokenOut - _initialBalanceTokenOut) == amount,
                "Invalid wrapper contract"
            );

            // Send weth to user
            ERC20(toToken).transfer(receiverAddress, amount);
        } else {
            _initialBalanceTokenOut = address(socketGateway).balance;

            // Swap Wrapped Token To Native Token
            ERC20(fromToken).safeTransferFrom(
                msg.sender,
                socketGateway,
                amount
            );

            (bool success, ) = fromToken.call(swapExtraData);

            if (!success) {
                revert SwapFailed();
            }

            _finalBalanceTokenOut = address(socketGateway).balance;

            require(
                (_finalBalanceTokenOut - _initialBalanceTokenOut) == amount,
                "Invalid wrapper contract"
            );

            // send ETH to the user
            payable(receiverAddress).transfer(amount);
        }

        emit SocketSwapTokens(
            fromToken,
            toToken,
            amount,
            amount,
            Identifier,
            receiverAddress,
            metadata
        );

        return amount;
    }

Vulnerability type: Insufficient validation, Unchecked User Input
HIGH severity: ParaSpace NFT — There is a flawed logic in borrow() of the ParaProxy contract (0x638a98BBB92a7582d07C52ff407D49664DC8b3Ee) of  ParaSpace NFT. The attacker can borrow more tokens as his scaledBalance will be enlarged by depositing into the position of the proxy (0xC5c9fB6223A989208Df27dCEE33fC59ff5c26fFF), i.e., specifying the _recipient of depositApeCoin().. https://twitter.com/BlockSecTeam/status/1636650252844294144

Vulnerable code:
function depositApeCoin(uint256 _amount, address _recipient) public { //vulnerable point
        if (_amount < MIN_DEPOSIT) revert DepositMoreThanOneAPE();
        updatePool(APECOIN_POOL_ID);

        Position storage position = addressPosition[_recipient]; //vulnerable point
        _deposit(APECOIN_POOL_ID, position, _amount);

        apeCoin.transferFrom(msg.sender, address(this), _amount);

        emit Deposit(msg.sender, _amount, _recipient);
    }

Vulnerability type: Access Control, Business Logic Flaw
HIGH severity: dForce — Read-only Reentrancy in   the `get_virtual_price` function of the Curve LP Oracle.. https://quillaudits.medium.com/decoding-dforce-protocol-read-only-reentrancy-exploit-quillaudits-c012aed4d666 https://twitter.com/SlowMist_Team/status/1623956763598000129 https://twitter.com/BlockSecTeam/status/1623901011680333824

Vulnerable code:
@external
@nonreentrant('lock')
def remove_liquidity(_amount: uint256, min_amounts: uint256[N_COINS]) -> uint256[N_COINS]:
    """
    @notice Withdraw coins from the pool
    @dev Withdrawal amounts are based on current deposit ratios
    @param _amount Quantity of LP tokens to burn in the withdrawal
    @param min_amounts Minimum amounts of underlying coins to receive
    @return List of amounts of coins that were withdrawn
    """
    _lp_token: address = self.lp_token
    total_supply: uint256 = ERC20(_lp_token).totalSupply()
    amounts: uint256[N_COINS] = empty(uint256[N_COINS])

    for i in range(N_COINS):
        _balance: uint256 = self.balances[i]
        value: uint256 = _balance * _amount / total_supply
        assert value >= min_amounts[i], "Withdrawal resulted in fewer coins than expected"
        self.balances[i] = _balance - value
        amounts[i] = value
        if i == 0:
            raw_call(msg.sender, b"", value=value) // @Vulnerable Point: Here, While Transferring ETH, LP tokens have not been burned. But the pool of ETH has been already reduced.
        else:
            assert ERC20(self.coins[1]).transfer(msg.sender, value)

    CurveToken(_lp_token).burnFrom(msg.sender, _amount)  # Will raise if not enough

    log RemoveLiquidity(msg.sender, amounts, empty(uint256[N_COINS]), total_supply - _amount)

    return amounts

Vulnerability type: Price Manipulation, Reentrancy
HIGH severity: BlueberryProtocol — Prices were being pulled from the PriceOracleProxy which passes calls through to the CoreOracle that is used on the Blueberry Strategies side. This, however, is an incorrect use of the system because the CoreOracle always returns prices scaled to 18 decimals, thus causing assets that have less than 18 decimals to be undervalued significantly when being borrowed.. https://twitter.com/blueberryFDN/status/1760865357236211964

Vulnerable code:
pragma solidity 0.5.16;

import "./PriceOracle.sol";
import "../BErc20.sol";

interface IBaseOracle {
    /// @dev Return the USD based price of the given input, multiplied by 10**18.
    /// @param token The ERC-20 token to check the value.
    function getPrice(address token) external view returns (uint256);
}

contract PriceOracleProxy is PriceOracle {
    IBaseOracle public baseOracle;

    /**
     * @param baseOracle_ The address of BlueBerry Core Oracle
     */
    constructor(IBaseOracle baseOracle_) public {
        baseOracle = baseOracle_;
    }

    /**
     * @notice Get the underlying price of a listed bToken asset
     * @param bToken The bToken to get the underlying price of
     * @return The underlying asset price mantissa (scaled by 1e18)
     */
    function getUnderlyingPrice(BToken bToken) public view returns (uint256) {
        address underlying = BErc20(address(bToken)).underlying();
        return baseOracle.getPrice(underlying);
    }

Vulnerability type: Oracle
HIGH severity: Cover Protocol — Incorrect calculation via cached data. Pool data in storage but forgets to update the cached data. The outdated cached data is later used in calculations and that enables the hack.. The vulnerable code snippet demonstrates that the `deposit` function uses cached data (`pool.lastUpdatedAt`) without updating it in real time. This outdated data is then used for calculations, leading to inaccurate reward distributions.

The `updatePool` function updates the `accRewardsPerToken` and

Vulnerable code:
function deposit(address _lpToken, uint256 _amount) external override {
    require(block.timestamp >= START_TIME , "Blacksmith: not started");
    require(_amount > 0, "Blacksmith: amount is 0");
    Pool memory pool = pools[_lpToken];  //vulnerable point, data cached.
    require(pool.lastUpdatedAt > 0, "Blacksmith: pool does not exists");
    require(IERC20(_lpToken).balanceOf(msg.sender) >= _amount, "Blacksmith: insufficient balance");
    updatePool(_lpToken);

    Miner storage miner = miners[_lpToken][msg.sender];
    BonusToken memory bonusToken = bonusTokens[_lpToken];
    _claimCoverRewards(pool, miner); //old cached data used
    _claimBonus(bonusToken, miner);

    miner.amount = miner.amount.add(_amount);
    // update writeoff to match current acc rewards/bonus per token
    miner.rewardWriteoff = miner.amount.mul(pool.accRewardsPerToken).div(CAL_MULTIPLIER);  //vulnerable point, old cached data used
    miner.bonusWriteoff = miner.amount.mul(bonusToken.accBonusPerToken).div(CAL_MULTIPLIER);  //vulnerable point, old cached data used

    IERC20(_lpToken).safeTransferFrom(msg.sender, address(this), _amount);
    emit Deposit(msg.sender, _lpToken, _amount);
}

Vulnerability type: Miscalculation
HIGH severity: Kashi — The `borrow` function uses the outdated `exchangeRate` to verify the borrowed share in the `solvent` modifier.. https://eigenphi.substack.com/p/casting-a-magic-spell-on-abracadabra https://twitter.com/BlockSecTeam/status/1603633067876155393

Vulnerable code:
function _borrow(address to, uint256 amount) internal returns (uint256 part, uint256 share) {
        uint256 feeAmount = amount.mul(BORROW_OPENING_FEE) / BORROW_OPENING_FEE_PRECISION; // A flat % fee is charged for any borrow

        (totalBorrow, part) = totalBorrow.add(amount.add(feeAmount), true);
        userBorrowPart[msg.sender] = userBorrowPart[msg.sender].add(part);
        emit LogBorrow(msg.sender, to, amount, feeAmount, part);

        share = bentoBox.toShare(asset, amount, false);
        Rebase memory _totalAsset = totalAsset;
        require(_totalAsset.base >= 1000, "Kashi: below minimum");
        _totalAsset.elastic = _totalAsset.elastic.sub(share.to128());
        totalAsset = _totalAsset;
        bentoBox.transfer(asset, address(this), to, share);
    }

Vulnerability type: Incorrect logic
HIGH severity: GAX — The attacker transferred 0 GAX and transferred out 49,583 USDT through the 0x6c99d7c8 method of the vulnerable contract.. https://x.com/EXVULSEC/status/1811348160851378333

Vulnerable code:
function 0x6C99d7c8(uint256 var0, uint256 var1, bool var2) public nonPayable {
    require(4 * (msg.data.length - 4) - 4 == 96);
    if (var2) {
        0x274f(var1, msg.sender, _uSDT);
    } else {
        emit 0x5d3444bfaab188d0ba45fc0d9479e2846405822e46b52e584cac2cc080f(msg.sender, owner_6_0_19, stor_4_0_19, var0, var1);
    }
}

Vulnerability type: Precision
HIGH severity: Meter — insufficient validation. None

Vulnerable code:
address tokenAddress = _resourceIDToTokenContractAddress[resourceID];
require(_contractWhiteList[tokenAddress], "provided tokenAddress is not whitelisted");

if (tokenAddress != _wTokenAddress) {
    if (_burnList[tokenAddress]) {
        burnERC20(tokenAddress, depositer, amount);
    } else {
        lockERC20(tokenAddress, depositer, address(this), amount);
    }
}

Vulnerability type: Bridge, CrossChain, Insufficient validation
HIGH severity: NOON (NO) — Incorrect function visibility. The `_transfer` function has wrong visibility which does not follow standard ERC20 implentation.. https://twitter.com/hexagate_/status/1663501545105702912

Vulnerable code:
function _transfer(address varg0, address varg1, uint256 varg2) public payable {  \n//vulnerable point\n    require(msg.data.length - 4 >= 96);\n    require(varg1);\n    require(varg2 <= _balanceOf[varg0]);\n    require(_balanceOf[varg1] + varg2 > _balanceOf[varg1]);\n    _balanceOf[varg0] = _balanceOf[varg0] - varg2;\n    _balanceOf[varg1] += varg2;\n    emit Transfer(varg0, varg1, varg2);\n    assert(_balanceOf[varg1] + _balanceOf[varg0] == _balanceOf[varg0] + _balanceOf[varg1]);\n}

Vulnerability type: Access Control