During the past week (Feb 16-Feb 22, 2026), BlockSec detected and analyzed three attack incidents, with total estimated losses of ~$6.22M. The table below summarizes these incidents, and detailed analyses for each case are provided in the following subsections.
| Date | Incident | Type | Estimated Loss |
|---|---|---|---|
| 2026/02/15 | Moonwell Incident | Misconfiguration | ~$1.78M |
| 2026/02/19 | PearlDriver Incident | Arithmetic Overflow | ~$40.3K |
| 2026/02/21 | IoTex Incident | Key Compromise | ~$4.4M |
1. Moonwell Incident
Brief Summary
On February 15, 2026, the Moonwell protocol on Base was exploited due to an oracle misconfiguration, resulting in approximately $1.78 million in bad debt. The issue occurred during the execution of the MIP-X43 proposal, where the Base cbETH oracle was incorrectly assigned a cbETH/ETH exchange rate feed instead of the composite oracle that incorporates the ETH/USD price. This caused the oracle to report cbETH at ~$1.12 rather than its actual market value of ~$2,200. Liquidation bots immediately seized 1,096.317 cbETH while repaying minimal debt before caps were reduced to halt the exploit.
Background
Moonwell is a lending protocol across multiple chains and executed a proposal named MIP-X43 on February 15, 2026. This proposal aimed to activate Chainlink OEV (Oracle Extractable Value) Wrapper contracts across all remaining core and isolated markets on Base and Optimism, extending coverage beyond the initial three feeds enabled in MIP-X38. The OEV wrappers are designed to allow the protocol to capture value during liquidations that rely on oracle prices, while ensuring liquidators remain properly incentivized.
Vulnerability Analysis
The vulnerability stemmed from a configuration error in the ChainlinkOracleConfigs.sol constructor. For Base chain cbETH, the proposal configured the oracle as "cbETHETH_ORACLE" (a cbETH/ETH exchange rate feed) instead of the proper composite oracle that combines this rate with ETH/USD pricing. When the OEV wrapper was deployed and wired as the feed via setFeed() on the ChainlinkOracle, the protocol began using a raw exchange rate (cbETH/ETH ≈ 1.12) as the USD price for cbETH. This created a massive discrepancy between the reported price (~$1.12) and the actual market value ( ～$2,200–$2,400), resulting in a ~2,200x undervaluation of cbETH collateral.
Attack Analysis
-
At 6:01 PM UTC on February 15, 2026, MIP-X43 execution completed, activating the misconfigured cbETH oracle on Base chain.
-
Liquidation bots monitoring the protocol immediately detect the price discrepancy and execute liquidations on cbETH [collateral positions]
-
Within minutes, 1,096.31 cbETH is seized by liquidators, generating ~$1.78M in bad debt across affected markets.
Conclusion
This incident was ultimately caused by a configuration error in Moonwell’s MIP-X43 deployment, where Base chain cbETH was mistakenly assigned a cbETH/ETH exchange rate feed instead of the correct composite oracle. This misconfiguration enabled the rapid depletion of a substantial amount of cbETH collateral.
For protocols managing multiple oracle feeds, it is critical to implement thorough pre-deployment validation procedures to ensure that each asset is linked to its intended price source. Rigorous verification can significantly reduce the risk of such high-impact misconfigurations.
2. PearlDriver Incident
Brief Summary
On February 19, 2026, PearlDriver’s NLAMM bonding curve contract on BSC was exploited, resulting in approximately $40.3K in losses. The root cause was an unchecked arithmetic overflow in the buy() function, allowing the attacker to mint extremely large quantities of game tokens at near-zero cost, then dump them into PearlDEX liquidity pools.
Background
PearlDriver utilizes an NLAMM (Non-Linear Automated Market Maker) bonding curve for token minting. Users can purchase game resource tokens via the buy() function, where the purchase stablecoin cost is calculated as: cost = amount * currentPrice.
Under normal conditions, this formula ensures that the payment required is directly proportional to the quantity purchased. The bonding curve relies on the assumption that larger purchases require correspondingly larger payments, maintaining pricing integrity and preventing disproportionate token issuance.
Vulnerability Analysis
The root cause was an arithmetic overflow in the stablecoin payment calculation. The entire buy() function was wrapped in an unchecked block, disabling Solidity’s built-in overflow protection. As a result, the multiplication used to compute the purchase cost did not revert when exceeding the maximum integer limit. Instead, the value overflowed and wrapped to a much smaller number, drastically reducing the required payment.
Consequently, the attacker was able to pay almost zero while minting an enormous quantity of tokens, which were then immediately dumped into DEX liquidity pairs to drain USDT.
Attack Analysis
In a single transaction, the attacker exploited the vulnerable buy() function across five assets (IRON ORE, COAL, WOOD, SAND, and CLAY) using the same attack pattern. Take the first asset as an example:
-
The attacker specified an extremely large purchase amount when invoking
buy(). Due to unchecked arithmetic, the calculation amount * currentPrice overflowed and wrapped to a near-zero value, requiring only 0.0053 USDT (less than ~$0.01) as payment. Despite the negligible cost, the contract minted an enormous quantity of IRON ORE to the attacker, specifically 7.03 × 10⁵⁸ tokens. -
The attacker immediately swapped a portion of the minted IRON ORE into its corresponding PearlDEX liquidity pair, receiving 7,805.55 USDT (~$7,805.56).
The same overflow-and-dump sequence was executed against the other four assets, draining liquidity from each asset-USDT pair and generating over $40K in total profit.
Conclusion
This incident was caused by unchecked arithmetic in the pricing logic of the NLAMM buy() function. By disabling overflow checks, the function allowed extreme input values to distort the payment calculation, breaking the economic assumptions of the bonding curve model.
While unchecked arithmetic can be appropriate in tightly controlled scenarios, its use in financial logic that directly determines payment amounts can introduce significant risk. To mitigate such risks, developers should carefully review all arithmetic operations and exercise caution when considering disabling Solidity 0.8+ built-in overflow checks, particularly in code paths that affect pricing or transfers.
3. IoTex Incident
Brief Summary
On February 21, 2026, IoTeX’s ioTube bridge suffered a security breach following the compromise of the Ethereum Validator owner key. The attacker gained ownership of the Validator contract, then seized control of TokenSafe and MintPool contracts to drain ~$4.4M worth of bridge reserves and mint over 400M CIOTX tokens. Stolen reserves were swapped and partially bridged to Bitcoin. According to the project, approximately 355M of the minted CIOTX tokens have been permanently locked or frozen.
Background
The compromised ioTube is IoTeX’s cross-chain bridge infrastructure connecting the IoTeX Layer 1 to other networks such as Ethereum. On Ethereum, the bridge architecture centers on the Validator contract (i.e., TransferValidatorWithPayload), which verifies cross-chain settlement messages and manages downstream minter contracts. These include TokenSafe, which holds bridge reserve assets, and MintPool, which holds minting authority for certain tokens such as CIOTX.
Vulnerability Analysis
The root cause was the private key compromise of the Validator contract owner. Because the bridge relied on a single EOA without multi-signature or timelock controls, possession of this key granted full administrative control. Using the contract’s upgrade() function, the attacker transferred ownership of TokenSafe and MintPool contracts to an attacker-controlled address. This enabled direct withdrawal of bridge reserve assets and unauthorized minting of large quantities of CIOTX.
Attack Analysis
-
Compromise the Validator contract owner key on Ethereum, gaining administrative control.
-
Use the Validator contract to transfer ownership of the
TokenSafeandMintPoolcontracts.
-
Drain ~$4.4M in reserve assets (USDC, USDT, WBTC, WETH, BUSD, etc.) from
TokenSafeand mint over 400M CIOTX viaMintPool. -
Swap the stolen reserve tokens and bridge to other chains.
Conclusion
This incident represents a textbook single-point-of-failure key compromise. The entire Ethereum-side bridge security relied on a single EOA with full administrative authority and no multi-signature protection or timelock safeguards. Once the EOA's private key was compromised, control over critical bridge components was effectively lost.
The case highlights the risk of centralized administrative control and underscores the importance of distributing upgrade and custody authority through stronger governance mechanisms.
About BlockSec
BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.
BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.
-
Official website: https://blocksec.com/
-
Official Twitter account: https://twitter.com/BlockSecTeam
