The Battlefield of Crypto Security Has Changed: From Vulnerability Economy to Permission Economy

Over the past decade, the Web3 security industry has been patching smart contracts, fixing vulnerabilities, and conducting audits. Now, attackers are bypassing the code and directly targeting the "trust chain" itself.

Written by: Fu Gui

On September 24, 2026, Bitget's hot and warm wallets lost approximately $387.5 million, just a few days ago. After breaching the backend system, attackers injected fake transaction data, triggering the exchange's own approval process. The CEO later stated in an announcement: "Our system approved the transfer." No private keys were leaked, and the cold wallet remained untouched.

Five months earlier, on April 18, 2026, KelpDAO minted approximately $290 million worth of rsETH out of thin air due to altered data from an RPC node. Not a single line of the contract was written incorrectly. The attackers obtained the RPC list relied upon by LayerZero DVN, compromised two independent clusters, and replaced op-geth with a malicious version. The malicious node returned fake data only to DVN's IP while providing real data to monitoring tools, then used DDoS attacks to force the system to failover to the contaminated node. DVN confirmed a transaction that never occurred, and the bridge released 116,500 rsETH without any real burn.

Two weeks earlier, on April 1, 2026, a member of the security committee of the Drift protocol pre-signed a blank transaction, and approximately $285 million was drained in just twelve minutes. The attackers impersonated a quantitative institution, dined with core contributors at international conferences, and even deposited over a million dollars into the Ecosystem Vault. Once trust was established, they coaxed the member into signing a seemingly harmless management transaction—hiding the transfer of management rights using Solana's durable nonce. Drift had just changed its multi-signature to zero delay, removing the timelock, leaving no time for reconsideration.

These three incidents alone total less than one billion dollars, all occurring in the past year. Looking back a year earlier, on February 21, 2025, Bybit's cold wallet transferred approximately $1.45 billion, marking the largest publicly acknowledged theft in cryptocurrency history. The attackers did not crack Ethereum's cryptography, find bugs in the Safe multi-signature contract, or even directly touch the private keys. They compromised the machines of Safe{Wallet} developers and injected a piece of JavaScript into the signing interface. The three signers saw a routine operation of "transferring from cold wallet to hot wallet" on their screens and clicked confirm.

In total, these four incidents amount to over $2.4 billion. None of these cases utilized undiscovered 0days in the contracts. The code was audited, formal verification was done, multi-signatures were set up, and cold wallets were separated, yet the money still vanished.

Some say security improved in 2026. The entire industry lost between $956 million and $1.39 billion in the first half of the year, half of last year's losses. However, excluding the anomalous $1.45 billion from 2025, the figures calculated by CertiK show a year-on-year increase of 28%, and SlowMist's statistics indicate a 50% rise in the number of incidents. The median loss per incident increased by 60.6%, reaching $169,000. The numbers look good only because there hasn't been another major case recorded in history this year, not because the thieves have stopped. The number of thieves has increased, becoming more dispersed, and each theft has become more costly.

We have been replacing the steel plates of our security doors with thicker ones, but the thieves have already climbed through the windows.

Beyond Signatures

Cryptography can ensure that others cannot forge my signature, but it cannot guarantee why I signed this transaction.

In the first half of 2026, 33 wallets were compromised, losing $445 million. 204 code vulnerabilities resulted in losses of $152 million. The numbers clearly show that breaching people is more profitable than breaching code. Hacken's Q2 report is even more direct: 88% of losses came from operational-level breaches, while smart contract vulnerabilities accounted for only 11%. Among 67 incidents, 44 involved contract vulnerabilities, but they collectively caused less than 10% of the losses.

The Drift case is the most typical. The attackers spent six months building trust, ultimately coaxing a member of the security committee into signing a seemingly harmless management transaction. This transaction utilized Solana's durable nonce mechanism, essentially a signed blank check that could be cashed at any time. In just 12 minutes, 31 withdrawals occurred, draining over half of the locked assets.

North Korea's Lazarus has turned this into a production line. They create fake resumes, set up fake companies, and all LinkedIn profiles are real. They submit resumes to target companies, gain SSO and VPN access, and lie in wait for months, gradually moving to the signing machines. SlowMist calculated that North Korean groups stole a total of $2.837 billion from January 2024 to September 2025, with $2.02 billion stolen in 2025 alone, accounting for 76% of service provider losses. They recovered only 13.2%. For the Bybit incident, only $35.4 million was frozen after a year.

They do not look for code vulnerabilities; they look for people who can sign. Finding a person is cheaper than finding a bug.

The Boundaries of Chain

The blockchain itself has not been hacked; the surrounding elements of the blockchain have been compromised.

KelpDAO's contract was not written incorrectly. This is the first historical case where fake data returned by an RPC node directly led to significant losses. It exposes a truth that everyone knows but no one takes seriously: so-called decentralized applications primarily rely on two or three cloud vendors and RPC service providers for reading data. MetaMask defaults to Infura, DApps' backends use Alchemy and QuickNode, and L2 sequencers also depend on these nodes, most of which run on AWS us-east-1. A chain may have a thousand validators, yet everyone trusts the data returned by two or three cloud service providers—what kind of decentralization is that?

TRM Labs' quantification is sharper: infrastructure and operational incidents account for about 15% of the total incidents but contribute approximately 76% of the losses. SlowMist's data for the first half of the year indicates that supply chain attacks rank third by incident count but first by loss amount, with KelpDAO alone accounting for $290 million.

Traditional hackers have also started exploiting blockchain for these issues. In a September 2026 report by Chainalysis, this was referred to as Blockchain Dead Drops. Malicious code and control instructions are not stored on servers but written into smart contracts on BSC or embedded in Bitcoin transactions. Blocking domains and pulling servers is ineffective. Data on the chain cannot be deleted; an infected computer can receive new instructions as long as it can query blocks. In the past 12 months, such activities have increased by 420%, with organizations linked to North Korea and Iran accounting for two-thirds of the new activities. Google Threat Intelligence has also observed that UNC5342 has been using the EtherHiding technique since February 2025, targeting crypto developers through fake job postings, with code hidden in smart contracts on TRON, Aptos, and BNB Chain.

The blockchain's most notable feature, immutability, has become the most reliable command server for hackers.

Permission as Attack Surface

Web3 has shifted from a vulnerability economy to a permission economy.

Previously, attackers did three things: find bugs, exploit bugs, and transfer money. Now they also do three things: find someone with signing authority, coax them into signing, and then legally transfer the money.

When comparing the Bybit and Bitget incidents, the issue becomes clearer. Bybit lost $1.45 billion, and the signers saw a transaction on their screens that appeared to transfer money to a hot wallet for liquidity, while the actual signed transaction transferred money to the hackers. Bitget lost $387.5 million, and there was no need to change the frontend; they directly breached the backend system, injected fake transaction data, and the exchange's own approval process deemed it a normal internal transfer, allowing the system to sign the money out.

Both losses were "legitimate." The multi-signature process was completed, the signatures were real, and the contract execution fully complied with the rules. The issue is not who can breach the system, but who has the authority to approve the transfer. The information displayed on the signing interface can be altered, and the data seen by the approval system can be fabricated. If all three signers see the same contaminated RPC and use the same cloud service provider, then 3-of-5 is merely mathematical decentralization; when something goes wrong, it still becomes a single point of failure. Many protocols only achieve mathematical 3-of-5 decentralization on smart contracts, but at the infrastructure level, the entire system runs on the same cloud vendor, relies on the same RPC, and is operated by the same person using a browser—this is "pseudo-decentralization" and also the most fatal single point.

In 2026, these major incidents—KelpDAO was a 1-of-1 single DVN verification, Drift was a 2-of-5 zero-delay multi-signature with a blank check, Resolv Labs had a single AWS KMS key, and Wasabi had an external account holding all administrative privileges—none involved new vulnerabilities; all were known configuration issues and single points of failure. Dune's data shows that 47% of applications in the LayerZero ecosystem still use 1-of-1 single DVN, 45% use two, and only 5% use three or more. Everyone knows the dangers of single points but avoids making changes due to inconvenience. Fifteen months before KelpDAO's incident, a developer had warned them in the Aave governance forum to add more validators, but no one acted. Now, the two parties are in a lawsuit. LayerZero subsequently announced that it would no longer sign applications with any 1-of-1 configurations.

The most dangerous transactions often appear the most compliant.

The Flip of AI Attack Economics

AI has not made attacks smarter; it has enabled attacks to be conducted in bulk for the first time.

Previously, a scammer would focus on one target and spend a month on social engineering, which was costly. Therefore, phishing was done by casting a wide net, sending out thousands of emails to secure a few hits. Now, AI can automatically create fake identities, generate fake websites, write phishing copy, scan code for vulnerabilities, identify targets, and attempt attacks automatically.

The North Korean-linked HexagonalRodent stole 26,584 wallets from 2,726 developer computers over three months. Its backend features real-time infostealer views, VNC-style remote control, browser file management, and a performance dashboard for wallets arranged by team and member. The delivery method is configured in VS Code's tasks.json with runOn: "folderOpen"; developers only need to open the project folder for it to execute without clicking anything. They use ChatGPT and Cursor to write malicious code, generate fake company and executive profiles with AI, and even check if backdoors can bypass antivirus software. TRM Labs calculated that the AI crime index rose from 28 in 2024 to 54, nearly doubling. As of 2026, losses from deepfake scams have already reached 263% of the total losses for 2025.

Anthropic and MATS researchers have developed SCONE-bench, a benchmark set containing 405 real attacked smart contracts. The AI agent replicated an attack worth $4.6 million in a simulator, screening 2,849 new contracts with no known vulnerabilities, discovering 2 zero-day vulnerabilities valued at $3,694, with an API cost of $3,476, resulting in a return on investment (ROI) of approximately 1.06 times. The ROI just surpassed 1, but this is only the initial result. If the model's capabilities improve further or if the scale of contracts increases by an order of magnitude, this number will change. At that point, "AI automatic scanning across the entire chain + automatic monetization" will become a profitable business.

The defense side is also utilizing AI. The day after the release of Claude Opus 4.8, someone discovered a soundness vulnerability in the Zcash Orchard privacy pool ZK circuit that had been lurking for four years. Attackers could exploit this vulnerability to forge ZEC infinitely without detection. Zcash urgently activated a hard fork to isolate the risk. Zcash has a mechanism called turnstile for cross-pool accounting checks. Even if there are issues within the Orchard pool, the total supply will not be infinitely inflated. This serves as a layer of runtime protection, safeguarding against cryptographic failures.

AI has shifted the cost burden to the defenders. Previously, the cost of attacks was high while the cost of defense was low; well-written and audited code could prevent most attacks. Now, crafting a highly customized phishing email takes only seconds, creating a nearly indistinguishable video conference takes just minutes, and scanning thousands of old contracts for vulnerabilities costs very little. Defenders must secure all entry points, while attackers only need to deceive one person to succeed. Four social engineering attacks resulted in losses of $310 million, accounting for 85% of total phishing losses. Scammers are no longer casting wide nets; they are now targeting high-value individuals.

Old code has also become a target again. In the second quarter of 2026, code vulnerability incidents rose from 78 in the first quarter to 126. Attackers are systematically revisiting old contracts that have been deployed for years without re-audits. There were 33 attacks on old tokens on the BNB Chain in the first half of the year, with individual losses ranging from tens of thousands to hundreds of thousands of dollars, all identified through AI scanning. Audits are snapshots taken at the time of deployment, while attacks are happening daily; old code is always at risk of being exploited.

AI agents have also become new targets. Agents can read context, adjust tools, and sign transactions. A malicious instruction hidden within normal input could translate into real monetary losses. After the launch of EIP-7702, a study by USENIX in 2026 showed that 63% of malicious delegations pointed to malicious contracts. Account abstraction provides convenience for users but also opens greater entry points for attackers. In the past, we defended against hackers, focusing on bad actors; in the future, we will defend against agents, protecting against their highly efficient and legitimate transfer of funds to bad actors after receiving contaminated prompts.

Boundaries of Auditing

According to the CoinGecko "2026 Crypto Security Report," among 245 incidents with a total loss of $3.63 billion, 147 protocols that had undergone independent audits accounted for 88.44%. Only 11% of attacks targeted flaws in audited contracts. Supply chain and infrastructure vulnerabilities caused over $1.8 billion in losses.

It’s not that audits are ineffective; it’s that the areas being audited are increasingly not where the thieves strike. Audits focus on the contract code at the moment of deployment, while attacks in 2026 are targeting deployment keys, RPCs, multi-signature processes, supply chains, and newly added code after audits. You can check the quality of the door lock, but if the thief enters through the window, it doesn’t mean the door lock is faulty.

Supply chain attacks were the leading type of attack in 2026, with losses amounting to $298 million according to Slow Mist. A malicious package on npm, downloaded billions of times weekly, infiltrated the frontend, SDK, and wallets, allowing users to sign incorrect transactions. There’s no need to breach the system; simply getting users to install it suffices. North Koreans set up a fake company called Veltrix Capital, offering contracts to open-source maintainers, embedding 24 malicious packages in npm and 12 in PyPI. The best backdoor is always the one users install themselves.

The previous security logic was simple: write code, audit, issue bounties, go live, and pause contracts if issues arise. This logic assumed the biggest risk was bugs in the code. Now, the greatest risk lies outside the code, rendering this logic inadequate.

Defense Must Follow Attack Surface

If thieves don’t enter through the door, defenses cannot only block the door.

Currently, the first diagram security teams should draw is not the smart contract architecture diagram but the full flow diagram of money coming in and going out. From user wallets to the treasury, which signature nodes, which administrators, which oracles, and which bridges are involved? At each node, ask: If this point is compromised, how much can be transferred at most? How many signatures are required? Can it execute automatically? Is there a time lock? Is there a second place to verify again? Can it be stopped immediately if something goes wrong? This is more effective than conducting an additional contract audit.

Next, don’t put all eggs in one failure domain. It’s not about how many signatures there are; it’s about whether those signers rely on the same trust source. If five signers all use the same cloud service provider, the same browser, the same hardware wallet, and see the same RPC returned data, then 3-of-5 is only mathematically decentralized; if something goes wrong, it’s still a single point of failure. Signing hardware should cross vendors, networks should cross carriers, keys should be distributed across different jurisdictions, and offline and online signatures should be separated for true multi-signature security.

In July 2026, TeraSwitch released a flawed interconnecting router that spread through a routing reflector in Amsterdam. 28.83% of staked SOL on Solana went offline simultaneously, just 4.5 percentage points short of the 33.34% finality threshold. 90 validators were affected, and recovery took about 40 minutes. There were 699 validators on the chain, but a single autonomous system AS20326 carried about 27.34% of the staked SOL. While validators on the chain are decentralized, the custodians and upstream routers behind them are not. The decentralization of validators does not equate to the decentralization of infrastructure.

Thus, "re-decentralization" is extending from the consensus layer to the dependency layer. Shared sorters, multi-DVN, and failure domain independence are what truly break apart single points of failure.

RPC cannot be trusted by default. Systems dealing with large sums of money, such as oracles, bridges, liquidation, governance, and treasuries, should not make decisions based solely on one RPC's returned value. At least three different vendors' RPCs should cross-check data; if they return different results, treat it as an attack, not a network failure. High-value paths should run full nodes independently, without relying on third parties. After the KelpDAO incident, RPCs that can return cryptographic proofs will shift from being a selling point to a necessity for institutions.

Wallets should not only check whether signatures are correct but also verify whether the transaction is what the user intends to do. If a user says, "Swap 1,000 USDC for ETH, with slippage not exceeding 0.5%", the wallet should first simulate the transaction, pass it through a risk engine, and confirm that the transaction is indeed for that purpose before allowing a signature. Malicious calldata, unlimited authorizations, address swaps, and frontend modifications can mostly be intercepted at this layer.

Defense requires a four-layer structure.

The first layer is permission governance. 1-of-1 configurations should be prohibited, whether for DVN, multi-signatures, or ADMIN_ROLE. All high-permission operations must enforce a timelock. Deployment keys and runtime keys should be separated; the deployer EOA should transfer control immediately after deployment and not hold ADMIN long-term.

The second layer is infrastructure hardening. The production environment should connect to at least two different cloud providers' RPCs for failover. Key decisions—withdrawals, minting, oracle price feeds—must perform block header or Merkle proof verification and cannot trust the return value of eth_call directly.

The third layer is runtime protection. Circuit breakers, rate limits, and alerts for abnormal amounts. Reduce the "maximum loss amount" from TVL to "time window × limit". THORChain's Solvency Checker and Outbound Delay mechanism serve as excellent examples: observing nodes will continuously compare the actual balance of the underlying native chain with their state machine's calculated accounts. Even if the on-chain logic or RPC nodes are compromised, and hackers create assets out of thin air in the state machine, real-time reconciliation will immediately suspend large withdrawals if discrepancies are found, using physical delays to intercept illegal arbitrage. This serves as a dual circuit breaker of economics and time, safeguarding the treasury even when the frontend and computation layers fail.

The fourth layer is continuous review as a substitute for one-time audits. The evolution of attack methods is faster than the audit conducted on the launch date. The significance of monitoring tools lies in their ability to observe what is currently happening in the system, rather than how the code looked three months ago.

Finally, accept that breaches will occur; don’t think you can prevent all attacks. Instead, consider how to prevent a complete loss of funds if a breach happens. The treasury should not allow a single transaction to transfer $100 million. Small amounts can be automated, large amounts should trigger time locks, and massive amounts must undergo manual review. Audits are not a one-time task upon deployment; on-chain monitoring should continuously observe transaction behaviors, permission changes, oracle price discrepancies, consistency among RPC returns, and gas anomalies. Security is not just about preventing attacks; it involves defense, measurement, blocking, and pursuit all working together.

There’s also shared risk. After the KelpDAO incident, Aave froze the rsETH market within hours, and multiple protocols collectively covered bad debts. Decentralized insurance is not simply about compensating losses after incidents; it’s about distributing risk across all network participants, compelling all token holders to monitor protocol security together. Nexus Mutual is incorporating OpSec Failure Cover into its development plans, and OpenCover has launched Covered Vaults, embedding risk transfer directly into vault products. More interestingly, the capital structure is intertwined: the same restaked capital protects network security while also covering DeFi treasury risks. If issues arise, the paired capital will be automatically slashed to compensate depositors.

Insurance prices will ultimately become the market price of security architecture. When an insurance company considers covering a protocol, it will ask: How many multi-signature signers do you have? Is there a timelock? Is the RPC a single point of failure? How many independent data sources does the oracle have? What is the maximum transfer amount for the treasury each time? Is there a circuit breaker? This is not just what the security team tells you to do; it’s what the capital market tells you your security architecture is worth.

Code is written by humans, who make mistakes; configurations can be forgotten, and single points will always have vulnerabilities. Money belongs to everyone, and everyone will care together.

In 2024, the total loss reached $2.36 billion, with phishing surpassing private key leaks as the biggest threat, leading to a growing awareness of human factors. In February 2025, Bybit accounted for $1.45 billion, bringing the annual total to $3.35 billion, with front-end supply chains and signature interfaces becoming the most critical entry points. In 2026, KelpDAO, Drift, and Bitget combined for over $900 million, with RPC and permission configurations becoming the main battlegrounds, as AI turned attacks into assembly lines, and even traditional hackers began using blockchain as infrastructure.

Over the past three years, the attacker's route has become clear: from targeting code to targeting people, from on-chain to off-chain infrastructure, from finding vulnerabilities to finding trust relationships. The seven mainstream public chains' consensus and execution layers have lost nearly zero directly over these three years; the chains themselves are becoming increasingly robust, while significant losses are occurring around the people, processes, configurations, and infrastructure surrounding the chains.

Web3 has not become insecure; rather, the most valuable attack surface has shifted from within the code to outside of it.

Cryptography can ensure that signatures are genuine, that transactions have not been altered, and that on-chain records cannot be deleted. However, cryptography cannot guarantee that the signer has not been deceived, that the data they see is real, that requests in the approval process are not forged, or that the balance returned by RPC is genuinely on-chain. These are not cryptographic issues; they are trust issues.

Future security will not only focus on code but will encompass the entire system, and further down the line, the entire trust chain. Security is no longer a task that ends with a code review; it is a continuously running system that covers every aspect of people, permissions, infrastructure, supply chains, and AI. Each aspect must be independently verified, and if any part fails, it should not allow losses to compromise the entire system.

The future of Web3 security is not about building a thicker wall but about creating a more refined permission system. The design goal is not "we will never be breached," but rather "even if one person is breached, one RPC is compromised, one dependency is poisoned, one signer is deceived, or one agent makes a wrong decision, the entire system's funds cannot be directly taken away."

What matters is whether the other parts of the system can still stand after one person falls.

Previously, we always asked if there were vulnerabilities in the contract. In the future, we should ask: Who can transfer the funds? What data do they base their decisions on? Is what they trust reliable? If something goes wrong, who will bear the responsibility?

Asking the right questions will ensure that defenses are set up in the right places.