ไม่เพียงแต่คีย์ส่วนตัว: จากกระเป๋าเงิน L2 ไปจนถึงซัพพลายเชน วิธีปกป้องขอบเขตความปลอดภัยของ Web3

In the past June, the crypto world experienced a round of security incidents spanning multiple attack vectors.

The latest monthly security report released by PeckShield shows that there were 40 major hacking incidents in June, with total losses reaching $75.87 million. What is more concerning is that these attacks were not concentrated on a single attack path. Instead, they covered wallet signature implementation flaws, L2 protocol vulnerabilities, and third-party service supply chain attacks, with multiple lines of defense breached within the same month.

As Web3 security risks expand from a single entry point to the entire on-chain interaction pathway, every user has to rethink one question: Are my crypto assets actually still safe?

I. Beyond Private Keys: The Importance of Wallet's Underlying Signature Implementation

The security incident on SecondFi, a Cardano ecosystem wallet in June, is the most direct example.

SecondFi is the successor to the Cardano ecosystem wallet Yoroi. Between June 21 and 23, the attacker transferred approximately 16 million ADA (worth about $2.4 million at the time) from some SecondFi user addresses, involving around 374 wallets. SecondFi later stated that emergency measures protected another approximately 129 million ADA that could have been affected.

The most unique aspect of this incident is that affected users did not actively hand over their seed phrases to the attacker. The problem was in the wallet's underlying signature implementation. According to analysis by the security firm BlockSec, the wallet erroneously derived the signature nonce from public transaction messages, omitting the secret nonce prefix required by the standard implementation.

This meant that every time a user signed a transaction using the affected wallet version, the public signature data published on-chain would expose enough information to derive the private key of the address. Therefore, the attacker did not need to hack the user's phone or obtain the seed phrase. They only needed to analyze public on-chain data to potentially recover the signing private key for the corresponding address.

From the user's perspective, the wallet was functioning normally. The seed phrase wasn't exposed in a pop-up, the password wasn't cracked, and the transaction was indeed initiated by the user. However, from a cryptographic standpoint, as long as the user's address had generated some valid signatures through the affected version, the public transaction and signature data could help the attacker derive the address's signing private key.

Ultimately, wallet security depends on whether private keys are generated correctly, whether the signing process strictly adheres to cryptographic standards, and whether these critical code components can be externally reviewed and verified. This is precisely why keeping core wallet components open-source is so important.

Of course, this is an implementation flaw in a specific version of a specific wallet, not a universal problem for all self-custodial wallets. Taking imToken's TokenCore as an example, its core code repository is publicly hosted on GitHub, covering underlying wallet functions like key management, address derivation, and transaction signing.

While open-sourcing code doesn't guarantee it's free of vulnerabilities, nor does it mean users can completely let their guard down, for the most sensitive cryptographic and signing components in a wallet, open-sourcing at least provides a crucial prerequisite: security researchers, developers, and the community can inspect the code, reproduce issues, and continuously test it, rather than having to trust an unverifiable black box.

For average users, such incidents also translate into several practical security principles.

• First, wallets should always be downloaded from official websites or official app stores, and updated to secure versions promptly.
• Second, it's inadvisable to keep all assets in a single, daily-use wallet. Large, long-term holdings should be stored using hardware wallets or independent cold wallets, isolated from hot wallets frequently connected to DApps.
• More importantly, once a wallet provider confirms a vulnerability at the key generation or signature implementation level, simply importing the original seed phrase into another wallet usually does NOT solve the problem.

This is because importing the same seed phrase into another wallet does not change the already exposed addresses and private keys. Affected assets need to be transferred to a new address that has never been signed using the vulnerable version. For average users, the safer approach is usually to follow the official emergency procedure to create a completely new set of wallets and seed phrases, and then migrate the assets, rather than repeatedly importing or operating on the original addresses themselves.

II. L2 is Not Just 'Cheaper Ethereum'; It's a Complex Chain of Trust

Beyond wallets, multiple incidents in June also pointed risks towards increasingly complex L2 systems.

On June 14 and 18, two legacy Rollup deployments related to Aztec were attacked, resulting in combined losses of approximately $4.35 million.

It is important to note that the attacks targeted legacy deployments like Aztec Connect, which are in a deprecated state. This does not equate to an attack on the current Aztec Network mainnet itself. However, the issues exposed by these two incidents serve as a significant warning for the entire ZK Rollup field.

In one incident, the attacker exploited an inconsistency between the transaction count and the actual processed data, allowing the system to register a deposit within the proof while bypassing the corresponding balance deduction process on L1.

The other incident stemmed from a missing constraint in the zero-knowledge proof circuit. The system verified a proof that was formally valid, but failed to ensure that the private state tree used in the proof was entirely consistent with the public state root on Ethereum used for actual settlement. This allowed the attacker to generate a proof around a forged state tree and withdraw assets from the L1 contract.

Such problems are difficult to summarize with the traditional question of "does the contract have a single line of vulnerable code?". After all, a zero-knowledge proof can prove that a computation process follows established rules, but only if the rules themselves are correct and complete. If a developer forgets to constrain a key variable, the proof can still be mathematically valid, yet prove a result inconsistent with the actual settlement state.

The subsequent security incident involving Taiko revealed a different kind of L2 trust chain risk.

On June 22, Taiko's SGX-based proof verification process was exploited, resulting in losses of approximately $1.7 million. According to BlockSec's analysis, the attacker used an SGX enclave signing private key that had been previously committed to a public GitHub repository. Simultaneously, they exploited a flaw in the on-chain verification contract that did not reject DEBUG mode Enclaves, registering a malicious prover as a legitimate instance.

The attacker then forged an L2 state proof, causing the contract on Ethereum to accept a non-existent L2 state, ultimately extracting funds from the bridge. In essence, because the key used to sign the trusted execution environment was public, and the remote attestation rules did not fully check the runtime environment attributes, a 'certified' proof lost its intended meaning of trustworthiness.

Concurrently, Base experienced a halt in mainnet block production from June 25 to 26. In its post-mortem, Base stated that both interruptions stemmed from the same block-building logic flaw: a failed transaction did not properly clean up previously recorded state, causing subsequent transactions to be miscounted for gas and generating a block containing an invalid state transition. Since other nodes could not accept this block, the network eventually stopped progressing. Base stated that the chain's integrity was not compromised during the incident and user funds were always safe.

This was not an asset theft or external attack, but a technical failure affecting network availability and recoverability. From a broader security perspective, however, availability itself is part of an L2's security model.

Because for users, whether a chain is secure depends not only on whether hackers can forge assets, but also on whether blocks can be produced consistently, whether bridges function correctly, whether nodes can recover quickly, and whether users still have viable exit paths when the system fails.

Therefore, when users choose an L2, they should not only compare fees and airdrop expectations. For smaller, newly launched L2s, or those with rapidly changing security mechanisms, it's best to avoid storing large amounts of assets beyond immediate needs. Before bridging, confirm you are using the official bridge and understand the withdrawal times, pause mechanisms, and emergency exit procedures. If the network stops producing blocks, cross-chain operations are abnormal, or the project issues a security warning, do not repeatedly submit transactions or continue bridging assets.

A more prudent approach is to diversify assets based on their purpose and risk level, rather than placing all liquidity into a single L2, a single bridge, or a single exit mechanism.

III. Smart Contracts Not Breached, But Third-Party Services Can Bring Attacks to Users

If the issues with wallets and L2s still occur within relatively low-level technical components, the Polymarket incident shows that the web frontend, the closest layer to the user, can also become an entry point for fund loss.

On June 25, Polymarket stated that one of its third-party vendors was compromised, allowing an attacker to inject malicious scripts into the Polymarket frontend accessed by some users.

According to statistics from security firms and on-chain analysts, the incident resulted in approximately $3 million in user asset losses, involving about 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and exchanged for approximately 1893 ETH. However, Polymarket later stated that the affected dependency was removed, and it would provide full refunds to affected users.

The key to this incident is that users likely accessed the correct Polymarket domain. Current disclosures do not point to a vulnerability in Polymarket's core smart contracts. The problem was primarily in the third-party frontend dependency loaded by the webpage.

This serves as a mirror. Today, most Web3 applications are not entirely on-chain. The web pages users see, such as trading interfaces, still rely heavily on traditional internet infrastructure and third-party software packages. If any one of these dependencies is attacked, a legitimate website could display incorrect information to users, alter withdrawal addresses, or trick wallets into signing malicious transactions.

Therefore, 'the URL is real' does not automatically mean 'all the code loaded right now is safe', and 'the contract passed an audit' does not mean the entire interaction path between the user and the contract is risk-free. Facing such frontend and supply chain attacks, average users struggle to independently inspect every piece of code loaded on a webpage. However, they can still limit potential losses by reducing permissions for individual interactions:

• Use a dedicated DApp interaction wallet: Avoid connecting long-term savings wallets directly to various DeFi, NFT, prediction market, and airdrop sites. Only keep funds intended for near-term use in your daily interaction wallet. Even if the frontend or token approvals are compromised, the impact range is limited.
• Focus on the actual action during signing, not just the webpage button: Just because a webpage says "Login", "Claim", or "Confirm Order" doesn't mean the pop-up in your wallet is for the same action.
• When a webpage behaves abnormally, stop and verify: If the page suddenly asks you to re-import your seed phrase, download an extra plugin, or displays transaction details inconsistent with the webpage description, pause the interaction. Confirm the situation through multiple official channels of the project and check or revoke unused historical token approvals.

From a wallet product perspective, this also means the role of the wallet is changing.

It should not just be a tool for storing private keys and popping up a signing window. It also needs to help users understand transaction intents as much as possible, identify abnormal approvals, display asset changes, and provide sufficiently clear warnings before high-risk interactions occur.

However, wallets cannot eliminate all risks for users. A more realistic security model involves wallets, protocols, L2s, third-party service providers, and users working together to reduce the attack surface, rather than placing the entire responsibility on any single party.

Final Thoughts

In the past, it was often said: Whoever holds the private key controls the on-chain assets.

This statement remains true but does not cover the entire journey of a user's assets from 'forming the intent to transact' to 'completing on-chain settlement'. Today's Web3 security is no longer just about protecting a set of seed phrases. It's about protecting the entire pathway from key generation, transaction display, and signature execution, to network verification and final settlement.

Of course, this doesn't mean users should avoid all on-chain interactions. For users, truly effective security habits mean managing assets based on their purpose, risk level, and interaction context: Heavy isolation for long-term assets, small amounts for daily interactions, low approvals for unfamiliar DApps, and multiple verifications for high-risk operations.

After all, when security risks expand from a point to a chain, the user's defense must also upgrade from simply protecting the private key to a complete set of habits.

Let's work together towards this goal.