市场冷了，黑客没停：跨链桥为什么总是被盯上？

The blockchain seems unusually quiet lately, except for the hackers.

Looking at SlowMist's "Hacked Archive" statistics, although current market heat has dropped and on-chain activity has decreased, hackers remain diligently active in the Web3 world, launching attacks. Among these, cross-chain bridges, DeFi protocols, wallet authorizations, private key management, and phishing attacks remain some of the most common targets for hackers.

According to relevant classifications in SlowMist's "Hacked Archive" statistics, since 2026, Web3 security incidents have caused total losses exceeding $900 million. Among these, there have been over 16 cross-chain bridge-related incidents, with losses of approximately $330 million. Taking recent events as examples:

Gravity Bridge was allegedly attacked due to issues related to contract keys or signature authorizations, resulting in the theft of approximately $5.4 million in assets. The Alephium TokenBridge Ethereum cross-chain bridge also suffered a vulnerability attack, stealing about $815,000 in assets within a short period and minting a large number of unbacked Wrapped ALPH tokens.

Such incidents are not exactly the same as the "wallet theft" most commonly heard by ordinary users. Often, the user's mnemonic phrase hasn't been leaked, and the wallet hasn't signed any malicious transactions. However, if the cross-chain bridge's verification mechanism, signature permissions, or operational infrastructure encounter problems, the assets on the bridge can still be affected.

This is also the aspect of cross-chain bridge risk that is most easily overlooked.

1. Why Are Cross-Chain Bridges Always a Target?

When many users use a cross-chain bridge for the first time, they instinctively think they are transferring assets from Chain A to Chain B.

But more accurately, cross-chain transfers usually don't involve assets actually "moving" from one chain to another. Instead, they complete asset mapping, locking, and re-minting through a set of bridging mechanisms. In short, the true role of a cross-chain bridge is not just a "channel," but more like an asset verification and accounting system between two chains.

And that's where the problem lies.

This means if the bridge's signing keys are compromised, attackers could forge legitimate authorizations. If the number of Guardians is too small or the verification mechanism is bypassed, malicious cross-chain messages could be executed as legitimate ones. If contract permission designs are unreasonable, attackers might bypass normal processes to steal locked assets or mint mapped assets on the target chain without real asset backing.

What the user sees is just one click, but behind it are multiple layers including contract permissions, signature mechanisms, message verification, asset custody, off-chain services, and monitoring systems. A problem in any one of these layers can expose assets to risk. In essence, cross-chain bridges are prone to becoming targets not because the "cross-chain" need itself is flawed, but because they naturally centralize three types of high-value permissions:

• First, cross-chain bridges often hold large amounts of locked assets. Behind many bridged assets are real assets locked on the source chain. If a bridge contract holds a large amount of USDC, USDT, ETH, or other highly liquid assets, it naturally becomes a prime target for attackers.
• Second, cross-chain bridges must solve the problem of "what happened on the other chain." Because a blockchain cannot natively read the state of another chain, cross-chain bridges must rely on some verification mechanism, such as validator signatures or other relay systems. The more complex these mechanisms, the larger the attack surface.
• Finally, ordinary users find it difficult to directly assess the true security status of a bridge. Just because a cross-chain page can be opened doesn't mean the bridge is secure. Users can't easily tell from the front-end whether the bridge's signers are safe, the contract permissions are reasonable, or the backend services have been compromised.

The recent Kelp DAO security incident pushed this discussion back into the spotlight. Public post-mortems show that such incidents don't necessarily stem from code vulnerabilities in the smart contracts themselves but can originate from cross-chain verification configurations, off-chain infrastructure, or operational security procedures.

In other words, the so-called "interoperability" between many L1s, L2s, and multi-chain applications today still fundamentally relies on a series of trusted relay, verification, and signature mechanisms. Once these mechanisms are misconfigured or compromised, they can become the weakest link in the entire system.

This is why cross-chain security cannot rely solely on users being "more careful" or on protocols being "audited once." It requires wallets, protocols, security teams, cross-chain infrastructure, and users to jointly establish a more comprehensive risk identification and protection mechanism.

2. Cross-Chain Isn't Unusable, But It Requires One More Step of Judgment

Of course, objectively speaking, cross-chain bridges are not unusable.

The multi-chain ecosystem has become a reality of Web3. Users need to transfer assets, use applications, participate in DeFi, or manage positions across different networks. Cross-chain bridges remain critical infrastructure. What truly needs to change isn't "completely avoiding cross-chain," but rather not treating cross-chain like a regular transfer.

Before a cross-chain operation, users should at least take a few extra steps to make judgments.

First, confirm the entry point is from an official channel. Be especially careful not to enter cross-chain pages from community DMs, search ads, unfamiliar tutorials, or comment section links. Especially right after a security incident, attackers are likely to create fake phishing sites for "asset migration," "emergency recovery," etc., tricking people into connecting wallets, authorizing assets, or entering mnemonic phrases.

Second, check if the project has issued an anomaly announcement. If a bridge has just been attacked, don't rush to continue using it, and don't blindly trade the related wrapped assets. Because based on historical experience, risks are often not fully cleared immediately after an attack. Attackers may still hold unbacked assets or continue to extract real assets using market liquidity.

Third, test with a small amount. Don't transfer large sums in one go. Especially when using an unfamiliar bridge, an unfamiliar chain, or a newly launched bridge, first use a small amount to confirm the path, arrival time, and whether the assets on the target chain are normal. While a small test can't eliminate all risks, it can reduce large losses caused by path errors, fake entry points, or asset identification issues.

Fourth, try to avoid infinite approvals when authorizing. Many cross-chain operations require authorizing tokens to a contract beforehand. If you're only transferring 100 USDT, try not to give a long-term approval far exceeding the actual usage amount. The larger the approval amount, the higher the subsequent potential risk exposure. This is especially true for DApp approvals that are not used for a long time, from unknown sources, or whose security status has changed. These should be regularly checked and cleaned up.

Fifth, carefully read signature and transaction information. Don't continuously click confirm just because you're in a hurry. Especially if you see an unfamiliar website, an unusual contract address, strange signature content, or a permission request inconsistent with your expected operation, stop immediately.

Finally, even after the cross-chain operation is complete, the security check shouldn't end immediately. Many users might think the operation is over once the assets arrive. But from a security perspective, checks after the cross-chain transfer are equally important:

• After completing the cross-chain transfer, first use a block explorer to check the transaction status on both the source and target chains. Confirm that the assets have truly been transferred, rather than just relying on the front-end display.
• Also confirm whether the assets received on the target chain are issued by an official or trusted contract. Don't casually trade tokens with the same name from unknown sources. Don't just click on associated websites or claim portals just because a certain asset suddenly appears in your wallet.
• Finally, regularly check and clean up unused approvals. Many approvals don't expire automatically. If you once granted a high-limit approval to a cross-chain bridge, DApp, or contract, the risk exposure may persist even if you no longer use it.

Ultimately, security doesn't only happen at the moment you safeguard your mnemonic phrase. It runs through the entire process of connecting to DApps, authorizing tokens, signing transactions, cross-chain transfers, and subsequent cleanup.

3. Even More Insidious Than Bridges, Is The "Human" Being Compromised

Cross-chain bridge incidents remind us that on-chain infrastructure itself can pose risks. However, from the perspective of ordinary users, another more common and insidious risk comes from social engineering attacks.

Social engineering attacks don't necessarily rely on complex code vulnerabilities. Their core is to exploit human habits, trust, anxiety, and information asymmetry, making users perform dangerous operations themselves.

In recent years, targeted phishing attacks, private key theft, malicious authorizations, and fake address scams against users have become very high-frequency sources of Web3 asset loss. This indicates that hackers aren't always obsessed with breaking smart contracts themselves but are increasingly turning towards user operations and off-chain systems.

Common social engineering attacks often revolve around one word: deception.

For example, attackers might use dust attacks, airdropped NFTs, fake point claims, or fake event pages to induce users to click and authorize. Once a user mistakenly thinks they are just claiming a reward, they actually grant a malicious contract permission to transfer assets, which can then be stolen by the attacker.

Another example is attackers using Trojans, clipboard listeners, malicious browser extensions, or fake input interfaces to steal mnemonic phrases and transaction information. For users, the most dangerous aspect is that these attacks often don't happen on-chain but occur within their daily devices and operational habits.

The most concerning thing about these risks is that they attack habits, not code.

Many users don't fall victim because they don't know about security. They fall victim because they are too familiar with the operations. So familiar that they click "Confirm" as soon as they see it, copy addresses from their history, claim any airdrop they see, and follow any "customer support" reminder they receive. Attackers exploit this familiarity to hide risks within the most routine operational paths.

Therefore, when operating on-chain, especially when using DeFi, cross-chain bridges, trading tools, or new project pages, authorization management and transaction confirmation must become fundamental habits. Do not grant long-term, large-sum approvals to unfamiliar DApps. Do not enter mnemonic phrases on unfamiliar websites. Do not trust customer support DMs. Do not directly copy addresses from your history. Do not ignore wallet risk warnings.

Final Thoughts

Even though the market is so quiet, we still say this: cross-chain bridges are not unusable. DeFi is not un-participatable. New chains and new applications are not un-tryable.

We just need to understand that the richer the on-chain operations, the more complex the risk structure. In the past, when we talked about wallet security, the main point was often "don't leak your mnemonic phrase." That statement is certainly not wrong. But in the current practical context, it's definitely not enough:

Because today's security issues have expanded from "who can control your private key" to more dimensions – it's not just about safeguarding your mnemonic phrase, but also about connecting to DApps, authorizing contracts, signing transactions, cross-chain transfers, and cleaning up historical authorizations. So for ordinary users, the simplest security principle can be condensed into one sentence:

Don't confirm when you don't understand. Don't authorize when you're unsure. Don't transfer when you haven't checked.