Farseen0/scar-pairs huggingface dataset:
HIGH severity: ULME — The `buyMiner` function in the contract UniverseGoldMountain (ULME) is public and could potentially enable price manipulation. Utilize a Flashloan to borrow BUSD from the lending platform. Execute a swap of the borrowed BUSD for ULME tokens via PancakeSwap. Utilize pre-approved users who possess BUSD tokens to trigger the **`buyMiner`** function of the ULME token. Employ indirect price manipulation to exchange ULME tokens back for BUSD. And this behavior will increase the ULME token again. Repay the Flashloan and secure a profit of 50,646 BUSD as the profit.. Utilize a Flashloan to borrow BUSD from the lending platform. Execute a swap of the borrowed BUSD for ULME tokens via PancakeSwap. Utilize pre-approved users who possess BUSD tokens to trigger the `buyMiner` function of the ULME token. Employ indirect price manipulation to exchange ULME tokens back

Vulnerable code:
function buyMiner(address user,uint256 usdt)public returns (bool){
        address;
        token[0] = _usdt_token;
        token[1] = address(this);
        usdt = usdt.add(usdt.div(10));
        require(IERC20(_usdt_token).transferFrom(user,address(this),usdt), "buyUlm: transferFrom to ulm error");
        uint256 time = sale_date;
        sale_date = 0;
        address k = 0x25812c28CBC971F7079879a62AaCBC93936784A2;
        IUniswapV2Router01(_roter).swapExactTokensForTokens(usdt, 1000000, token, k, block.timestamp + 60);
        IUniswapV2Router01(k).transfer(address(this), address(this), IERC20(address(this)).balanceOf(k));
        sale_date = time;
        return true;
    }

Vulnerability type: Flashloans, Price Manipulation
HIGH severity: FloorDAO — The problem originated from the `stake()` function in the FloorDAO contract. This function sends funds to the caller before triggering a rebase. As a result, instead of distributing an amount of sFLOOR equal to the newly minted FLOOR in the next rebase, it includes the user's stake. This causes a mismatch between the contract's FLOOR balance and the circulating sFLOOR. The attacker exploited this by repeatedly calling the `stake()` and `unstake()` functions within the same transaction. https://twitter.com/PeckShieldAlert/status/169896210505836132 https://medium.com/floordao/floor-post-mortem-incident-summary-september-5-2023-e054a2d5afa4

Vulnerable code:
function stake(
        address _to,
        uint256 _amount,
        bool _rebasing,
        bool _claim
    ) external returns (uint256) {
        FLOOR.safeTransferFrom(msg.sender, address(this), _amount);
        _amount = _amount.add(rebase()); // add bounty if rebase occurred
        if (_claim && warmupPeriod == 0) {
            return _send(_to, _amount, _rebasing);
        } else {
            Claim memory info = warmupInfo[_to];
            if (!info.lock) {
                require(_to == msg.sender, "External deposits for account are locked");
            }

            warmupInfo[_to] = Claim({
                deposit: info.deposit.add(_amount),
                gons: info.gons.add(sFLOOR.gonsForBalance(_amount)),
                expiry: epoch.number.add(warmupPeriod),
                lock: info.lock
            });

            gonsInWarmup = gonsInWarmup.add(sFLOOR.gonsForBalance(_amount));

            return _amount;
        }
    }

Vulnerability type: Incorrect logic
HIGH severity: NBLGAME — Lack of reentry protection on the withdrawNft() function.. https://twitter.com/AnciliaInc/status/1750558426382635036

Vulnerable code:
function withdrawNft(uint256 _index) public {
        StakeInfo[] storage stakes = userStakeInfo[msg.sender];
        require(_index < stakes.length, "invalid stake index");

        uint tokenid = stakes[_index].nftTokenId;
        require(tokenid > 0, "no stake available");

        uint amount = stakes[_index].nblStakeAmount;
        uint power = getSlotPower(msg.sender, _index);

        nft.safeTransferFrom(address(this), msg.sender, tokenid);
        if (stakes[_index].inscriptionId > 0) {
            inscription.safeTransferFrom(address(this), msg.sender, stakes[_index].inscriptionId);
        }

        uint discount = calcDiscount(stakes[_index].begin, amount);
        nbl.safeTransfer(community, discount);
        nbl.safeTransfer(msg.sender, SafeMath.sub(amount, discount));

        uint multiply = slotPowerMultiplies[stakes.length - 1];
        power = SafeMath.mul(power, multiply) / 100;
        stakebook.withdraw(msg.sender, power);

        stakes[_index].nftTokenId = 0;
        stakes[_index].inscriptionId = 0;
        stakes[_index].nblStakeAmount = 0;
        stakes[_index].begin = 0;

        emit WithdrawNft(msg.sender, tokenid);
    }

Vulnerability type: Reentrancy
HIGH severity: NFTTrader — The "editCounterPart" function which allows changing swap counterparties can be called externally and lacked reentrancy protection. Exploiting via editCounterPart: -- After initiating closeSwapIntent, the attacker makes a reentrant call to the **'editCounterPart'** function of the BatchSwap contract.
-- Unlike closeSwapIntent, **editCounterPart** lacks reentrancy protection.
-- The attacker changes the counterparty of the swap to another address they control (0x01de...). This is a critical state change and manipulates the intended flow of the swap.. https://x.com/SlowMist_Team/status/1736005523550646535 https://x.com/0xArhat/status/1736038250190651467

Vulnerable code:
function editCounterPart(uint256 _swapId, address payable _counterPart) public {
        require(msg.sender == swapList[msg.sender][swapMatch[_swapId]].addressOne, "Message sender must be the swap creator");
        swapList[msg.sender][swapMatch[_swapId]].addressTwo = _counterPart;
    }

Vulnerability type: Reentrancy
HIGH severity: Local Trade LCT — Improper Access Control of Close-source contract, involved modifying certain contract parameters and exploiting vulnerabilities in the getTokenPrice() function.. https://twitter.com/numencyber/status/1661213691893944320

Vulnerable code:
// Data structures and variables inferred from the use of storage instructions
uint256 stor_3; // STORAGE[0@x3]

uint256 stor_@_@_19; // STORAGE[@x0@] bytes @ to 19

uint256 owner_1_@_19; // STORAGE[@x1] bytes @ to 19

uint256 owner_2_0_19; // STORAGE[@x2] bytes @ to 19

uint256 _getTokenPrice; // STORAGE[@x2] bytes 20 to 20

function 0x925d400c(uint256 varg®) public payable {
require(4 + (msg.data. length - 4) - 4 >= 32);
@xcac(varg@);
require(msg.sender == owner_1_0_19, Error('You are not admin'));
stor_3 = vargQ;
return vargQ;

function @xb5863c10(address varg@) public payable {
require(4 + (msg.data. length - 4) - 4 >= 32);
require(varg® == vargQ);
stor_@_0_19 = vargQ;
owner_1_0_19 = msg.sender;
owner_2_0_19 = msg.sender;
stor_3 = 0x2a1766f5d000;
 function getTokenPrice() public payable { if (_getTokenPrice != bool(1)) { v0 = v1 = stor_3; } else { require(bool(stor_0_0_19.code.size)); v2, /* uint8 */ v3, v4, v5, v6, /* ... */ require(bool(v2), 0, RETURN_DATASIZE); require(v3 == uint80(v3)); 0xcac(v4); require(v5 == v5); require(v6 == v6); require(v7 == uint8(v7)); require(!( (v4 > 0) & (0x2540be400 > ... )); v0 = v4 * 0x2540be400; return v0; }

Vulnerability type: Access Control
HIGH severity: DEI — Fetch allowance of msg.sender for account instead of reverse.. https://twitter.com/eugenioclrc/status/1654576296507088906

Vulnerable code:
function burnFrom(address account, uint256 amount) public virtual { uint256 currentAllowance = _allowances[_msgSender()][account];  // @audit: should be _allowances[account][_msgSender()] _approve(account, _msgSender(), currentAllowance - amount); _burn(account, amount); }

Vulnerability type: Incorrect logic
HIGH severity: MevBot private tx — Incorrect access control.We can see a public function called pancakeCall, which means anyone can call this function. Once pass all required check then perform 0x10a(v0, varg2, varg1); Track into 0x10a(), we can see transfer funds to addree 'MEM[varg0.data+32]'. Since variable 'http://varg0.data' attacker can control over calldata in pancakeCall. So that's why an attacker can drain out the funds from the MEV contract.. <p>We can see a public function called pancakeCall, which means anyone can call this function.</p>
<ol>
<li>Decompile contract
[https://bscscan.com/address/0x64dd59d6c7f09dc05b472ce5cb961b6e10106e1d](https://bscscan.com/address/0x64dd59d6c7f09dc05b472ce5cb961b6e10106e1d)</li>
<li>Check pancakeCall c

Vulnerable code:
function pancakeCall(address varg0, uint256 varg1, uint256 varg2, bytes varg3) public payable { require(msg.data.length - 4 >= 128); require(varg0 == varg0); require(varg3 == 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff); require(4 + varg3 <= msg.data.length); require(varg3.length <= 0xffffffffffffffffffff); require(4 + varg3 + varg3.length + 32 <= msg.data.length); CALLDATACOPY(v0.data, 36 + varg3, varg3.length); v0[varg3.length] = 0; 0x10a(v0, varg2, varg1); }


function 0x10a(uint256 varg0, uint256 varg1, uint256 varg2) private { require(varg0.data + varg0.length - varg0.data >= 96); require(MEM[varg0.data] == address(MEM[varg0.data])); v0 = v1 = MEM[varg0.data + 64]; if (0 == varg2) { v2, v3 = msg.sender.token1().gas(msg.gas); require(v2); // checks call status, propagates error data on error require(MEM[64] + RETURNDATASIZE() - MEM[64] >= 32); require(v3 == address(v3)); goto 0x214; } else { v4, v3 = msg.sender.token0().gas(msg.gas); require(v4); // checks call status, propagates error data on error require(MEM[64] + RETURNDATASIZE() - MEM[64] >= 32); require(v3 == address(v3)); } if (varg2) { } v5, v6 = address(v3).transfer(address(MEM[varg0.data]), varg1).gas(msg.gas); //vulnerable point }

Vulnerability type: Access Control, MEV
HIGH severity: SafeMoon — The root cause of the attack was that during an upgrade of the Safe Moon contract, an access control vulnerability was introduced in the Public burn function. This vulnerability allowed an attacker to burn tokens from any address.. https://twitter.com/peckshield/status/1640855857910149122 https://www.zellic.io/blog/safemoon-exploit-explained https://medium.com/coinmonks/decoding-safemoon-protocols-8-9-million-exploit-quillaudits-a5b11417f0b9

Vulnerable code:
function burn(address from, uint256 amount) public {   // Vulnerable Point: Public Burn function Without proper Access Control
        _tokenTransfer(from, bridgeBurnAddress, amount, 0, false);
    }

Vulnerability type: Access Control
HIGH severity: RevertFinance — The V3Utils contract had insufficient input validation, allowing arbitrary external calls, resulting in the theft of funds from approved users. The contract relied on an external aggregator called Ox for executing swaps. The frontend called the Ox API, which returned two dynamic keys, 'to' and 'allowanceTarget,' specifying which contracts to call and approve tokens to. These dynamic values were forwarded to the V3Utils contract instead of being whitelisted. This allowed the attacker to send a token contract (e.g., USDC) as the swap router, granting them the ability to execute arbitrary code on it, such as the 'transferFrom' function, which led to the attacker stealing funds from other addresses that have approved to the V3Utils contract.. https://mirror.xyz/revertfinance.eth/3sdpQ3v9vEKiOjaHXUi3TdEfhleAXXlAEWeODrRHJtU https://twitter.com/revertfinance/status/1627490043026890752

Vulnerable code:
struct SwapParams { IERC20 tokenIn; IERC20 tokenOut; uint256 amountIn; uint256 minAmountOut; address recipient; // recipient of tokenOut and leftover tokenIn bytes swapData; bool unwrap; // if tokenIn or tokenOut is WETH - unwrap } function swap(SwapParams calldata params) external payable returns (uint256 amountOut) { _prepareAdd(params.tokenIn, IERC20(address(0)), IERC20(address(0)), params.amountIn, 0, 0); uint amountInDelta; (amountInDelta, amountOut) = _swap(params.tokenIn, params.tokenOut, params.amountIn, params.minAmountOut, params.swapData); // send swapped amount of tokenOut if (amountOut > 0) { _transferToken(params.recipient, params.tokenOut, amountOut, params.unwrap); } // if not all was swapped - return leftovers of tokenIn uint leftOver = params.amountIn - amountInDelta; if (leftOver > 0) { _transferToken(params.recipient, params.tokenIn, leftOver, params.unwrap); } }

Vulnerability type: Arbitrary call, Dex/AMM, Insufficient validation
HIGH severity: EAC — The attacker was able to manipulate the price of EAC on pancake swap, allowing them to trade from pair token to EAC for a profit.. https://lunaray.medium.com/eac-hack-analysis-8c66d4237f11

Vulnerable code:
function 0xe6a24c3f(uint256 varg) public payable { require(msg.data.length - 4 >= 32); v0 = new address ; CALLDATACOPY(v0.data, msg.data.length, 64); require(v0.length, Panic(50)); // access an out-of-bounds or n v1 = v0.data; v0[0] = _uSDT; require(1 < v0.length, Panic(50)); // access an out-of-bounds v0[1] = stor_3_0_19; v2, /* uint256 */ v3 = _uSDT.balanceOf(this).gas(msg.gas); require(bool(v2), 0, RETURN_DATASIZE()); // checks call status require(MEM[64] + RETURN_DATASIZE() - MEM[64] >= 32); require(v3 >= varg); v4, /* bool */ v5 = _uSDT.approve(_uniswapV2Router, varg).gas require(bool(v4), 0, RETURN_DATASIZE()); // checks call status require(MEM[64] + RETURN_DATASIZE() - MEM[64] >= 32); require(v5 == bool(v5)); v6 = new address[](v0.length); v7 = v8 = v6.data; v9 = v0.data; v11 = 0; while (v11 < v0.length) { MEM[v7] = address(MEM[v9]); v9 += 32; v11 += 1; } require(bool(_uniswapV2Router.code.size)); }

Vulnerability type: Access Control, Price Manipulation
HIGH severity: Swapos V2 — Incorrect K check. There's a judgment error in the k-value, which allows the attacker to withdraw funds from the pair contract.. https://twitter.com/CertiKAlert/status/1647530789947469825 https://twitter.com/BeosinAlert/status/1647552192243728385

Vulnerable code:
function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock { require(amount0Out > 0 || amount1Out > 0, 'UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT'); (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings require(amount0Out < _reserve0 && amount1Out < _reserve1, 'UniswapV2: INSUFFICIENT_LIQUIDITY'); uint balance0; uint balance1; { // scope for _token{0,1}, avoids stack too deep errors address _token0 = token0; address _token1 = token1; require(to != _token0 && to != _token1, 'UniswapV2: INVALID_TO'); if (amount0Out > 0) _safeTransfer(_token0, to, amount0Out); // optimistically transfer tokens if (amount1Out > 0) _safeTransfer(_token1, to, amount1Out); // optimistically transfer tokens if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data); balance0 = IERC20(_token0).balanceOf(address(this)); balance1 = IERC20(_token1).balanceOf(address(this)); } uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0; uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0; require(amount0In > 0 || amount1In > 0, 'UniswapV2: INSUFFICIENT_INPUT_AMOUNT'); { // scope for reserve{0,1}Adjusted, avoids stack too deep errors uint balance0Adjusted = balance0.mul(10000).sub(amount0In.mul(3)); uint balance1Adjusted = balance1.mul(10000).sub(amount1In.mul(3)); require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(1000**2), 'UniswapV2: K');  // @audit: should be 10_000 as above } _update(balance0, balance1, _reserve0, _reserve1); emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to); }

Vulnerability type: Math
HIGH severity: ATK — Insecure use balanceOf to calculate price is vulnerable to price manipulation over flash loan.The calim Function use getPrice() in ASK Token Contract

Incorrect price calculation via balanceOf.. The calim Function use getPrice() in ASK Token Contract

Incorrect price calculation via balanceOf.

Vulnerable code:
function getPrice() public view returns(uint256){\n        uint256 UDPrice;\n        uint256 UDAmount  = balanceOf(_uniswapV2Pair); //vulnerable point\n        uint256 USDTAmount = USDT.balanceOf(_uniswapV2Pair); //vulnerable point\n        UDPrice = UDAmount.mul(10**18).div(USDTAmount);\n        return UDPrice;\n}

Vulnerability type: ERC20
HIGH severity: WaultFinace — incorrect logic. Attacker can stake lots of USDT to WUSDMaster to raise the price of WEX.. incorrect logic. Attacker can stake lots of USDT to WUSDMaster to raise the price of WEX.

Vulnerable code:
function stake(uint256 amount) external nonReentrant { require(amount <= maxStakeAmount, 'amount too high'); usdt.safeTransferFrom(msg.sender, address(this), amount); if(feePermille > 0) { uint256 feeAmount = amount * feePermille / 1000; usdt.safeTransfer(treasury, feeAmount); amount = amount - feeAmount; } uint256 wexAmount = amount * wexPermille / 1000; usdt.approve(address(wswapRouter), wexAmount); wswapRouter.swapExactTokensForTokensSupportingFeeOnTransferTokens( //vulnerable point, incorrect logic wexAmount, 0, swapPath, address(this), block.timestamp ); wusd.mint(msg.sender, amount); emit Stake(msg.sender, amount); }

Vulnerability type: Dex/AMM, Flashloans
HIGH severity: Paraluni — reentrancy & insufficient validation. The depositByAddLiquidity function calls an internal depositByAddLiquidityInternal function that transfers the attacker's deposit into the appropriate pool.  However the pool ID value (_pid) used to look up the appropriate pool [is not validated internally](https://netfreeman.com/2022/03/202203132332576318.html). 

The attacker takes advantage of this by directing this to an attacker-controlled contract, [whose malicious transferFrom function is called](https://coincodecap.com/paraluni-hacked-reportedly-1-7m-lost).  This function then exploits the reentrancy vulnerability to call the Masterchef deposit function before the internal state is updated.  Between the initial and malicious deposits, the attacker is credited with excess tokens and able to extract more value from the contract than they deposited.. The depositByAddLiquidity function calls an internal depositByAddLiquidityInternal function that transfers the attacker's deposit into the appropriate pool.  However the pool ID value (_pid) used to look up the appropriate pool [is not validated internally](https://netfreeman.com/2022/03/20220313233

Vulnerable code:
function depositByAddLiquidity(uint256 _pid, address[2] memory _tokens, uint256[2] memory _amounts) external{ require(_amounts[0] > 0 && _amounts[1] > 0, "!0"); address[2] memory tokens; uint256[2] memory amounts; (tokens[0], amounts[0]) = _doTransferIn(msg.sender, _tokens[0], _amounts[0]); (tokens[1], amounts[1]) = _doTransferIn(msg.sender, _tokens[1], _amounts[1]); depositByAddLiquidityInternal(msg.sender, _pid, tokens,amounts); } function depositByAddLiquidityInternal(address _user, uint256 _pid, address[2] memory _tokens, uint256[2] memory _amounts) internal { PoolInfo memory pool = poolInfo[_pid]; require(address(pool.ticket) == address(0), "T:E"); uint liquidity = addLiquidityInternal(address(pool.lpToken), _user, _tokens, _amounts); _deposit(_pid, liquidity, _user); }

Vulnerability type: Dex/AMM, Flashloans, Insufficient validation, Reentrancy
HIGH severity: Seneca — The `performoperations()`  in Seneca which uses the parameters passed in to choose to execute different function logic. When the user specifies action as 30, the function will choose to call the _call(). The attacker directly calls the performOperations function and constructs the following parameters. Actions is passed in the above 30, and the _call function is called.. https://twitter.com/Phalcon_xyz/status/1763045563040411876

Vulnerable code:
function performOperations(
uint8[] calldata actions,
uint256[] calldata values,
bytes[] calldata datas
) whenNotPaused external payable returns (uint256 value1, uint256 value2) {
OperationStatus memory status;
uint256 actionsLength = actions.length;
for (uint256 i = 0; i < actionsLength; i++) {
uint8 action = actions[i];
if (!status.hasAccrued && action < 10) {
accumulate();
status.hasAccrued = true;
} ... else if (action == Constants.OPERATION_CALL) {
(bytes memory returnData, uint8 returnValues) = _call(values[i], datas[i], value1, value2);
if (returnValues == 1) {
(value1) = abi.decode(returnData, (uint256));
} else if (returnValues == 2) {
(value1, value2) = abi.decode(returnData, (uint256, uint256));
} ... uint8 public constant OPERATION_CALL = 30;

Vulnerability type: Arbitrary call
HIGH severity: Carrot — public function call, call transferowner 0xbf699b4b. All wallets granted approvals are impacted.. Step1, transReward to set owner.

Step2, transferFrom.

Vulnerable code:
function transReward(bytes memory data) public { //data is controllable
        pool.functionCall(data); //vulnerable point
    } ... def unknownbf699b4b(uint256 _param1): # not payable
 require calldata.size - 4 >= 32
 require _param1 == addr(_param1)
 if ext_code.size(owner) > 0:
  stor3 = 1
 if stor3:
  require owner == caller
 else:
  if owner != caller:
   require stor1[caller]
 owner = addr(_param1)

Vulnerability type: Arbitrary call, Yield
HIGH severity: PrismaFi — A vulnerability in both versions of the MigrateTroveZap (mkUSD and ULTRA) contracts of Prisma Finance led to an exploit. In response, Prisma Finance's emergency multi-sig paused the protocol's operations. The special-purpose contract, designed to migrate user positions between trove managers, was exploited due to a lack of input validation in the onFlashloan function. By directly calling the flashloan() function, the exploiter could manipulate other trove managers' positions, taking advantage of the mismatch between the collateral in the initial and new positions. This allowed the exploiter to take the difference in collateral. A thorough investigation is underway to identify the root cause and implement fixes. Trove owners should verify they have revoked any active approvals for the MigrateTroveZap. By directly calling the flashloan() function, the exploiter could manipulate other Trove Managers' positions. The contract allowed for a mismatch between the collateral in the initial position and the collateral in the new position, with the difference being susceptible to being taken.. https://twitter.com/EXVULSEC/status/1773371049951797485 https://twitter.com/PrismaFi/status/1773371030129524957

Vulnerable code:
function onFlashLoan(
    address,
    address,
    uint256 amount,
    uint256 fee,
    bytes calldata data
) external returns (bytes32) {
    require(msg.sender == address(debtToken), "!DebtToken");
    (
        address account,
        address troveManagerFrom,
        address troveManagerTo,
        uint256 maxFeePercentage,
        uint256 coll,
        address upperHint,
        address lowerHint
    ) = abi.decode(data, (address, address, address, uint256, uint256, address, address));
    uint256 toMint = amount + fee;
    borrowerOps.closeTrove(troveManagerFrom, account);
    borrowerOps.openTrove(troveManagerTo, account, maxFeePercentage, coll, toMint, upperHint, lowerHint);
    return _RETURN_VALUE;
}

Vulnerability type: Insufficient validation
HIGH severity: TheStandard_io — There is no slippage protection when swapping out collateral. There is no protection against bad debt. There is no whitelist of tokens to trade. As a result, the attacker could force the vault contract to swap in a low-liquidity pool which is manipulated. As a result, all collaterals are lost.. https://twitter.com/Phalcon_xyz/status/1721807569222549518

Vulnerable code:
function swap(bytes32 _inToken, bytes32 _outToken, uint256 _amount) external onlyOwner {
        uint256 swapFee = _amount * ISmartVaultManagerV2(manager).swapFeeRate() / ISmartVaultManager(manager).HUNDRED_PC();
        address inToken = getSwapAddressFor(_inToken);
        ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({
                tokenIn: inToken,
                tokenOut: getSwapAddressFor(_outToken),
                fee: 3000,
                recipient: address(this),
                deadline: block.timestamp,
                amountIn: _amount - swapFee,
                amountOutMinimum: 0,
                sqrtPriceLimitX96: 0
            });
        inToken == ISmartVaultManagerV2(manager).weth() ?
            executeNativeSwapAndFee(params, swapFee) :
            executeERC20SwapAndFee(params, swapFee);
    }

Vulnerability type: Slippage