The `paywitherc20` function is publicly exposed, allowing direct token theft

Malicious user can grief legitimate users by permanently locking their pre-approved ERC20 funds in the StopLimit contract

Griefing other users' ERC20 approvals and permits through unsanitized external call in OracleLess:fillOrder

Malicious users can create orders, charging other users, to be exeucted at unfavorable prices

Almost infinitely doubling the aBondBalance by calling `ABondToken.transferFrom`, where `from` is the attacker's 1st account

`CDS::updateDownsideProtected` lacks access control, and hence allows for DoS'ing `_updateCurrentTotalCdsDepositedAmount` and therefore `deposit`

Contrary to the intended schedule, the users can renew options as often as they wish

The "buyer" newer gets the `receiptID` ERC721 token from the "seller" in exchange for `token`, because the receipt ERC721 token remains stuck in the `BuyOrder` contract with no way to rescue / transfer it

ManagedBudget doesn't comply with fee-on-transfer tokens

In ProtectedListings, listing.checkpoint is greater by 1 than it should be in case the _collection has already been checkpointed at least once during the same block.timestamp, leading to incorect health factor and unlockPrice calculations

SettlementSignatureVerifier is missing check for duplicate validator signatures

Reentrancy Vulnerability Allows Bypass of Cooldown, Leading to Unfair Reward Extraction Through Flash Loan

Exposed `_removeCredIdPerAddress` & `_addCredIdPerAddress` allows anyone to cause issues to current holders as well as upcoming ones

Permanently blocking fair winners from claiming their prizes and getting propagated; and fair users -- from cancelling their raffles -- by maliciously constructing a fake prizeManager contract

The maximum number of generations is infinite

WhenNotPaused modifier in the CDPVault can be bypassed by users

Invalid validation in _farmPlots function allowing a malicious user repeated farming without locked funds

The _totalStaked tracker calculation is incorrect and will be inflated due to the improper logic in the writeOffDebt function of the UserManager contract, leading to wrong Comptroller gInflationIndex being calculated and wrong user rewards being issued

Users can get vouched for (entrusted) maliciously by utilizing the ERC1155Voucher's onERC1155BatchReceived function which lacks proper access control checks

Permanent freezing of user's funds as a consequence of _checkpoint_total_supply using > instead of >= in the RewardsDistributorV2

Exceeding the MAX_DELEGATES limit maliciously will cause operational disruptions in the VotingEscrow

StakingToken.sol doesn't properly handle FOT, rebasing tokens or those with variable which will lead to accounting issues downstream.

`executeWithdraw` may be blocked if any of the users are blacklisted from the `baseToken`

PendleConnector.sol::supply doesn't pass a valid slippance protection min

The modifier `onlyExistingRoute` works incorrectly

Incorrect modifier condition

Balancer flashloan contract can be DOSed completely by sending 1 wei to it

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