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

Improper Transfer Restrictions on Non-Bridged Tokens Due to Boolean Bridged Token Tracking, Allowing a DoS Attack Vector

Mixing currency and token units in updateParticipation causes wrong accounting and potential loss of funds

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

Attacker can DOS liquidity migration in LiquidityManager.sol

Malicious actors can manipulate the `cross_chain_callback` callback

In settlement.cairo::receive_cross_chain_msg - the payload_type can be passed by the user, confusing offchain systems

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

In settlement.cairo::receive_cross_chain_msg - the message will always be marked with Status::SUCCESS

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

Does not check if to_chain and to_handler is whitelisted in cross_chain_erc20_settlement

`Tokens` Are Automatically Whitelisted Upon Creation And Binding Even When `_whiteListEnabled == false`

The Bridging Process will revert if the Collection is matched on the destination chain and not matched on the source chain

Infinite loop breaks whitelist removal funtionality on L2

Starknet tokens deposited with use_withdraw_auto can never be withdrawn

Reentrancy attack to make an NFT unbridgeable

Users can't vote because of a wrong check in BribeRewarder::_modify()

BribeRewarder.sol allows reward manipulation by malicious users

Wrong check in _requireOnlyOperatorOrOwnerOf in MlumStaking.sol leading to anyone being able to add to someone else's position

Voter.sol::onRegister()

Attacker can make 0 value deposit() calls to deny user from redeeming or withdrawing collateral

A locked fighter can be transferred; leads to game server unable to commit transactions, and unstoppable fighters

Since you can reroll with a different fighterType than the NFT you own, you can reroll bypassing maxRerollsAllowed and reroll attributes based on a different fighterType

Players have complete freedom to customize the fighter NFT when calling `redeemMintPass` and can redeem fighters of types Dendroid and with rare attributes

Non-transferable `GameItems` can be transferred with `GameItems::safeBatchTransferFrom(...)`

User can evade `liquidation` by depositing the minimum of tokens and gain time to not be liquidated

StakingRewards pools are not given their promised share of rewards due to incorrect calculation

Adversary can prevent updating price feed addresses by creating poisonous proposals ending in `_confirm`

Unwhitelisting does not clear _arbitrageProfits, so re-whitelisting may result in an unfair distribution of liquidity rewards.

In CouncilMember.sol

Rewards can be drained because of lack of access control

Looping over unbounded `pendingStakes` array can lead to permanent DoS and frozen funds

Missing deadline check allow pending transactions to be maliciously executed

Fees are hardcoded to 3000 in ExactInputSingleParams

doesn't follow the EIP standard

It may be possible to DoS AuctionHouse by specifying malicious creators

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

Adversary can block `claimAuction()` due to push-strategy to transfer assets to multiple bidders

`GMXVault` can be blocked by a malicious actor

Wrong hardcoded PnL factor is used in all GMXVault add liquidity operations

Incorrect state transition may cause vault in stuck

Borrower can drain all funds of a sanctioned lender

Admin can't burn tokens from blocklisted addresses because of a check in _beforeTokenTransfer

Sandwich attack to steal all ERC-20 tokens in the Fees contract

[H-04] Lender#buyLoan - Malicious user could take over a loan for free without having a pool because of wrong access control

Stealing any loan opening for auction through others' lending pool

Attacker can steal a loan's collateral and break the protocol

Hardcoded Router Address May Cause Token Lockup in Non-Standard Networks

Lender can Sandwich a borrower to seize his collateral

The `borrow` and `refinance` functions can be front-run by the pool lender to set high interest rates

No expiration deadline leads to losing a lot of funds

Single-step process for critical ownership transfer is risky

Fixed fee level is used when swap tokens on Uniswap

Pragma non-specification can lead to non-functional / corrupted contract when deployed on Arbitrum

Club buyers on secondary marketplace could get scammed

Unsafe ERC20.transfer() - unchecked return values

Use safeMint instead of mint for ERC721

_loanTokenBalance can be easily manipulated leading to wrong calculations and loss of funds