Web3 August Security Monthly Report: Major Security Incidents 29, Total Losses Exceed 68.29 Million USD

CN
1 hour ago
In August 2026, the main reason for significant security incidents was contract vulnerabilities, with 18 incidents caused by contract/network vulnerabilities and 2 incidents harmed by private key leakage. Security of smart contracts and private key management remain weak links in Web3 security.

Written by: Beosin

According to monitoring data statistics from the Beosin Alert platform, in August 2026, the total amount of losses from various security incidents was approximately 76.15 million dollars, with a total of 29 significant security incidents, primarily due to contract vulnerabilities. Among these, 18 were security incidents caused by contract/network vulnerabilities, and 2 were incidents harmed by private key leakage, indicating that smart contract security and private key management remain weak links in Web3 security.

Top 10 Losses in August

On August 13, a personal user address 0x13e3....179e was hacked due to private key leakage, losing WBTC, cbBTC, LDO, USDS, CRV, and other cryptocurrency assets, with a total loss of approximately 25.6 million dollars, making it the highest actual loss incident. On August 30, the lending protocol Tectonic on the Cronos network suffered a hacker attack due to a contract vulnerability, with estimated losses of about 74 million. This attack led Cronos to take emergency measures, pausing the network and rolling back transactions, with hackers ultimately transferring about 6 million dollars to the Ethereum network through a cross-chain transaction.

In addition, due to a vulnerability, the Harmony public chain had approximately 4 billion ONE tokens minted additionally, nominally causing losses exceeding 4 million dollars, but eventually cleared the status of the counterfeit tokens through rollback transactions and thus are not counted as losses.

Types of Attacked Projects and Losses on Each Chain

This month, the attacked targets included various types such as public chains, lending protocols, wallet applications, token contracts, cross-chain bridges, and individual users, among which DeFi projects suffered the highest losses, reaching as much as 33.09 million dollars; while personal addresses experienced losses of approximately 28.4 million dollars due to private key leakage or phishing. Token contracts were attacked the most, with a total of 10 counts; DeFi contracts ranked second in attacks, with a total of 9 counts.

The chain with the highest loss amount in May was Ethereum, with losses exceeding 48.58 million dollars and a total of 15 security incidents. Currently, most DeFi protocols and phishing attacks targeting whales are still primarily on Ethereum. The second most attacked chain was BNB Chain, but the attack targets were mainly token contracts with relatively small losses. Additionally, security incidents also occurred on public chains such as Cronos, Base, Harmony, Bitcoin, Solana, demonstrating a multi-chain attack situation.

Main Security Event Analysis

1. Tectonic and Moonwell: Price Manipulation

Tectonic and Moonwell are on-chain lending protocols, and the reason for the attacks was the manipulation of collateral prices for certain illiquid tokens, allowing for the borrowing of excess assets at artificially inflated asset values for profit. In the Tectonic attack, attackers raised the price of Tectonic protocol's governance token $TONIC by 100 times, obtaining a borrowing limit of approximately 74 million dollars, and then borrowed assets such as USDT. After the incident, the Cronos network urgently paused the entire chain's block production, and the attacker transferred approximately 6 million dollars to Ethereum before the network was paused. Subsequently, the Cronos network conducted a rollback to mitigate losses.

The hacker's Ethereum profit address: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD and the flow of stolen funds:

Currently, about 2659 ETH remains in 0xc4041, 140.1 ETH transferred to 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c continues to be sent to multiple newly created addresses.

Moonwell was attacked because the attacker manipulated the price of the illiquid MAMO token to borrow cbBTC, resulting in a loss of approximately 8.7 million dollars:

These two attacks were not based on smart contract vulnerabilities but rather because the protocol itself priced collateral from weak spot liquidity, incorrectly calculating the collateral value. To avoid such attacks, protocols can obtain data from multiple oracles and conduct additional assessments for drastic price changes.

2. Harmony: Replay Attack

Harmony is a Layer 1 that supports sharding, operating four shards and transferring assets between them through a receipt-based asynchronous cross-shard mechanism. The source shard generates a cryptographic receipt for outbound transactions, while the target shard is responsible for verifying whether the receipt and its Merkle proof match the signed source block header before recording the transaction, and each receipt can only be used once.

The vulnerability in this attack existed in the legacy parts of the Harmony shard system. Previously, Harmony checked whether the shard receipts were used by examining two fields, CXMerkleProof.ShardID and BlockNum,

As these fields were outside of the signed block header, attackers could modify them without disrupting any existing functionality. In this attack, the attacker acquired a cross-shard receipt and modified its ShardID and BlockNum, causing the validator 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 fields used as "one-time use tokens," they must be part of the signed header certification. When validating receipts, shard ID and block number should be read directly from the verified block header rather than relying on unauthenticated fields in the proof structure.

3. Term Finance: Governance Attack

Term Finance is a DeFi fixed-rate lending protocol, with each vault (Valut) being an ERC-4626 Vault based on Yearn V3 code. The governance of Term Finance’s vaults does not use approval voting but rather rejection voting. When curators propose parameter changes, the governance opens a window for LP token holders to voice objections. However, there are serious flaws in the governance voting thresholds:

● Lack of absolute vote count or capital floor: The conditions for a proposal to pass, 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 amount.

● Extremely low participation: Almost no depositors wrapped their vault shares (tmvETH) into governance tokens (gtmvETH) to participate in the voting. This led to a very low total supply of governance tokens for the related vault.

Attackers took advantage of these design flaws to execute a governance attack on the vaults at very low cost:

(1) Obtaining voting rights: The attacker exchanged about 0.5 ETH for about 0.485 tmvETH vault shares and wrapped them 1:1 into 0.485 gtmvETH governance tokens, gaining voting rights.

(2) Initiating malicious proposals: When the attacker created the proposal, the contract recorded that the total supply of governance tokens at that time was only 0.535 gtmvETH. This meant that the 0.485 gtmvETH held by the attacker accounted for 90.66% of the total.

(3) Voting and execution: The attacker, as the sole voter, cast a favorable vote. Since there were no opposing votes, the support rate far exceeded the 50% threshold; simultaneously, their individual voting power exceeded the minimum participation threshold (minVotingPower) calculated based on the extremely low total supply.

(4) Withdrawing assets: After the proposal passed, malicious operations were executed to withdraw assets (WETH) from the vault.

The attacker used the same method to breach 6 vaults of Term Finance, causing losses of approximately 8.5 million dollars.

This attack is also a very typical on-chain protocol governance attack. For on-chain governance, project teams should set the following checkpoints for prevention:

● Setting absolute vote count or capital floor: Governance proposals cannot rely solely on relative proportions to pass. A hard threshold based on absolute numbers must be set, requiring supporting votes to reach a certain amount (e.g., 1 million dollars) or independent address count.

● Equipping guardians or cancellation pathways for time locks: Although governance execution typically has delays, this only preserves a certain response time. Project teams must equip effective guardians or proposal cancellation pathways during the execution delay period. Should any malicious proposals be discovered within the delay period, the guardian can immediately intervene and cancel.

● Monitoring governance participation: Protocols should establish real-time monitoring of governance participation for each vault. When an abnormal low total supply of governance tokens or voting participation rate for a vault is detected, timely alerts should be issued, and even automatic protective measures triggered.

Web3 Security Threat Trends

The deepest trend presented by Web3 security in 2026 is the systemic expansion of the attack surface. Vulnerabilities are emerging simultaneously at the code level, daily operations, and interaction processes, making it impossible to cover operational security, on-chain governance, and business operation logic vulnerabilities with just a few security audits or tools. This presents new challenges for Web3 project teams in building a security defense system.

Additionally, attacks targeting DeFi contracts and individual users are frequent. Contract vulnerabilities or authorizations may be easily exploited by attackers. Contract developers or operators should review the security of contracts, and for core business handling contracts, multiple and multi-party security audits should be conducted. For individual users, they should regularly use blockchain explorers or authorization revocation tools to check and cancel unused contract authorizations and become more familiar with common and newly developed phishing techniques to enhance security awareness.

免责声明:本文章仅代表作者个人观点,不代表本平台的立场和观点。本文章仅供信息分享,不构成对任何人的任何投资建议。用户与作者之间的任何争议,与本平台无关。如网页中刊载的文章或图片涉及侵权,请提供相关的权利证明和身份证明发送邮件到support@aicoin.com,本平台相关工作人员将会进行核查。

Share To
APP

X

Telegram

Facebook

Reddit

CopyLink