Web3 August Security Report: 29 Major Incidents, Over $68.29M Lost

According to data monitored by Beosin Alert, in August 2026, total losses from various security incidents amounted to approximately $76.15 million, with a total of 29 major security incidents occurring, primarily due to contract vulnerabilities. Among these, 18 incidents were caused by contract/network vulnerabilities, and 2 were due to private key leaks. Smart contract security and private key management remain weak points in Web3 security.

On August 13, a personal user address 0x13e3....179e lost WBTC, cbBTC, LDO, USDS, CRV, and other crypto assets due to private key compromise, resulting in total losses of approximately $25.6 million—the largest actual loss in a security 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 around $74 million. The attack prompted the Cronos network to take emergency measures, pausing the network and rolling back transactions; ultimately, the hacker successfully transferred approximately $6 million to the Ethereum network via cross-chain transactions.

Additionally, approximately 4 billion ONE tokens were extra minted on the Harmony blockchain due to a vulnerability, resulting in a nominal loss of over $4 million; however, the forged tokens were ultimately removed by rolling back the transactions, so they are not counted as a loss.

This month, attacks targeted a variety of entities including public blockchains, lending protocols, wallet applications, token contracts, cross-chain bridges, and individual users. DeFi projects suffered the highest losses, totaling $33.09 million, while individual addresses lost approximately $28.4 million due to private key compromises or phishing. Token contracts were the most frequently targeted, with 10 incidents recorded; DeFi contracts ranked second, with 9 attacks.

The blockchain with the highest loss amount in May was Ethereum, with losses exceeding $48.58 million across 15 security incidents. Most DeFi protocols and phishing attacks targeting whales continue to focus primarily on Ethereum. The second most targeted blockchain was BNB Chain, but attacks mainly targeted token contracts, resulting in relatively smaller losses. Additionally, security incidents have occurred on other blockchains such as Cronos, Base, Harmony, Bitcoin, and Solana, indicating a multi-chain attack landscape.

1. Tectonic and Moonwell: Price Manipulation

Tectonic and Moonwell are on-chain lending protocols that were attacked due to price manipulation of certain low-liquidity collateral tokens, allowing attackers to borrow excessive assets based on inflated collateral values. In the Tectonic attack, the attacker artificially inflated the price of Tectonic’s governance token, $TONIC, by 100 times, gaining approximately $74 million in borrowing capacity and subsequently withdrawing assets such as USDT. Following the incident, the Cronos network temporarily halted block production. Before the halt, the attacker transferred approximately $6 million to Ethereum via cross-chain bridges. Subsequently, the Cronos network executed a rollback to recover the losses.

Hacker Ethereum profit address: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD and stolen funds流向:

Approximately 2,659 ETH remain stored at 0xc4041; after 140.1 ETH was transferred to 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c, it was further dispersed to multiple newly created addresses.

Moonwell lost approximately $8.7 million when attackers manipulated the price of the low-liquidity MAMO token to borrow cbBTC:

These two attacks were not based on smart contract vulnerabilities, but rather on the protocol’s practice of pricing collateral from weak spot liquidity, leading to incorrect collateral valuations. To prevent such attacks, the protocol can obtain data from multiple oracles and implement additional checks for significant price fluctuations.

2. Harmony: Replay attack

Harmony is a sharded Layer 1 blockchain that runs four shards and transfers assets between them using a receipt-based asynchronous cross-shard mechanism. The source shard generates encrypted receipts for outbound transactions, and the target shard verifies 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 exploited in this attack exists in the legacy portion of Harmony's sharding system. Previously, Harmony checked whether a shard receipt had already been used by examining two fields: CXMerkleProof.ShardID and BlockNum.

Since these two fields are outside the signed block header, an attacker can modify them without breaking any existing functionality. In this attack, the attacker obtained a cross-shard receipt and altered its ShardID and BlockNum, 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 is a very typical replay attack. For any field used as a "one-time use token," it must be part of the signed header authentication. When verifying the receipt, the shard ID and block number should be read directly from the verified signed block header, not from 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 built on Yearn V3 code. However, Term Finance’s vault governance does not use approval voting, but rather veto voting. When curators propose parameter changes, governors open a window requiring LP token holders to submit objections. However, the governance voting threshold contains a critical vulnerability:

● Lack of absolute vote or capital thresholds: The conditions isSupportThresholdReached() and isMinParticipationReached() check only relative proportions, not absolute vote counts. This means a proposal can pass as long as the relative majority is met, regardless of the total number of voters or the total amount of capital represented.

● Extremely low participation: Almost no depositors have wrapped their vault shares (tmvETH) into governance tokens (gtmvETH) to participate in voting, resulting in an extremely low total supply of governance tokens for the associated vault.

Attackers exploited the aforementioned design flaw to carry out a governance attack on the vault at an extremely low cost:

(1) Obtain voting rights: The attacker exchanged approximately 0.5 ETH for approximately 0.485 tmvETH vault shares and wrapped them 1:1 into 0.485 gtmvETH governance tokens to gain voting rights.

(2) Submitting a malicious proposal: When the attacker created the proposal, the contract recorded the total governance token supply as only 0.535 gtmvETH, meaning the attacker’s 0.485 gtmvETH accounted for 90.66% of the total.

(3) Voting and Execution: The attacker, as the sole voter, casts an approving vote. With no opposing votes, their support rate far exceeds the 50% threshold; additionally, their individual voting power surpasses the minimum participation threshold (minVotingPower) calculated based on the extremely low total supply.

(4) Withdraw assets: After the proposal passed, a malicious action was executed to withdraw the assets (WETH) from the treasury.

The attacker used the same method to compromise six vaults of Term Finance, resulting in 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 implement the following checkpoints for prevention:

● Set absolute vote counts or capital thresholds: Governance proposals cannot pass based solely on relative proportions. A hard threshold based on absolute numbers must be established, such as requiring a minimum amount of voting power (e.g., $1 million) or a minimum number of unique addresses.

● Equip the timelock with a guardian or proposal cancellation path: Although governance execution typically involves a delay, this merely provides a window for response. Project teams must implement an effective guardian mechanism or proposal cancellation path during the execution delay period. If a malicious proposal is detected within the delay period, the guardian can immediately intervene and cancel it.

● Monitor governance participation: The protocol should implement real-time monitoring of governance participation across all treasuries. If a treasury’s total governance token supply or voting participation rate is abnormally low, trigger alerts and potentially automatic protective measures.

Web3 security threat trends

The most profound trend in Web3 security in 2026 is the systematic expansion of the attack surface. Vulnerabilities are emerging simultaneously at the code level, in daily operations, and during interactions; relying solely on a few security audits or tools cannot cover operational security, on-chain governance, and business logic vulnerabilities. This presents new challenges for Web3 projects in building robust security defense systems.

In addition, attacks on DeFi contracts and individual users are becoming increasingly common. Contract vulnerabilities or excessive approvals can easily be exploited by attackers; contract developers and operators should re-evaluate the security of their contracts and conduct multiple, independent security audits for contracts handling core operations. For individual users, it is recommended to regularly use blockchain explorers or revocation tools to check and revoke approvals for contracts no longer in use, and to stay informed about common and emerging phishing tactics to enhance security awareness.

This article was compiled by the Beosin Security Team using Beosin Alert security alerts, on-chain data, and public post-incident analyses from project teams. Feel free to reach out with any questions or feedback.