Beosin reports 36 major security incidents in May 2026, with total losses exceeding $76M.

Article by Beosin

According to data monitored by the Beosin Alert platform, in May 2026, total losses from various security incidents amounted to approximately $76.15 million, with a total of 36 major hacking incidents occurring. The primary causes were smart contract vulnerabilities and private key leaks. Among these, 17 incidents resulted from smart contract or network vulnerabilities, and 10 were due to private key compromises, highlighting severe challenges to code and operational security within the DeFi ecosystem.

The Verus-Ethereum Bridge, which connects the Verus L1 chain to Ethereum, was exploited due to a smart contract vulnerability, resulting in the largest loss of $11.58 million. Echo Protocol was compromised when attackers leaked private keys and minted 1,000 eBTC (paper value of approximately $76.7 million), but due to liquidity constraints, the actual profit realized was approximately $5.13 million.

The targets of attacks included cross-chain bridges, decentralized exchanges, lending protocols, prediction markets, stablecoins, and ordinary users. Among these, cross-chain bridges suffered the highest losses, totaling $27.995 million, while DeFi-related projects experienced the most attacks, totaling 14 incidents.

Ethereum suffered the highest loss amount in May, exceeding $48.76 million, with security incidents involving cross-chain bridges and most DeFi protocols still primarily targeting Ethereum. This was followed by BNB Chain, Monad, and TON. Additionally, security incidents occurred on Monero and Bitcoin, indicating a multi-chain attack landscape.

1. Verus: Cross-chain message validation vulnerability

The Verus-Ethereum Bridge operates by having a submitter provide proof data demonstrating that a certified, qualified output exists on the Verus chain; once the bridge contract verifies this proof, assets are released on Ethereum. However, a vulnerability exists in the bridge contract on the Ethereum side: although it validates the proof received from the Verus chain, it does not verify whether the provided data corresponds to a valid original output. This allows an attacker to construct a fraudulent output that passes verification and withdraws far more funds than they have deposited.

Code segment with vulnerabilities:

The vulnerability in this incident is of the same type as those in 2022 that caused Wormhole to lose $320 million and Nomad to lose $190 million—both involved bridges verifying the messages themselves without verifying the underlying value of the funds.

2. Trusted Volumes: Signature Parameter Defect

The attacker exploited a signature design flaw in the TrustedVolumes request-for-quote (RFQ) process by using custom signature data during actual transfers to set the transfer sender as the TrustedVolumes Resolver contract, thereby passing validation and successfully withdrawing assets from the Resolver contract for profit.

Code segment with vulnerabilities:

The authorization check references varg4, but the fund transfer execution references different parameters, resulting in a mismatch between the authorized signer field and the actual debit address due to missing validation.

The attacker only needs to sign an order using a registered signer address, where maker = Exploit (passing the signature verification), while setting all other signature parameters (tokens, amounts) to arbitrary values—such as a fake 1:1 order—that pass the price oracle’s reasonable price check, then withdraw assets from the protocol contract:

3. Private Key Leakage Incident Example: StablR

In May, multiple private key leaks occurred, resulting in total losses exceeding $25 million. Among them, StablR, as a compliant stablecoin issuer, became a typical case study in security governance for the stablecoin and DeFi sectors.

StablR has launched two compliant stablecoin products: EURR and USDR. The multisig wallet controlling EURR minting is 0x8278D2881dBF8F6Fc01c98d196c4b16F1aade5Bc; the multisig wallet controlling USDR minting is 0xF45392bd2D6e6b8C5Dc26BA6c8a12889419B82F3.

Since transactions from the two multisig wallets above require only one signature, the attacker, by controlling the owner address 0xC73fD562de86d7860EE636C20813Bcb2cF4D550d, added the address 0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1 to both multisig wallets, thereby gaining control over the project's minting permissions:

This type of incident is not due to code vulnerabilities, but rather operational security issues by the project team: failing to securely store private keys for privileged addresses, not using high-threshold multisignature for high-value or high-risk operations, lacking time locks for large-scale minting activities, and having no rapid incident response mechanism in place.

The most profound trend in Web3 security for 2026 is the systemic expansion of the attack surface. Vulnerabilities are emerging simultaneously in code, infrastructure, interoperability, and human processes; relying solely on occasional security audits or tools is insufficient to cover operational security, employee endpoints, cloud infrastructure, and software supply chains. This places higher demands on Web3 projects for sustained operational security.

In addition, attacks on outdated or abandoned contracts are frequent, as vulnerabilities or excessive permissions within these contracts can easily be exploited by attackers. Contract developers or operators should re-evaluate the security of previous contracts; for abandoned contracts, they should promptly address or transfer any remaining funds and contact users to revoke unnecessary approvals. Users should also regularly use blockchain explorers or authorization revocation tools to check and cancel approvals for contracts they no longer use.