These are real world cases of bug fixes reported through Immunefi. To learn more about smart contract vulnerabilities theory check: Vulnerabilities
The bug, which was found within Frontier — the Substrate pallet that provides core Ethereum compatibility features within the Polkadot ecosystem–impacted Moonbeam, Astar Network, and Acala. The estimated potential damage from the vulnerability amounted to approximately $200m across the three projects, which was swiftly prevented
- Vulnerability type: Minting new valid but depegged wrapped tokens.
Allowed users to steal most of the 88MPH tokens generated from yield contract by depositing an asset and withdrawing the vested 88mph tokens immediately.
- Vulnerability type: Theft of funds.
The bug could have allowed users to drain contract funds.
- Vulnerability type: Theft of funds.
Improper impot sanitazion that allowed a bad actor to steal funds using a worthless NEP-141.
- Vulnerability type: Improper Input Sanitization
We need Aurora to execute a burn function on NEAR and wait to withdraw the assets in Ethereum. How do we create a transaction looks like Aurora did it?
- Vulnerability type: Logic, Bridge
Missing call check vulnerability that allows direct theft of native assets.
Vulnerability Type: Missing call check, theft of funds.
- Vulnerability type: Missing Call Check
Potentially exploitable Denial of Service scenario by emptying double entry-point ERC-20 tokens through Balancer’s flash loans.
- Vulnerability type: DoS
Unciphered unveiled three novel exploits impacting popular (and once-popular) crypto wallets Electrum Bitcoin Wallet, Trezor One, and Ethereumwallet.com.
- Vulnerability type: hardware
Logic vulnerability in the fee reclamation and rebate features in Synthetix.
- Vulnerability type: logic
A malicious user could have withdrawn all their obligation collaterals without paying off their full debt.
- Vulnerability type: logic
Missing access control issue in the onSwap() function of the Sense Balancer pool that could have allowed a malicious actor to update the oracle data of the Space AMM contract
- Vulnerability type: access control
The vulnerability consisted of an infinite spend bug that, if exploited by a malicious user, could have led to a direct loss of 70k ETH and $200m in other assets.
- Vulnerability type: infinite spend
Upgradeable proxy implementation self-destruct bug that helped prevent a potential lockup of user funds
- Vulnerability type: upgradeable proxy
The vulnerability would have allowed a malicious attacker to assign a user’s allowance to themselves, enabling the attacker to steal that user’s funds.
- Vulnerability type: Logic and allowance.
The bug would have allowed an attacker to replicate money continuously on any chain using a vulnerability found in OVM 2.0 (Optimism Virtual Machine)
- Vulnerability type: Logic, OVM(EVM equivalent)
Consensus bypass vulnerability that would have allowed an attacker to decrease the total staking power, allowing a consensus (⅔ threshold) bypass that could potentially have allowed an attacker to drain all the funds from the deposit manager, engage in unlimited withdrawals, DoS, and more.
- Vulnerability type: PoS Consensus bypass
In the PT tokens, one condition wasn’t checked during the burn of those tokens which could lead to the theft of the yield from the protocol after the two periods.
- Vulnerability type: Logic error
Free collateral miscalculation and overpricing by a factor of two could allow a bad actor to drain almost all liquidity.
- Vulnerability type: Logic error - Miscalculation
The vulnerability that could allow stealing the fees of the current block in Cronos Blockchain
- Vulnerability type: theft of yield
A front-end critical vulnerability that could allow minting an infinite amount of tokens.
- Vulnerability type: Insecure front-end, mint.
The vulnerability consisted of a lack of balance/allowance check in the transfer() function of Polygon’s MRC20 contract and would have allowed an attacker to steal all MATIC from the contract.
- Type of vulnerability: Lack of balance check.
Vulnerability Type: flash loan/oracle price manipulation.
The Dedaub team filed a submission via Immunefi for uninitialized implementation contracts for Uniswap V3 vault proxies. The contracts in scope held a total of $6.4M in Uniswap V3 positions at the time of the submission.
- Vulnerability Type: Uninitialized Proxies, Access control.
The vulnerability allowed an attacker to exit their burn transaction from the bridge multiple times, up to 223 times. There were around ~$850M at risk. Having just $100k to launch the attack with would result in $22.3M in loss!
- Vulnerability Type: Bridge manipulation.
The vulnerability allowed a malicious node operator included in Lido or RocketPool to steal user deposits frontrunning the deposit.
- Vulnerability Type: Frontrunning
A logic error caused one of the contracts to think it had less money than it did, resulting in excess shares being issued for new deposits.
- Vulnerability Type: Logic Error
Critical reentrancy vulnerability in OpenZeppelin’s TimelockController, where the “executor” was able to hijack the controller and set the delay to 0, remove the existing “proposers”, set themselves as the “proposer” and take over the Timelock and the contracts associated with it.
- Vulnerability Type: Re-entrancy, Access control
The logic error permitted a malicious user to claim more rewards from staking than they were entitled to.
- Vulnerability Type: Logic Error - Excess rewards
The bug allowed a potentially malicious hacker to gain access to funds in a contract.
- Vulnerability Type: Arbitrary call method
The beacon proxy was not initialized and could have been initialized by anyone, including a hypothetical malicious attacker.
- Vulnerability Type: Uninitialized proxy
Any user could have called setWhitelist() to give an attacker the ability to call the harvest function.
- Vulnerability Type: Access control
A critical vulnerability in MCDEX’s broker contract that would have allowed a malicious user to drain that contract of ETH
- Vulnerability Type:
Due to insufficient validation, a malicious user could have claimed the same winning lottery ticket at least 255 times in a single transaction.
- Vulnerability Type: Logic Error - insufficient validation
A malicious user drains Cream’s liquidity mining rewards contract using the front-end and different wallets.
- Vulnerability Type: Front-end - Insufficient Validation
This logic error allows for theft of yield or abuse of the rewards system. A bad actor was able to claim rewards owed to other users and drain the entire contract.
- Vulnerability Type: Logic Error - Improper Validation
A logic error leading to a flash loan attack vector.
- Vulnerability Type: Logic Error, Flash loan
This vulnerability allowed the beneficiary of the time-locked funds to transfer out those funds before those funds were scheduled to be released.
- Vulnerability Type: Arbitrary call
Using the arbitrary call an attacker could call “transferFrom” and since there was no validation of the data provided, the contract will be forced to transfer all the LP tokens from any victim to the attacker.
- Vulnerability Type: Arbitrary call
The init() function was missing an onlyOwner modifier and also there was no initializer to prevent a re-initialization. So init() function was unprotected and was callable multiple times.
Vulnerability Type: Logic Error, Access Control
Web content injection vulnerability that would have allowed a malicious user to inject any arbitrary text on PancakeSwap’s website.
- Vulnerability Type: Content injection
The race condition vulnerability would have allowed a malicious user to repeatedly claim the same voucher, which entitles a user to some amount of crypto tokens. (Race condition).
- Vulnerability type:
The vulnerability was a griefing/denial of service attack against the protocol that would have allowed a malicious user to create a system where bribes had to be paid for a user to buy or sell an NFT.
- Vulnerability Type: Griefing, Denial of Service (DoS)
Theft of Yield using an MEV attack with flash bots.
- Vulnerability Type: MEV, Theft of yield
Flash loan-driven market manipulation vulnerability permits a threat actor to drain 60.000 ETH from the contract.
- Vulnerability Type: Flashloan/oracle price manipulation.
The critical vulnerability consisted of a failure to validate that the receiver of the proceeds of a collateralized loan was the same entity as the borrower, meaning a malicious user could request a loan based on unused collateral from another user.
- Vulnerability Type: Logic - No validation.
Assuming a situation where the FEI price is below the peg, a malicious user could purchase FEI, pushing the price not just back to the 1:1 peg, but above the peg, receiving some amount of FEI as a buy reward in the process. The user could then drip the FEI back into the Uniswap pool via a transfer (not a swap), which bypasses the burn penalty, and finally, convert the FEI to wETH with a swap. As a result, the attacker receives a wETH from the pool without having (net) sold any FEI.
- Vulnerability Type: Logic Error
A user could see the lottery draw transaction, compute the winning lottery number, buy the right ticket during the draw, and front-run with a high gas fee to win the lottery. PancakeSwap fixed the vulnerability by updating its contract to include protections against buying using the multibuy method during the drawing phase.
- Vulnerability Type: Front-running.
A single Dollar worth of coverage could have enabled a malicious attacker to withdraw far more assets than available. Because the exploit allows them to get 10^18 as much as they purchased.
- Vulnerability Type: Logic Error