Author: Beosin
According to monitoring data statistics from the Beosin Alert platform, in August 2026, the total loss amount from various security incidents was approximately $76.15 million, with a total of 『29』 major security incidents. The primary cause was contract vulnerabilities. Among these, there were 18 security incidents due to contract/network vulnerabilities and 2 security incidents involving losses from private key leakage. Smart contract security and private key management remain weak points in Web3 security.
Top 10 Losses in August
On August 13th, the personal user address 0x13e3....179e had crypto assets such as WBTC, cbBTC, LDO, USDS, and CRV stolen due to private key leakage, with a total loss of about $25.6 million. This was the security incident with the largest actual loss. On August 30th, the lending protocol Tectonic on the Cronos network suffered a hacker attack due to a contract vulnerability, with an estimated loss of approximately $74 million. This attack led to the Cronos network taking emergency measures, pausing the network and rolling back transactions. The hacker ultimately transferred about $6 million to the Ethereum network via cross-chain transactions.
Additionally, approximately 40 billion ONE tokens were minted extra on the Harmony public chain due to a vulnerability, with a nominal loss exceeding $4 million. However, this was ultimately resolved by rolling back transactions to clear the state of the counterfeit tokens, so it is not counted as a loss.
Types of Attacked Projects and Loss Situation Across Chains
This month, the attacked targets covered various types including public chains, lending protocols, wallet applications, token contracts, cross-chain bridges, and ordinary users. Among them, DeFi projects suffered the largest loss amount, reaching $33.09 million; while losses for personal addresses due to private key leakage or phishing were approximately $28.4 million. Attacks on token contracts were the most frequent, totaling 10 incidents; attacks on DeFi contracts ranked second, with 9 incidents.
The chain with the highest loss amount in May was Ethereum, with losses exceeding $48.58 million and a total of 15 security incidents. Currently, most DeFi protocols and phishing attacks targeting whales are still mainly on Ethereum. The chain with the second-highest number of security incidents was BNB Chain, but the attack targets were primarily token contracts, resulting in smaller loss amounts. Security incidents also occurred on other public chains such as Cronos, Base, Harmony, Bitcoin, and Solana, showing a multi-chain trend in on-chain attacks.
Analysis of Major Security Incidents
1. Tectonic and Moonwell: Price Manipulation
Tectonic and Moonwell are on-chain lending protocols. The reason for their attacks was the manipulation of prices for certain low-liquidity token collaterals, allowing them to borrow excessive assets based on inflated collateral value to profit. In the Tectonic attack, the attacker inflated the price of the Tectonic protocol's governance token $TONIC by 100 times, obtaining a borrowing capacity of approximately $74 million, and then borrowed assets such as USDT. After the incident, the Cronos network urgently paused block production across the entire chain. Before the pause, the attacker transferred about $6 million to Ethereum via cross-chain. Subsequently, the Cronos network performed a rollback to recover the losses.
Hacker's Ethereum profit address: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD and the flow of stolen funds:
Currently, about 2659 ETH remains stored at 0xc4041, and 140.1 ETH was transferred to 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c, then further dispersed to multiple newly created addresses.
Moonwell, on the other hand, lost about $8.7 million because the attacker manipulated the price of the illiquid MAMO token to borrow cbBTC:
These two attacks were not based on smart contract vulnerabilities but rather because the protocols themselves priced collateral from weak spot liquidity, incorrectly calculating collateral value. To avoid such attacks, protocols can obtain data from multiple oracles and implement additional checks for cases of extreme price fluctuations.
2. Harmony: Replay Attack
Harmony is a shard-supporting Layer 1, operating four shards and transferring assets between them via a receipt-based asynchronous cross-shard mechanism. The source shard generates encrypted receipts for outbound transactions, and the target shard is responsible for verifying that the receipt and its Merkle proof match the signed source block header before recording the transaction, with each receipt usable only once.
The vulnerability in this attack existed in the legacy part of Harmony's sharding system. Previously, Harmony checked whether a shard receipt had been used by examining two fields: CXMerkleProof.ShardID and BlockNum,
Because these two fields are outside the signed block header, an attacker could modify them without breaking any existing functionality. In this attack, the attacker obtained a cross-shard receipt, modified the ShardID and BlockNum within it, causing the verification program to recognize it as a brand new receipt. The target shard accepted the modified receipt and recorded it again, while the original shard did not deduct the corresponding assets.
This was a very typical replay attack. For any field used as a "one-time use marker," it must be part of the signed header's authenticated portion. When verifying a receipt, the shard ID and block number should be read directly from the verified signed block header, rather than trusting unauthenticated fields within the proof structure.
3. Term Finance: Governance Attack
Term Finance is a DeFi fixed-rate lending protocol, where each Vault is an ERC-4626 Vault based on the Yearn V3 code. Term Finance's vault governance is not approval voting but veto voting. When a curator proposes a parameter change, governance opens a window requiring LP token holders to raise objections. However, there were serious vulnerabilities in the threshold settings for governance voting:
● Lack of absolute vote count or capital floor: The conditions for proposal passage, isSupportThresholdReached() and isMinParticipationReached(), only check relative proportions, not absolute vote counts. This means that as long as a relative majority is met, the proposal can pass, regardless of the total number of voters or total capital behind those votes.
● Extremely low participation: Almost no depositors wrapped their vault shares (tmvETH) into governance tokens (gtmvETH) to participate in voting. This led to an extremely low total supply of governance tokens for the relevant vaults.
The attacker exploited the above design flaws to carry out a governance attack on the vaults at a very low cost:
(1) Acquiring voting power: The attacker exchanged about 0.5 ETH for approximately 0.485 tmvETH vault shares and wrapped them 1:1 into 0.485 gtmvETH governance tokens, obtaining voting rights.
(2) Initiating a malicious proposal: When the attacker created the proposal, the contract recorded the total governance token supply at that time as only 0.535 gtmvETH. This meant the attacker's holding of 0.485 gtmvETH represented 90.66% of the total.
(3) Voting and execution: The attacker cast an approval vote as the sole voter. Since there were no opposing votes, the support rate far exceeded the 50% threshold; meanwhile, their individual voting power also exceeded the minimum participation threshold (minVotingPower) calculated based on the extremely low total supply.
(4) Extracting assets: After the proposal passed, the malicious operation was executed to withdraw assets (WETH) from the vault.
Using the same method, the attacker compromised a total of 6 vaults in Term Finance, causing losses of approximately $8.5 million.
This attack is also a very typical on-chain protocol governance attack. For on-chain governance, project teams should set up the following checkpoints for prevention:
● Set absolute vote count or capital floor: Governance proposals should not rely solely on relative proportions for passage. A hard threshold based on absolute quantities must be set, for example, requiring approval votes to reach a certain amount (e.g., $1 million) or a number of independent addresses.
● Equip timelocks with guardians or cancellation paths: Although governance execution usually has a delay, this only provides some reaction time. Project teams must equip effective guardian mechanisms or proposal cancellation paths for the execution delay period. Once a malicious proposal is detected during the delay period, the guardian can immediately intervene and cancel it.
● Monitor governance participation: Protocols should establish real-time monitoring of governance participation levels for each vault. When an abnormally low total supply of governance tokens or voting participation rate is detected for a particular vault, alerts should be issued promptly, and even automatic protective measures triggered.
Web3 Security Threat Trends
The deepest trend in Web3 security in 2026 is the systematic expansion of the attack surface. Vulnerabilities are emerging simultaneously at the code level, daily operations, and interactive operations. Relying solely on several security audits or tools cannot cover operational security, on-chain governance, or vulnerabilities in business logic. This poses new challenges for Web3 project teams in building security defense systems.
Additionally, attacks targeting DeFi contracts and individual users are frequent. Contract vulnerabilities or permissions can easily be exploited by attackers. Contract developers or operators should review the security of their contracts. For contracts handling core business, multiple rounds of security audits from different parties should be conducted. For individual users, they should regularly use blockchain explorers or permission-revocation tools to check and cancel contract permissions that are no longer in use, stay informed about common and emerging phishing techniques, and enhance security awareness.
