Market cools, but hackers don’t stop: Why are cross-chain bridges always targeted?

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

If you look at the statistics from SlowMist's "Hacked Archive," you'll find that despite the current market downturn and decreased on-chain activity, hackers remain "diligently" launching attacks within the Web3 world. Among their targets, cross-chain bridges, DeFi protocols, wallet authorizations, private key management, and phishing attacks remain some of the most common directions.

According to the relevant classification statistics from SlowMist's "Hacked Archive," since 2026, Web3 security incidents have caused cumulative losses exceeding $900 million. Among these, there have been over 16 cross-chain bridge-related incidents, resulting in losses of approximately $330 million. For example, looking at recent incidents:

The 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 bridge also suffered a vulnerability attack, stealing about $815,000 in assets in a short time and causing a large number of unbacked Wrapped ALPH tokens to be minted.

These kinds of incidents differ from the "wallet theft" most commonly heard by regular users. Often, the user's seed phrase hasn't been leaked, and the wallet hasn't signed any malicious transactions. However, if issues arise with the bridge's verification mechanism, signature permissions, or operational infrastructure, the assets on the bridge can still be affected.

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

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

When many users first encounter a cross-chain bridge, they instinctively think, "I am transferring my assets from Chain A to Chain B."

More accurately, cross-chain activity usually doesn't involve physically "moving" assets from one chain to another. Instead, it relies on a bridging mechanism to lock assets on the source chain and mint mirrored tokens on the destination chain. In short, the true role of a cross-chain bridge is not just a "passageway," but rather an asset verification and accounting system sitting between two chains.

And there lies the problem.

This means if the bridge's signing key is compromised, attackers can forge legitimate authorizations. If the number of Guardian validators is too low or the verification mechanism is bypassed, a malicious cross-chain message could be executed as if it were legitimate. If contract permission designs are unreasonable, an attacker might bypass normal processes to steal locked assets or mint mirrored assets on the target chain without being backed by real assets.

What the user sees as a single click actually involves multiple layers: contract permissions, signature mechanisms, message verification, asset custody, off-chain services, and monitoring systems. A problem at any one of these layers can expose assets to risk. Simply put, the reason cross-chain bridges are frequent targets isn't inherent to the "cross-chain" concept itself, but because they naturally centralize three types of high-value permissions:

• First, cross-chain bridges often hold a large amount of locked assets. Behind many bridged assets lies real, locked assets on the source chain. If a bridge contract accumulates a significant amount of USDC, USDT, ETH, or other highly liquid assets, it naturally becomes a prime target for attackers.
• Second, bridges must solve the problem of "what's happening on the other chain." Blockchains cannot natively read the state of another chain, so a bridge must rely on some verification mechanism, such as multi-signature validators or relay systems. The more complex these mechanisms, the larger the attack surface.
• Finally, it's difficult for regular users to directly judge the real security state of a bridge. The fact that a cross-chain page loads successfully doesn't mean the bridge is secure. It's hard for users to know just from the frontend interface 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 brought this discussion back into the spotlight. Public post-mortems showed that such incidents don't necessarily stem from code vulnerabilities in the smart contracts themselves, but can arise from cross-chain verification configurations, off-chain infrastructure, or operational security procedures.

In other words, what many L1, L2, and multi-chain applications call "interoperability" today essentially relies on a series of trusted relay, verification, and signature mechanisms. If these mechanisms are misconfigured or breached, they can become the weakest link in the entire system.

This is why cross-chain security can't be solved just by users being "more cautious," nor just by protocols getting "one audit." It requires wallets, protocols, security teams, cross-chain infrastructure, and users to jointly build a more complete mechanism for risk identification and protection.

2. You Can Use Cross-Chain Bridges, But You Must Exercise More Caution

Objectively speaking, cross-chain bridges aren't unusable.

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

Before crossing chains, users should at least take a few extra steps to assess the situation.

First, confirm that the access point is an official channel. Pay extra attention not to enter the cross-chain page via community DMs, search ads, unfamiliar tutorials, or links in comments sections. Especially right after a security incident occurs, attackers are very likely to create phishing sites mimicking "asset migration" or "emergency recovery" tools to trick users into connecting wallets, authorizing assets, or entering seed phrases.

Second, check if the project has released an incident announcement. If a bridge has just been attacked, do not rush to use it or blindly trade the related wrapped assets. Past experience shows that risks are often not fully cleared immediately after an attack. Attackers may still hold unbacked assets or exploit market liquidity to extract more real assets.

Third, conduct a small test transaction. Never transfer large amounts in one go, especially when using an unfamiliar bridge, an unfamiliar chain, or a newly launched bridge. First, send a small amount to verify the path, the arrival time, and whether the assets received on the target chain are correct. While a small test can't eliminate all risks, it can reduce the potential for large losses due to incorrect paths, fake portals, or asset identification issues.

Fourth, avoid infinite approvals whenever possible. Many cross-chain operations require users to approve tokens for the contract beforehand. If you only need to bridge 100 USDT, try not to grant a long-term approval with limits far higher than necessary. The larger the approval limit, the greater the potential risk exposure, especially for DApps you no longer use, those from unknown sources, or those whose security status has changed. It's better to regularly check and clean up such approvals.

Fifth, carefully read signature and transaction information. Don't just click "Confirm" out of haste. Stop immediately if you see an unfamiliar website, an unusual contract address, strange signature content, or permission requests that don't match your intended operation.

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

• After completing the cross-chain transfer, first use a block explorer to check the transaction status on both the source chain and the target chain to confirm the assets have truly been transferred, rather than just relying on what the frontend page shows.
• Simultaneously, confirm whether the assets received on the target chain are issued by the official contract or a trusted contract. Do not randomly trade tokens with the same name from dubious sources. Furthermore, just because an asset suddenly appears in your wallet, don't click on its associated website or claim portal.
• Finally, regularly check and revoke unused approvals. Many approvals don't expire automatically. If you previously granted a high allowance to a cross-chain bridge, DApp, or contract, the risk exposure persists even if you no longer use them.

Ultimately, security isn't just about safeguarding your seed phrase at a single moment; it's a continuous process that runs through connecting to DApps, approving tokens, signing transactions, performing cross-chain transfers, and subsequent clean-up.

3. More Insidious Than the Bridge is the "Human" Factor Being Exploited

Incidents involving cross-chain bridges remind us of potential risks within the on-chain infrastructure itself. However, from a regular user's perspective, another more common and insidious risk comes from social engineering attacks.

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

Over the past two years, phishing attacks targeting users, private key thefts, malicious authorizations, and address poisoning scams have become very high-frequency sources of asset loss in Web3. This indicates that hackers aren't always fixated on breaking smart contracts themselves, but are increasingly turning their focus towards user operations and off-chain systems.

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

For example, attackers might use dusting attacks, airdropping NFTs, fake reward claims, or fraudulent event pages to trick users into clicking and granting authorizations. When a user mistakenly thinks they are just claiming a reward, they might actually be granting a malicious contract permission to transfer their assets, which are subsequently stolen.

Another example is using trojans, clipboard hacks, malicious browser extensions, or fake input interfaces to steal seed phrases and transaction information. For users, the most dangerous aspect is that these attacks often don't occur on-chain, but within the everyday devices and habits of the user.

The most worrying thing about this type of risk is that it attacks not code, but habits.

Many users fall victim not because they don't understand security, but because they are too familiar with the operations. So familiar that they click "Confirm" without thinking, copy addresses from history, claim airdrops without verifying, or follow instructions from a customer support DM. Attackers exploit this familiarity, hiding the risk within the most routinized operational paths.

Therefore, when operating on-chain, especially when using DeFi protocols, cross-chain bridges, trading tools, or new project pages, managing approvals and verifying transactions must become fundamental habits. Do not grant large, long-term approvals to unfamiliar DApps. Do not enter your seed phrase on unknown websites. Do not trust customer support DMs. Do not directly copy addresses from transaction history. Do not ignore risk warnings from your wallet.

Final Thoughts

Even with the market being so cold, we must still say: cross-chain bridges are usable, DeFi is participable, and new chains and applications are tryable.

However, we need to understand that the more extensive your on-chain activities, the more complex the risk structure becomes. Just as we used to talk about wallet security, the main point was "don't leak your seed phrase." While this statement is certainly not wrong, in the current practical context, it is definitely insufficient:

Because security issues today have expanded from "who controls your private key" to multiple dimensions. It's not just about keeping your seed phrase safe, but also about securing your actions when connecting to DApps, approving contracts, signing transactions, transferring across chains, and cleaning up old approvals. For regular users, the simplest security principle can be summed up in one sentence:

Do not confirm what you don't understand. Do not authorize what you're unsure about. Do not transfer what you haven't verified.