Migration incorrectly blocked when deposit is paused & `collatToAdd` is zero

Loss to liquidator in direct liquidation path

`OraclePendlePT.latestAnswer()` will not always return `1e18` precision price

First staker excessively benefits from stale `lastUpdateTime`

Loss to liquidator in direct liquidation path

Incorrect assumption that PT to underlying asset rate is 1.0 post-expiry

Rewards With Low Decimal Tokens will Be Lost

OraclePendlePT::latestAnswer does always return price in 18 decimals for some market

User cannot use USDT in PendlePTRouter

Users will lose WStable

sUSDe cannot be withdrawn from WStable

Users with the FULL_RESTRICTED_STAKER_ROLE can still stake whenever receiver is not restricted

Rebalancer Can Steal All Funds

WrapAndSupply::wrapAndSupplyOnExtensionMarket Does Not Pay Gas Fee

Everclearbridge::sendMsg Does Not Pull Tokens

Everclearbridge::sendMsg Does Not Approve Enough Tokens

BatchSubmitter Cannot Handle Liquidation Call

Rebalancer Cannot Manage Returned Funds

Race condition during liquidation unfairly penalizes late liquidators

Users with `realizedInterest` cannot repay when `asset` is paused resulting in unfair liquidation

Unprotected claimRefund Lets Attackers Steal Other Users’ Refunds

`claimLend()` fails to reset `lendAccrued` mapping resulting in token theft

Cross-chain liquidation pulls `seizeTokens` instead of `repayAmount` from liquidator

`borrowCrossChain()` fails to scale `borrow_principle` resulting in cross-chain collateral leftover after full repayment

Incorrect liquidity checks in `redeem()` due to usage of stale index

Faulty `borrowedAssets` tracking enables borrowers to exceed `maxBorrow` limits

Incorrect `maxClose` calculation in `liquidateBorrowAllowedInternal()` prevents max liquidation

Liquidators are forced to supply the liquidated collateral to redeem their reward after liquidation

Double scaling of `borrowed` amount in `borrow()` prevents maximum borrowing

Incorrect netting logic in `commit()` results in incorrect withdrawals

Incorrect `realTax` calculation in `removeValueSingle()` leads to zero tax collection

Double taxation on withdrawal due to miscalculated `removedAmount` in `removeValueSingle()`

Missing `acceptOwnership` selector in Diamond-cuts prevents ownership transfer

PayGasInERC20AndUpdateCctx does not pay protocol for gas fees or protocol fees.

Attacker can steal all tokens as a result of the payWithERC20() function being public

Fee-vault can be made insolvent in case of defaults

Missing reserve interest accrual prior to backstop take rate update leads to incorrect backstop_credit computation

Missing update_rz_emis_data Calls in draw and donate Functions Lead to Incorrect Emissions Distribution

Pools Outside of the Reward Zone can keep receiving Blend Tokens

MergeTgt has no handling if TGT_TO_EXCHANGE is exceeded during the exchange period

Cross-Chain Signature Replay Attack Due to User-Supplied `domainSeparator` and Missing Deadline Check

Incorrect Logic in onlyOperator Modifier Leading to Denial-of-Service for Authorized Operators Across Critical Functions

Using Stale price in pyth network

Creator of one vesting plan can affect vesting plans created by other users.

In the Liquidation Type 1 process, Ether refunds are being sent to an incorrect recipient address

Possible hash collision when creating order

A malicious user can steal all funds from `Bracket`, `StopLimit` and `OracleLess` contract

Possible DoS in `AutomationMaster::getExchangeRate`

`SafeERC20.safeApprove` reverts for changing existing approvals

`PythOracle::currentValue` does not work as expected

Minting zero tokens when underlyingToken is not Ether in cashIn()

Since the cost of launching a new pool is minimal, an attacker can maliciously consume VirtualTokens.

Users can prevent protocol from rebalancing for his gain and cause loss of funds for protocol and its users

Protocol allows creating broken tricrypto CPMM pools

Logical error in `validate_fees_are_paid` can cause a DoS or allow users to bypass fees if `denom_creation_fee` includes multiple coins including `pool_creation_fee` and the user attempts to pay all fees using only `pool_creation_fee`

User cannot claim rewards or close_position, due to vulnerable division by zero handling

Farms can be created to start in past epochs

Wrong simulation function used in reverse operation path

Penalty fees can be shared among future farms or expired farms, risks of exploits

Single sided liquidity can't be used to lock LP tokens in the farm manager

The NFR manager was not changed during the NFR ownership transfer, potentially causing the new owner to not able to claim his rewards or bribes.

Malicious user can delete all lend orders from DLOFactory

Lenders and Borrowers do not get correct incentives

Borrower can deprive lender off interest in a loan

Borrower has to pay more fee than intended to extend loan

Users are incorrectly refunded when liqudity is insufficient

_onTransferReceived() does not work as intended

Tokens are pulled from users without verifying pool status contrary to requirement

Incorrect slippage handling in `swap_internal()`

settlement.cairo doesn't process callback correctly leading to CrossChainMsgStatus marked as SUCCESS even if it failed on destination chain

SettlementSignatureVerifier is missing check for duplicate validator signatures

In Starknet already processed messages can be re-submitted and by anyone

handler's `receive_cross_chain_callback()` will always set the tx_status to `SETTLED` on source chain & burn the tokens (MintBurn Mode) even when the msg fails on destination

A cross-chain message can be initiated with invalid parameters

inconsistency in sender address when creating cross chain messages on Starknet can lead to loss of funds

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

Missing `ERC20Method` validation at destination allows non-transfer tx to be handled as transfers.

Excessive Authority Granted to Managers in the `ckr_btc.cairo` Contract Presents Significant Management Risks

Users are incorrectly refunded when liqudity is insufficient

_onTransferReceived() does not work as intended

Tokens are pulled from users without verifying pool status contrary to requirement

Incorrect slippage handling in `swap_internal()`

Signature replay in `createArt` allows to impersonate artist and steal royalties

`PhiFactory:claim` Potentially Causing Loss of Funds If `mintFee` Changed Beforehand

Attacker can DOS user from selling shares of a credId

Liquidation can be DOSed due to lack of liquidity on collateral asset reserve

The maximum number of generations is infinite

Number of entities in generation can surpass the 10k number

Forger Entities can forge more times than intended

Pause and unpause functions are inaccessible

Reallocation depends on the slot0 price, which can be manipulated.

incorrect price for negative ticks due to lack of rounding down

`updateIRMParams` does not call `applyInterestForToken` before updating `irmParams` which leads to incorrect calculation of interest rate for subsequent trades.

Vaults can become immune from liquidation by setting `vault.recipient` to a blacklisted quote token address

Chainlink's `latestRoundData` might return stale or incorrect results

Lack of slippage and deadline during withdraw and deposit

In Dolomite, when opening a borrow position, the holding position in the Registry will never be updated due to the removePosition flag being set to true

It is possible to open insolvent position is Silo connector, due to missing check in borrow function

The `TVLHelper.sol#getTVL` function is DOSed by the `under collateralized connector`, and as a result, many parts of the protocol may be DOS.

Missing calls to `_updateTokenInRegistry` leads to incorrect state of tokens in registry

Incorrect modifier condition

Stale price can be used in `getValueFromChainlinkFeed` function

Noya is not compatible with tokens whose balance changes outside of transfers causing funds to get stuck in the contract

Registry deletes liquidity positions without verifying complete withdrawal.

No incentive to liquidate small positions could result in protocol going underwater

V3Utils.execute() does not have caller validation, leading to stolen NFT positions from users

Holders array can be manipulated by transferring or burning with amount 0, stealing rewards or bricking certain functions

Anyone can update the address of the Router in the DcntEth contract to any address they would like to set.

Whitelised accounts can be forcefully DoSed from buying curveTokens during the presale

Curves::_buyCurvesToken(), Excess of Eth received is not refunded back to the user.

Attacker can drain all ETH from AuctionDemo when block.timestamp == auctionEndTime

Bidder Funds Can Become Unrecoverable Due to 1 second Overlap in `participateToAuction()` and `claimAuction()`

Bad implementation in minter access control for `RabbitHoleReceipt` and `RabbitHoleTickets` contracts

transfer() depends on gas consts

Use of `payable.transfer()` may lock user funds