Binance was hit by another major security incident on Oct. 30, adding to a string of high-profile breaches that have rattled the crypto industry over the past year.
According to the source article’s preliminary account, the attacker may have first compromised a DevOps engineer’s laptop, then entered a service container and submitted unauthorized withdrawal transactions. Binance estimated the total impact at $6.3 billion and said about $3 billion in related assets has been frozen through joint efforts.
Placed alongside earlier incidents, the pattern looks harder to ignore. Bybit lost about $1.46 billion last year. Bitget saw about $387.5 million moved without authorization in September this year. Now Binance has been pulled into a new round of turmoil.
The attack paths were different, but the article argues they share one feature: attackers are spending less time trying to brute-force cryptography or private keys and more time targeting the broader chain of trust. Employee endpoints, third-party security products, software supply chains, service containers, and transaction approval flows can all become the weak point that breaks the whole defense line.
AI is making that risk larger. On Oct. 22, Ethereum co-founder Vitalik Buterin offered a blunt assessment: in the AI era, the long-term end state of cybersecurity may favor defenders, but the transition period will be very hard.
From Bybit to PHP2Shell, attackers are moving through the full trust chain
The article first revisits the recent exchange incidents.
In the Bybit case, attackers used social engineering to compromise a Safe developer’s device, obtained related access credentials, and then took control of frontend resources in Safe’s wallet infrastructure.
In the Bitget case, attackers exploited a flaw in a third-party security product, obtained high-privilege internal credentials, and then used forged withdrawal instructions to bypass existing risk controls.
In the latest Binance incident, the path likely began with the compromise of a DevOps engineer’s laptop.
Those three cases touched three different layers: third-party wallet infrastructure, third-party security products, and internal development and operations environments. That, the article says, helps explain why cold wallets and multisig setups are not a cure-all. The exploited point is often not the private-key algorithm itself, but a trusted link that can influence final transaction execution without being independently verified to the same degree.
The same trust-chain problem extends beyond crypto exchanges.
A week before the Binance incident, Binance founder CZ posted a warning that users should be extra careful when visiting any website over the following days. At the time, two critical PHP core engine flaws known as PHP2Shell — CVE-2026-109618 and CVE-2026-109619 — were drawing broad attention. Both carried a CVSS v4.0 score of 9.2.
PHP powers about 70% of websites globally, according to the article, including major platforms such as WordPress, Magento, and Drupal. The two flaws, described as long-dormant bugs tied to memory management and global state reset, could let an attacker achieve remote code execution with a single specially crafted web request and no authentication, before the site’s own application code even runs. That would allow direct server takeover, backdoor deployment, or credential theft.
Scanning data cited from Palo Alto Networks and Censys showed that more than 22.6 million to 36.7 million internet-exposed instances were within the risk range.
The article says security firms disclosed that these two low-level memory-state flaws, which had remained hidden for more than a decade and were difficult for human auditors to spot, were uncovered with the help of AI. In practical terms, that means AI is lowering the barrier to turning obscure logic flaws into usable attack payloads.
It groups the shift in AI-era cyberattacks into three changes:
- Industrialized zero-day discovery. Finding deep memory bugs in a PHP core engine or firmware layer once required elite researchers to spend months on manual code review and fuzzing. AI can now scan open-source codebases around the clock at much lower cost and turn years-old bugs into operational weapons at scale.
- An extreme compression of the patch window. Once vulnerability details leak or patch code is committed, attackers can use AI to reverse patches, generate exploit variants, and automate internet-wide scanning and injection within minutes. Traditional upgrade cycles measured in days or weeks struggle to keep up.
- Software supply chains and DevOps as the primary entry point. Modern Web3 and financial systems do not exist in isolation. Frontend interfaces, backend containers, third-party NPM and PyPI packages, and engineers’ local development environments form a large and fragile open-source supply chain.
Seen through that lens, the Binance DevOps container compromise and the Bybit frontend supply-chain tampering point to the same issue. Because onchain attacks are easy to monetize directly, the crypto sector may be among the first to absorb what the article describes as a global wave of AI-enabled hacking on a near-pandemic scale.
It also makes one distinction clear: not every attack above was directly launched or executed by AI. Even so, AI is amplifying both attackers and defenders, and under today’s software engineering model that amplification can deepen the structural asymmetry that already exists between the two sides.
Vitalik: the end state may favor defense, but the transition will be brutal
In response to the debate triggered by low-level flaws such as PHP2Shell, Buterin said on Oct. 22 that the long-run end state of cybersecurity could tilt toward defenders. His caveat was just as important: the transition will be extremely difficult.
The reason is asymmetry built into current software engineering. A large software system can contain millions of lines of legacy code, hundreds of external dependencies, and a dense web of permissions and execution paths. Defenders need every critical link to hold. Attackers need only one gap that has not yet been found.
Buterin’s point, as presented in the article, is that relying on researchers to find bugs in released software before hackers do is not enough to create a durable defensive edge. If both sides are using stronger AI, the contest still comes down to who finds the flaw first.
What has to change is the way software itself is built. He highlighted two directions: formal verification and minimizing the trusted computing base, or TCB.
Formal verification: replacing trial-and-error with mathematical proof
Traditional testing can show that no bug was found in the scenarios that were tested. It cannot prove that no bug exists. Formal verification aims to do something stronger: use mathematical logic to prove that code satisfies its security specification across all possible inputs and state transitions, ruling out issues such as memory overflow, state-reset failures like PHP2Shell, or reentrancy-style logic flaws.
Historically, formal verification has been expensive. The code needed to express the proof could be several times larger than the business logic itself, which is why it was mostly reserved for aerospace systems or core cryptographic protocols.
But the article says AI changes that equation. AI can search for bugs, but it can also help write formal proofs. Buterin’s view is that AI-assisted formal verification could become the eventual form of software development. Signal-style encrypted communication protocols, TLS, ZK-EVM systems, and application-layer smart contracts could all, in principle, receive end-to-end mathematical security proofs before release.
If code is mathematically shown to satisfy its security properties, then stronger attacker-side AI cannot discover a vulnerability that is not there.
Minimizing the TCB: shrinking the attack surface around what must be trusted
The second direction is to reduce the trusted computing base.
The TCB is the full set of hardware and software components that a system must trust unconditionally in order to remain secure. Looking back at Binance’s $6.3 billion incident and the earlier Bybit multisig hijacking, the private-key algorithms were not broken, yet funds were still lost. The article’s explanation is that the TCB had become too large: container clusters, complex operations-permission pipelines, developers’ laptop operating systems, and frontend JavaScript libraries all sat inside a trust chain where compromise could lead to asset loss.
The core idea behind TCB minimization is subtraction and isolation. Functions that directly handle private-key protection, signature verification, and core authorization should be pulled into smaller, more clearly bounded, tightly audited environments. Other complex functions should run in peripheral environments with limited permissions.
Under that model, even if a browser, plugin, frontend service, or AI agent is compromised, it should not automatically gain unrestricted power over user assets.
The article uses non-custodial wallets such as imToken as one example of a shorter trust chain. On a centralized exchange, user assets pass through platform accounts, custodial wallets, and internal withdrawal systems. With imToken, users hold their own private keys, manage onchain assets directly, and initiate transactions themselves, removing the centralized custody layer in the middle.
A shorter trust chain means less platform-level risk exposure and no dependence on whether an exchange pauses withdrawals or freezes account balances. The trade-off is that users take on direct responsibility for private-key storage and device security.
From acceleration to d/acc: why defensive acceleration matters
If formal verification and TCB minimization answer the question of how to make systems safer at the technical level, Buterin’s broader d/acc framework tries to answer a larger one: when AI and other frontier technologies are changing the world quickly, what should society choose to accelerate first?
d/acc stands for Defensive Accelerationism. The article says Buterin first laid out the idea systematically in 2023 and expanded on it again in 2025 in d/acc: one year later.
The framework does not reject technological progress. It argues for selective acceleration: prioritize technologies that strengthen society’s defensive capacity, distribute power more broadly, and reduce systemic risk. In contrast with e/acc’s push for acceleration across the board, d/acc asks whether a technology is increasing offensive capability or improving defense.
Within that framework, the article lists four layers of defensive buildout:
- Cyber defense: cryptography, formal verification, software isolation, and vulnerability detection to reduce attack success rates and protect digital assets and data.
- Bio defense: pathogen detection, air monitoring, vaccine development, and public-health technology to improve resilience against biological risk.
- Physical defense: distributed energy, resilient communications, and infrastructure hardening to reduce vulnerability in critical real-world systems.
- Information defense: privacy protection, source verification, and decentralized coordination to resist misinformation, deepfakes, and large-scale information manipulation.
Those areas are broad, but the article ties them to one goal: as technology increases the capabilities of individuals and organizations, it should also increase their ability to protect themselves, rather than concentrating stronger tools in the hands of a small group with resources and control.
In the discussion around the PHP flaws, Buterin also reiterated a harder line within the d/acc framework. Faced with the asymmetric shock created by frontier AI, high-risk offensive AI should be treated cautiously at certain stages. At the same time, society should direct more than 1% of GDP into cybersecurity, biosafety, and hardening the physical world’s security infrastructure.
The article’s reasoning is straightforward. Markets can price and commercialize the gains from technological progress quickly, but the value of security infrastructure is often underestimated. Companies may spend heavily on stronger AI models, faster compute, and more efficient software-development tools, while giving far less support to long-term maintenance of foundational open-source software, formal verification, and security audits. If that resource mismatch is left in place, digital systems built on fragile open-source foundations become more dangerous over time.
In the AI era, security is no longer just about finding bugs first
From the internet-wide infrastructure risk exposed by PHP2Shell to the major incidents at Bybit, Bitget, and Binance, the article argues that 2026 is delivering an expensive lesson in real time: the contest in cybersecurity is no longer only about who can discover vulnerabilities faster. It is also about whether the software ecosystem can build defenses that remain reliable under pressure.
Security will never be a one-time fix. The article does not frame that as a hopeless war of attrition. Over the past decades, cryptography has already shown that some defensive guarantees can be built on mathematical foundations rather than on simply adding more human effort. AI, combined with formal verification and a smaller trusted computing base, could extend that logic to much larger parts of the software stack.
For ordinary users, the same security philosophy can shape how assets are managed. Choosing a non-custodial wallet such as imToken means keeping control of assets in one’s own hands and reducing reliance on centralized custody and internal operating systems. It also means taking device security, seed phrase storage, and every transaction approval more seriously.
The article closes on a narrower reading of Buterin’s claim that the end state may favor defenders. It does not mean AI will stop finding bugs one day. It means the systems people rely on should be built so they can keep operating even against smarter attackers, using a smaller trusted core, tighter permission boundaries, and security mechanisms that can be verified. Technological progress may deserve acceleration. The capacity to protect that progress, and the assets tied to it, needs acceleration too.
