Author: imToken

The chain seems to have never been so deserted, except for hackers.

If you look at the data statistics of SlowMist's "Hacked Archives", you will find that although the current market popularity has declined and the activity on the chain has dropped, hackers are still "conscientiously" launching attacks in the Web3 world. Among them, cross-chain bridges, DeFi protocols, wallet authorization, private key management and phishing attacks are still one of the most common targets of hackers.

If statistics are based on the relevant categories of SlowMist's "hacked archives", Web3 security incidents have caused cumulative losses of more than 900 million U.S. dollars since 2026, including more than 16 cross-chain bridge-related incidents, with losses of approximately 330 million U.S. dollars. Taking recent events as an example:

Gravity Bridge was suspected to have been attacked due to issues related to contract keys or signature authorization, and approximately $5.4 million in assets were stolen; the Alephium TokenBridge Ethereum cross-chain bridge also suffered a vulnerability attack, with approximately $815,000 in assets stolen in a short period of time, and a large amount of unendorsed Wrapped ALPH was minted.

This type of incident is not exactly the same as the "wallet theft" most commonly heard by ordinary users. In many cases, the user's mnemonic phrase is not leaked, and the wallet does not actively sign malicious transactions. However, if there is a problem with the cross-chain bridge's own verification mechanism, signature authority, or operational infrastructure, the assets on the bridge may still be affected.

This is also where the risks of cross-chain bridges are most easily overlooked.

1. Why are cross-chain bridges always the target of attacks?

When many users use a cross-chain bridge for the first time, they subconsciously understand that I am transferring assets from chain A to chain B.

But to be more precise, cross-chain usually does not mean that assets are actually "moved" from one chain to another, but that asset mapping, locking and recasting are completed through a set of bridging mechanisms. In short, the real role of the cross-chain bridge is not just a "channel", but more like an asset verification and accounting system between the two chains.

The problem is here too.

This means that if the signing key of the bridge is leaked, the attacker may forge legal authorization; if the number of Guardians is too small or the verification mechanism is bypassed, malicious cross-chain messages may be executed as real messages; if the contract permissions are not designed reasonably, the attacker may bypass the normal process and steal the locked assets, or cast mapped assets without real asset endorsement on the target chain.

What the user sees is just a click, but behind it involves contract permissions, signature mechanisms, message verification, asset custody, off-chain services and monitoring systems. Problems at any layer may expose assets to risks. To put it bluntly, The reason why cross-chain bridges are easy targets for attacks is not because there is a problem with the "cross-chain" requirement itself, but because it naturally concentrates three types of high-value permissions:

• First of all, cross-chain bridges often hold a large amount of locked assets, and many bridge assets correspond to real assets locked on the source chain. If a large amount of USDC, USDT, ETH or other highly liquid assets is deposited in the bridge contract, it will naturally become a key target for attackers;

• Secondly, the cross-chain bridge must solve the problem of "what happened on the other chain". Because the blockchain itself cannot naturally read the state of the other chain, the cross-chain bridge must rely on some kind of verification mechanism, such as verifier signatures or other relay systems. The more complex these mechanisms are, the greater the attack surface;

• Finally, it is difficult for ordinary users to directly judge the true security status of a bridge. Being able to open a cross-chain page does not mean that the bridge is in a safe status. Whether the signers of the bridge are safe, whether the contract permissions are reasonable, and whether the back-end service has been breached, it is difficult for users to directly tell from the front-end interface;

The Kelp DAO security incident that occurred not long ago has once again brought the relevant discussion to the forefront. Public review shows that such incidents do not necessarily come from code vulnerabilities in the smart contract itself, but may come from cross-chain verification configurations, off-chain infrastructure or operational security links.

In other words, the so-called "interoperability" between many L1, L2 and multi-chain applications today essentially still relies on a series of trusted relay, verification and signature mechanisms. Once these mechanisms are improperly configured or compromised, they may become the most vulnerable link in the entire system.

This is why cross-chain security cannot just rely on users to be "cautious", nor can it just rely on the protocol to "be audited once". It requires wallets, protocols, security teams, cross-chain infrastructure and users to jointly establish a more complete risk identification and protection mechanism.

2. Cross-chain does not mean that it cannot be used, but one more step of judgment is required

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

Multi-chain ecology has become a reality in Web3. Users need to transfer assets, use applications, participate in DeFi or manage positions between different networks. Cross-chain bridges are still an important infrastructure. What really needs to change is not to "no need to cross-chain at all", but to not treat cross-chain as an ordinary transfer.

Before cross-chain, users should at least make a few more steps of judgment.

First, confirm whether the entrance comes from official channels, and be especially careful not to enter cross-chain pages from community private messages, search ads, unfamiliar tutorials or links in comment areas. Especially right after a security incident, it is easy for attackers to take the opportunity to forge phishing websites such as "asset migration" and "emergency recovery" to induce people to connect wallets, authorize assets or enter mnemonic phrases.

Second, check whether the project team has issued an abnormal announcement. If a certain bridge has just been attacked, do not rush to continue cross-chain at this time, and do not blindly trade related wrapped assets, becauseAccording to historical experience, after many attacks occur, the risk will not be completely cleared at the first time. The attacker may still hold unendorsed assets, or use market liquidity to continue to obtain real assets.

Third, for small-amount testing, do not cross large amounts of assets at once, especially when using an unfamiliar bridge, an unfamiliar chain, or a new bridge that has just been launched. First use a small amount to confirm whether the path, arrival time, and target chain assets are normal. Although small-amount testing cannot completely eliminate risks, it can reduce large losses caused by path errors, false entrances, or asset identification problems.

Fourth, try to avoid unlimited authorization when authorizing. Currently, many cross-chain operations need to authorize tokens to the contract. If you only cross 100 USDT, try not to grant long-term authorization that is much higher than the actual amount used. After all, the larger the authorization amount, the higher the potential subsequent risk exposure. Especially those DApp authorizations that have not been used for a long time, have unknown sources, or have changed security status, should be checked and cleaned regularly.

Fifth, read the signature and transaction information carefully. Do not click confirm continuously because you are in a hurry. Especially when you see an unfamiliar website, an abnormal contract address, strange signature content, or a permission request that is inconsistent with your expected operation, you should stop the operation immediately.

In the end, when the cross-chain is completed, the security check should not end immediately. Many users may think that the cross-chain operation is over after the assets are received. But from a security perspective, post-cross-chain inspections are equally important:

• After completing the cross-chain, first use the block browser to check the transaction status of the source chain and the target chain respectively to confirm whether the assets have actually been transferred, instead of just looking at the front-end page display;

• At the same time, you must also confirm whether the assets received by the target chain are assets issued by official or trusted contracts. Do not trade tokens with the same name of unknown origin at will, and do not click on the website or claim portal associated with it just because an asset suddenly appears in your wallet;

• Finally, regularly check and clean up authorizations that are no longer used, because many authorizations will not expire automatically. If you have granted a higher amount of permission to a cross-chain bridge, DApp or contract, you may continue to retain risk exposure even if you no longer use it;

In the final analysis, security does not only occur at the moment of mnemonic word storage, but throughout the entire process of connecting DApps, authorizing tokens, signing transactions, cross-chain transfers, and subsequent cleanup.

3. What is more hidden than the bridge is that "people" are breached

The cross-chain bridge incident reminds us that the on-chain infrastructure itself may be risky. But from the perspective of ordinary users, another more common and more hidden type of risk comes from social engineering attacks.

So-called social engineering attacks do not necessarily rely on complex code vulnerabilities. Its core is to use people's habits, trust, anxiety and information asymmetry to allow users to complete dangerous operations by themselves.

In the past two years, phishing, private key theft, malicious authorization and disguised address fraud targeting users have become very frequent sources of risk in Web3 asset losses. This shows that hackers are not always obsessed with breaking the smart contract itself, but are increasingly turning to user operations and off-chain systems.

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

For example, attackers may induce users to click and authorize through dust attacks, airdrop NFTs, fake points collection, or fake event pages. Once the user mistakenly believes that he is only receiving rewards, he actually grants asset transfer permissions to the malicious contract, and subsequent assets may be transferred by the attacker.

For another example, attackers may steal mnemonic words and transaction information through Trojan viruses, clipboard monitoring, malicious browser plug-ins or disguised input interfaces. For users, the most dangerous thing is that these attacks often do not occur on the chain, but in daily equipment and operating habits.

The most alarming thing about this type of risk is that they attack not code, but habits.

Many users are not fooled because they don’t understand security, but because they are too familiar with the operation. Be familiar enough to click "Confirm" when you see it, copy the historical address when you see it, claim the airdrop when you see it, and follow the customer service reminder when you see it. Attackers take advantage of this sense of familiarity to hide risks in the most routine operations.

Therefore, when users operate on the chain, especially when using DeFi, cross-chain bridges, trading tools or new project pages, authorization management and transaction confirmation must become basic habits. Do not authorize large amounts for a long time to unfamiliar DApps, do not enter mnemonic phrases on unfamiliar websites, do not trust private message customer service, do not copy addresses directly from history records, and do not ignore the risk reminders that pop up in wallets.

Write at the end

Even if the market is so cold, we still have to say that it is not impossible to use cross-chain bridges, it is not impossible to participate in DeFi, and it is not impossible to try new chains and new applications.

What we need to understand is that the richer the operations on the chain, the more complex the risk structure. Just like when we talked about wallet security in the past, the focus was often "don't leak the mnemonic phrase." This sentence is certainly not wrong, but in the current actual context, it is definitely no longer enough:

Because today's security issues have further expanded from "who can control your private key" to more dimensions - not just keeping the mnemonic, but also when connecting DApps, authorizing contracts, signing transactions, cross-chain transfers and cleaning up historical authorizations, so for ordinary users, the simplest security principles can be condensed into one sentence:

Don’t confirm when you don’t understand, don’t authorize when you’re unsure, and don’t transfer money without checking.