Market may have cooled down, but hackers haven't stopped. Why are cross-chain bridges always in the crosshairs?

The on-chain space has rarely felt this quiet, except for the hackers.

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

According to related statistics from SlowMist's "Hacked Archive," since 2026, Web3 security incidents have caused cumulative losses exceeding $900 million, including over 16 incidents related to cross-chain bridges, with losses of approximately $330 million. Take recent events as examples:

Gravity Bridge was reportedly attacked due to issues with contract keys or signature authorizations, resulting in the theft of approximately $5.4 million in assets. Alephium's TokenBridge Ethereum bridge also suffered a vulnerability attack, with around $815,000 in assets stolen in a short period and a large number of unbacked Wrapped ALPH tokens minted.

These types of incidents are not exactly the same as the "wallet thefts" most commonly heard by ordinary users. Often, the user's seed phrase hasn't been leaked, and their wallet hasn't signed any malicious transactions. However, if the bridge's validation mechanism, signing permissions, or operational infrastructure has issues, 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 Targets?

Many users, when first using a cross-chain bridge, instinctively think they are transferring assets from chain A to chain B.

But more accurately, cross-chain transfers usually don't mean the asset actually "moves" from one chain to another. Instead, they complete an asset mapping, locking, and re-minting process through a bridging mechanism. 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.

That's where the problem lies.

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

What the user sees is just one click, but behind it involves multiple layers including contract permissions, signature mechanisms, message verification, asset custody, off-chain services, and monitoring systems. A flaw in any layer can expose assets to risk. Simply put, cross-chain bridges are frequent targets not because the "cross-chain" need itself is flawed, but because they inherently 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 significant amounts 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." Since a blockchain cannot natively read the state of another chain, the bridge must rely on some verification mechanism, such as validator signatures or other relay systems. The more complex these mechanisms are, the larger the attack surface.
• Finally, it's difficult for ordinary users to directly assess the true security state of a bridge. Just because a cross-chain page loads doesn't mean the bridge is secure. Whether the bridge's signers are secure, the contract permissions are reasonable, or the backend services are compromised is not easily apparent from the frontend interface.

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

In other words, the so-called "interoperability" between many L1s, L2s, and multi-chain applications today still fundamentally relies on a set of trusted relay, verification, and signing mechanisms. If 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 protocols being "audited once." It requires wallets, protocols, security teams, cross-chain infrastructure, and users to jointly establish a more comprehensive mechanism for risk identification and protection.

2. Cross-Chain Isn't Unusable, But Requires an Extra Step of Judgment

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

The multi-chain ecosystem is a reality of Web3. Users need to transfer assets, use applications, participate in DeFi, or manage positions across different networks. Cross-chain bridges remain essential infrastructure. What truly needs to change is not "avoiding cross-chain entirely," but rather not treating a cross-chain transaction like a simple transfer.

Before crossing chains, users should take a few extra steps to judge.

First, confirm the entry point is from an official source. Be especially careful not to enter a cross-chain page via direct messages in communities, search ads, unfamiliar tutorials, or links in comment sections. Especially right after a security incident, attackers are likely to set up phishing sites mimicking "asset migration" or "emergency recovery" to trick users into connecting wallets, authorizing assets, or entering seed phrases.

Second, check if the project has released an anomaly announcement. If a bridge has just been attacked, don't rush to use it for transfers or blindly trade related wrapped assets. Past experience shows that after many attacks, the risk isn't immediately cleared. Attackers might still hold unbacked assets or exploit market liquidity to extract real assets.

Third, test with a small amount. Don't transfer large sums at once, 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 the status of the target chain's assets. While a small test cannot eliminate all risks, it can reduce the chance of large losses due to path errors, fake entry points, or asset identification issues.

Fourth, avoid giving unlimited approvals when possible. Most cross-chain operations require approving tokens for a contract. If you're just bridging 100 USDT, try not to grant a long-term approval for an amount far exceeding the actual usage. A higher approval limit means a larger potential exposure to risk, especially for DApp approvals that are no longer used, are 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 rush and click confirm blindly. Especially if you see an unfamiliar website, an unusual contract address, strange signature content, or permission requests that don't match your intended operation, stop immediately.

Finally, security checks shouldn't end immediately after the cross-chain transaction is complete. Many users think the process is over once the assets arrive. However, from a security perspective, post-cross-chain checks are equally important:

• After completing the bridge, first use a block explorer to check the transaction status on both the source and target chains. Confirm the assets have truly been transferred, rather than just relying on the frontend display.
• Simultaneously, verify that the assets received on the target chain are issued by official or trusted contracts. Don't trade tokens with the same name from unknown sources, and don't click on associated websites or claim portals just because a new asset suddenly appears in your wallet.
• Finally, regularly check and revoke approvals that are no longer in use. Many approvals don't auto-expire. If you've previously granted high approval limits to a bridge, DApp, or contract, ceasing to use them doesn't automatically remove the risk exposure.

Ultimately, security isn't just about the moment you safeguard your seed phrase. It's a complete process that runs through connecting to DApps, approving tokens, signing transactions, bridging assets, and subsequent cleanup.

3. More Insidious Than the Bridge: The "Human" Element Compromised

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

So-called social engineering attacks don't necessarily rely on complex code vulnerabilities. Their core is exploiting human habits, trust, anxiety, and information asymmetry to trick users into performing dangerous operations themselves.

In recent years, phishing attacks, private key theft, malicious approvals, and address spoofing scams targeting users have become very high-frequency sources of Web3 asset loss. This indicates that hackers aren't always fixated on breaching the smart contract itself, but are increasingly turning their focus towards user operations and off-chain systems.

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

For example, attackers might use dust attacks, airdropped NFTs, fake point claims, or fake event pages to lure users into clicking and granting approvals. Once a user mistakenly thinks they are just claiming a reward, they might actually authorize a malicious contract to transfer their assets, which can later be stolen by the attacker.

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

The most concerning part of this type of risk is that it attacks habits, not code.

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, and follow customer service prompts without question. Attackers exploit this familiarity, hiding 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, managing approvals and confirming transactions must become fundamental habits. Don't grant long-term, large approvals to unfamiliar DApps. Don't enter seed phrases on unknown websites. Don't trust direct message "customer support." Don't blindly copy addresses from transaction history. Don't ignore risk warnings popped up by your wallet.

In Conclusion

Even with the market so sluggish, we still say that cross-chain bridges are not unusable, DeFi is not unplayable, and new chains and applications are not untryable.

But we need to understand that the richer the on-chain operations, the more complex the risk structure. Just as in the past, wallet security discussions focused on "don't leak your seed phrase." While not wrong, in the current context, that advice is certainly no longer sufficient:

Today's security issues have expanded beyond "who controls your private key" to many more dimensions. It's not just about safekeeping your seed phrase, but also about connecting to DApps, approving contracts, signing transactions, bridging assets, and cleaning up historical approvals. So, for ordinary users, the simplest security principle can be condensed into one sentence:

Don't confirm what you don't understand. Don't approve when you're uncertain. Don't transfer without verification.