Web3 Security Risks Expand: Wallets, L2s, and Supply Chain Vulnerabilities in June

In the just-concluded month of June, the crypto world experienced a series of security incidents spanning multiple areas.

PeckShield's latest monthly security report reveals that 40 major hacking incidents occurred in June, resulting in total losses of $75.87 million. More concerning is that these attacks were not concentrated on a single attack vector but instead targeted multiple fronts simultaneously, including wallet signature implementation flaws, L2 protocol vulnerabilities, and third-party service supply chain compromises—multiple defenses were breached within the same month.

As Web3 security risks expand from a single entry point to the entire on-chain interaction path, every user must reconsider a critical question: Are my crypto assets still safe?

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

SecondFi was formerly the Cardano ecosystem wallet Yoroi. Between June 21 and 23, attackers transferred approximately 16 million ADA from the addresses of some SecondFi users, affecting around 374 wallets, equivalent to about $2.4 million at the time of the incident. SecondFi subsequently stated that, through emergency measures, an additional 129 million ADA that may have been at risk were further protected.

What makes this incident particularly unusual is that affected users did not voluntarily provide their mnemonic phrases to the attackers; the issue stemmed from a flaw in the wallet’s underlying signature implementation. According to analysis by the security firm BlockSec, the system incorrectly derived the signature nonce from publicly available transaction messages, omitting the secret nonce prefix required by standard implementations.

This means that whenever a user signs a transaction using the affected wallet version, the public signature data published on the chain exposes sufficient information to derive the private key of the address. As a result, attackers do not need to compromise the user’s device or obtain the mnemonic phrase—only analyze the public on-chain data to potentially recover the signing private key for the corresponding address.

From the user’s perspective, the wallet still appears to be functioning normally—since the mnemonic phrase was not exposed via a pop-up, the password was not cracked, and all transactions were indeed initiated by the user themselves. However, from a cryptographic standpoint, if any valid signatures were generated using the affected version of the wallet, the publicly available transaction and signature data could potentially enable attackers to derive the private key associated with that address.

Ultimately, wallet security depends on whether the private key is generated correctly, whether signatures are completed strictly according to cryptographic standards, and whether these critical components can be externally reviewed and verified—this is why keeping core wallet components open source is essential.

This is an implementation flaw specific to this wallet and version, not a universal issue with all self-custody wallets. For example, imToken's TokenCore has its core codebase publicly hosted on GitHub, covering fundamental wallet functions such as key management, address derivation, and transaction signing.

While open source does not guarantee the absence of vulnerabilities, nor does it mean users can completely let down their guard, for the most sensitive cryptographic and signing components in a wallet, open source at least provides a crucial foundation: it allows security researchers, developers, and the community to examine the code, reproduce issues, and continuously test it—rather than being forced to trust an unverifiable black box.

For regular users, such incidents also correspond to several more practical security principles.

• First, wallets should always be downloaded from the official website or official app store, and security updates should be installed promptly;
• Second, avoid keeping all your assets in a single everyday interaction wallet. Large or long-term holdings should be stored in a hardware wallet or a separate cold wallet, isolated from hot wallets that frequently connect to dApps.
• More importantly, if the wallet officially confirms a vulnerability at the level of key generation or signature implementation, simply importing the original mnemonic phrase into another wallet usually will not resolve the issue;

Because importing the same mnemonic phrase into another wallet does not change the previously exposed addresses or private keys, affected assets must be transferred to a new address that has never been signed using the vulnerable version. For regular users, the safer approach is typically to follow the official emergency procedure by creating a completely new wallet and mnemonic phrase, then migrating assets, rather than repeatedly importing or operating on existing addresses.

In addition to wallets, several events in June pointed to increasing risks associated with increasingly complex L2 systems.

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

It should be noted that the attacks targeted older deployments, such as Aztec Connect, which have already been deprecated—not the current Aztec Network mainnet itself. However, the issues exposed in both incidents serve as a significant warning for the entire ZK Rollup ecosystem.

In one incident, the attacker exploited an inconsistency between the number of transactions and the actual processed data, causing the system to register a deposit internally while bypassing the corresponding balance deduction process on L1.

Another incident stemmed from a missing constraint in the zero-knowledge proof circuit, causing the system to validate a formally valid proof without ensuring that the private state tree used in the proof exactly matched the public state root actually used for settlement on Ethereum. This allowed attackers to generate proofs based on a forged state tree and extract assets from the L1 contract.

This type of issue cannot be easily summarized by the traditional notion of “whether a contract contains a line of vulnerable code.” After all, zero-knowledge proofs can verify that a computation adheres to predefined rules, but only if those rules themselves are correct and complete. If a developer forgets to constrain a critical variable, the proof may still be mathematically valid—yet it could validate a result inconsistent with the actual settlement state.

The subsequent security incident on Taiko exposed another risk in the L2 trust chain.

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

The attacker then forged an L2 state proof, causing a contract on Ethereum to accept a non-existent L2 state, ultimately withdrawing assets from the bridge funds. This occurred because the key used to sign the trusted execution environment was exposed, and the remote attestation rules failed to fully verify the runtime environment's properties, rendering the "attested" proof no longer trustworthy.

Meanwhile, Base experienced consecutive mainnet block production halts on June 25–26. In its post-incident review, Base stated that both interruptions stemmed from the same flaw in block construction logic: a failed transaction did not properly clean up its prior state records, causing subsequent transactions to miscalculate gas and generate blocks containing invalid state transitions. Since other nodes rejected these blocks, the network ultimately halted. Base emphasized that the chain’s integrity was not compromised during the incident and user funds remained secure at all times.

This was not an asset theft or external attack, but a technical failure affecting network availability and resilience. However, from a broader security perspective, availability is itself part of the L2 security model.

For users, the security of a chain depends not only on whether hackers can forge assets, but also on whether blocks can be continuously produced, cross-chain bridges can function properly, nodes can recover quickly, and users still have viable exit options in case of system failures.

Therefore, when using L2s, users should not only compare fees and airdrop expectations. For smaller, newly launched L2s or those with rapidly evolving security mechanisms, avoid storing large amounts of assets beyond your actual usage needs for extended periods; before bridging, confirm you are using the official bridge and understand withdrawal times, suspension mechanisms, and emergency exit procedures; if the network stops producing blocks, experiences bridging anomalies, or receives an official security alert, do not repeatedly submit transactions or continue bridging assets.

A more prudent approach is to diversify the management of assets based on their different purposes and risk levels, rather than concentrating all liquidity on a single L2, one cross-chain bridge, or one exit mechanism.

While wallet and L2 issues still stem from lower-level technical components, the Polymarket incident demonstrates that the web frontend closest to users can also serve as an entry point for funds.

On June 25, Polymarket stated that a third-party vendor it uses was compromised, allowing attackers to inject malicious scripts into the Polymarket frontend accessed by some users.

According to statistics from security agencies and on-chain analysts, the incident resulted in approximately $3 million in user asset losses, affecting around 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and exchanged for approximately 1,893 ETH. However, Polymarket later stated that it has removed the affected dependencies and will issue full refunds to affected users.

The key point of this incident is that users may still have been accessing the correct Polymarket domain, and current disclosures do not indicate a vulnerability in Polymarket’s core smart contracts—the issue primarily lies in third-party frontend dependencies loaded on the webpage.

This is also a mirror: today, most Web3 applications are not fully chain-based; the web pages users see, such as transaction interfaces, still heavily rely on traditional internet infrastructure and third-party software packages. If any of these dependencies is compromised, a legitimate website could display incorrect information to users, replace payment addresses, or trick wallets into signing malicious transactions.

Therefore, "the website is legitimate" does not necessarily mean "all code loaded at this moment is secure," and "the contract has been audited" does not mean there is no risk along the entire interaction path between the user and the contract. Facing such frontend and supply chain attacks, ordinary users find it difficult to independently verify every piece of code loaded on the webpage, but they can still reduce potential losses by limiting the permissions granted in each interaction:

• Use a separate DApp interaction wallet: Avoid directly connecting your long-term savings wallet to various DeFi, NFT, prediction market, and airdrop websites. Keep only funds you plan to use soon in your daily interaction wallet, so that even if the frontend or approvals are compromised, the impact remains limited.
• Before signing, pay attention to the actual action being performed, not just the button text on the webpage: a button labeled "Login," "Claim," or "Confirm Order" on the website does not mean the signature request in your wallet represents the same action;
• When encountering anomalies on the website, do not continue operating out of habit: if the page suddenly requests you to re-import your mnemonic phrase, download additional plugins, or displays transaction details inconsistent with the website’s description, pause interaction immediately. Verify the situation through multiple official channels of the project, and review or revoke historical authorizations you no longer use.

From a wallet product perspective, this also means the role wallets play is evolving.

It should not merely be a tool for storing private keys and popping up signature windows; it should also help users understand transaction intent, identify unusual authorizations, display asset changes, and provide clear warnings before high-risk interactions occur.

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

In the past, it was commonly said that whoever controls the private key controls the on-chain assets.

This statement still holds true, but it does not cover the entire process from when a user generates a transaction intent to when on-chain settlement is completed. Today’s Web3 security is no longer just about protecting a set of seed phrases—it’s about securing the entire journey, from wallet key generation and transaction display to signature execution, network verification, and final settlement.

Of course, this doesn't mean users should avoid all on-chain interactions entirely. Effective security practices for users involve separating asset usage, risk levels, and interaction scenarios: keep long-term assets highly isolated, use small amounts for daily interactions, grant minimal permissions to unfamiliar dApps, and require multiple verifications for high-risk actions.

After all, when security risks expand from a single point to an entire chain, user defense must evolve from simply safeguarding private keys to adopting a comprehensive set of habits.

Let’s encourage each other.