Griefing attack on liquidity_lockbox withdrawals due to lack of minimum deposit

Lines of code Vulnerability details Impact The liquiditylockbox contract does not enforce a minimum deposit limit. This allows a user to open many positions with minimum liquidity, forcing other users to close these positions one by one in order to withdraw. This could lead to a griefing attack...

potential griefing attack on deployMarket

Lines of code Vulnerability details Impact potential griefing attack on deployMarket by malicious borrowers Proof of Concept when borrwer try to deployMarket , malicious borrower see paramenters of the deploymarket in transaction pool, take those parameters and deploy market by front runnning...

delegateMulti(...) Griefing Attack

Lines of code Vulnerability details Impact A call to delegateMulti... with the right parameters will consume much gas and waste memory for Proxy Delegators DoS costing the attacker very little. Proof of Concept Calling delegateMulti with many unique targets and amounts of 0 consumes Proxy...

Flashloan excess debt is not sent to user

Lines of code Vulnerability details Impact These vulnerabilities can have the following impacts: 1. Liquidators may lose their eligible funds due to missing transfers of excess debt assets. 2. Excess debt TR tokens could remain in the contract after LP.flashloan claim back borrowed funds, which c...

Forced close position

Lines of code Vulnerability details Impact The impact of this vulnerability is that any entity can forcefully close a user's position, resulting in a potential griefing attack. If the user's position is profitable, the user could lose potential larger profits against their will. Proof of Concept...

Griefing attack on the Vaults is possible, withdrawing the winning side stakes

Lines of code Vulnerability details Anyone can withdraw to receiver once the receiver is isApprovedForAllowner, receiver. The funds will be sent to receiver, but it will happen whenever an arbitrary msg.sender wants. The only precondition is the presence of any approvals. This can be easily used ...

Griefing Attack by staking for any receipent

Lines of code Vulnerability details Impact Any user can grief attack and lock funds of victim by staking with victim address as recipient. Proof of Concept If warmup period is more than 1, it is possible to do this by staking with victim address as recipient with 1 wei amount, and increasing the...

CNote balance can be affected by griefing attack

Lines of code Vulnerability details Functions borrowFresh, repayBorrowFresh, mintFresh, redeemFresh require CNote balance to be strictly zero, reverting unconditionally otherwise. However, as CNote is ERC20 with usual transfer functionality, anyone can send a cNote tokens to the contract itself,...

A malicious filler can fill a partial order in such a way that the rest cannot be filled by anyone

Lines of code Vulnerability details Impact For filling a partial order, because Seaport accepts any representation of a fraction, a malicious filler can provide a giant fraction unreduced. This would severely limit what orders can be filled afterwards and in some cases making any more fills...

Owner's delegates should be decreased in _burn()

Lines of code Vulnerability details function burnuint tokenId internal requireisApprovedOrOwnermsg.sender, tokenId, "caller is not owner nor approved"; address owner = ownerOftokenId; // Clear approval approveaddress0, tokenId; // TODO add delegates // Remove token removeTokenFrommsg.sender,...

Griefing attack by transferring aTokens to the contract

Originally part of a QA report by Tadashi 69 Griefing attack by transferring aTokens to the contract Summary: tokenToShares uses the following formula for computing the total shares of an user: return supply == 0 ? tokens : tokens.mulsupply.divaToken.balanceOfaddressthis; An attacker wishing to...

PermissionlessBasicPoolFactory's pools with fee on transfer tokens can be emptied by repetitive deposit-withdraws

Lines of code Vulnerability details Griefing attack is possible if pool deposit token is a fee on transfer ERC20 as deposit, withdraw atomic call sequence is allowed with pre-fee token quantity being accounted as deposit amount. Suppose F is a fee on transfer token and the pool with F as deposit...

Fund loss or theft by attacker with creating a flash loan and setting SuperVault as receiver so executeOperation() will be get called by lendingPool but with attackers specified params

Lines of code Vulnerability details Impact According to Aave documentation, when requesting flash-loan, it's possible to specify a receiver, so function executeOperation of that receiver will be called by lendingPool. In the SuperVault there is no check to prevent this attack so attacker can use...

makeProposal can be front run with an arbitrary proposal modifications, enabling griefing attack

Handle hyh Vulnerability details Impact Griefing attack is possible for makeProposal as proposal details can be modified by anyone. Proposal setters have no access controls, requiring only that proposal be not current, so when makeProposal is executed after the preparation phase an attacker can...

Griefing attack on migrateLPT can prevent token transfer to L2

Handle harleythedog Vulnerability details Impact In L1Migrator.sol the function migrateLPT can be called by anyone. A malicious user can call migrateLPT with a small maxSubmissionCost argument to intentionally make the retryable ticket creation fail. This will lock the LPT in the L1 escrow. Now,...

Expired insurance status set incorrectly after unlock of funds

Handle ye0lde Vulnerability details Impact Expired insurance status set incorrectly after unlock of funds The insurance status is not set to false and the unlock function can be called over and over driving the lockedAmount to 0. The distorted lockedAmount will then cause liquidity and utilizatio...

Possible griefing attack on vault setStrategy

Handle harleythedog Vulnerability details Impact In the function setStrategy within Vault.sol, there is a requirement that strategy.investedAssets == 0 so that no funds are left stuck in the strategy. A malicious user could strategically transfer 1 wei of underlying to the strategy or any other...

Changing a strategy can be bricked

Handle kenzo Vulnerability details A vault wouldn't let the strategy be changed unless the strategy holds no funds. Since anybody can send funds to the strategy, a griefing attack is possible. Impact Strategy couldn't be changed. Proof of Concept setStrategy requires strategy.investedAssets == 0...

Griefing attack is possible as NFTXStakingZap, PalmNFTXStakingZap, NFTXMarketplaceZap rely on zero vault token balance for LP and minting

Handle hyh Vulnerability details Impact NFTXStakingZap and PalmNFTXStakingZap liquidity provision and NFTXMarketplaceZap minting will be blocked as addLiquidity and mint functions will revert all the time. An attacker can transfer a tiny amount of vault tokens to NFTXStakingZap/PalmNFTXStakingZap...

Anyone can call closeLoan() to close the loan

Handle WatchPug Vulnerability details function closeLoanuint256 amount external override returns uint256 principal, uint256 interest // The amount specified is an optional amount to be transfer from the caller, as a convenience for EOAs. requireamount == uint2560 ||...