What happened
Binance published its initial findings on 3 November 2026 and said the investigation remains subject to independent review. In June 2026, Binance says Wallet DevOps Engineer A downloaded a tampered Homebrew installation while trying to install an AI coding tool; Binance replaced the device and rotated related credentials. In September 2026, attackers used a fake recruitment process to induce Software Engineer B to download a malicious code repository onto a work computer. On 20 October 2026, Binance says the attacker used Engineer B’s compromised computer and an internal AI tool to gain control over Engineers A and C and discover a container deployment permission token. Between 17:15 and 19:56 UTC on 29 October 2026, the attacker used stolen credentials from Engineer A on Engineer C’s computer, deployed a container and triggered the malicious script.
Binance says approximately USD 6.34 billion in digital assets were impacted, approximately USD 2.85 billion had been frozen or intercepted, and 98% of impacted token assets had been replenished as of 31 October 2026. Between 20:05 and 20:09 UTC on 29 October 2026, five hot wallets sent 233.46 million XRP, approximately 970,500 SOL and 44.2 million OP to attacker-controlled addresses; another hot wallet sent 18,270 BTC.
The attackers submitted 50 signing transactions to establish malicious EIP-7702 delegation authorisations that continued independently of Binance’s normal withdrawal infrastructure. Because the affected hot wallet used Multi-Party Computation, Binance says there was no single private key available to revoke the malicious EIP-7702 authorisations immediately. At 00:10 UTC on 30 October 2026, Binance sent a new authorisation from the Binance14 hot wallet to the zero address to clear the EIP-7702 delegation code.
The malicious developer-tool replacement created /opt/homebrew/Cellar/pyenv/2.8.0/libexec/pyenv_, deleted the legitimate pyenv, renamed the malicious file to pyenv, recreated the symlink and spawned zsh. The FBI published TraderTraitor-linked Ethereum addresses including 0x8532FA14ACAf483729C449b8458aedDb900543D4, 0xc887aF690E0301CD4edBbCe8F8d31b4EC65B286A and 0x897C80d1a9729E94460e2Bd93178bD5215158DF3. Attribution posture: The FBI attributes the theft to North Korea’s TraderTraitor activity, while Binance’s own report relies on the FBI’s attribution.
Why this matters now
This is not a cryptocurrency-only failure. The relevant enterprise pattern is a sequence in which information exposed during an earlier developer-tool incident supported targeted recruitment, endpoint compromise, lateral identity control, discovery of a deployment token and access to a transaction-authorisation service. Any organisation where developers can bridge collaboration tools, AI systems, deployment platforms and high-value production operations should test the same path.
Traditional containment assumptions did not fully apply. Suspending withdrawals and shutting down hot-wallet services did not invalidate malicious EIP-7702 authorisations already established on-chain. The lesson for payment, signing, certificate, infrastructure-as-code and machine-identity systems is that emergency isolation must also revoke authority externalised into another control plane, not merely disable the application that originally issued it.
The exposed operating models include cryptocurrency custody, payment platforms, treasury services, certificate authorities and other environments where a developer workstation or deployment token can affect irrevocable transactions. The board-level question is whether privileged authority is bound to a verified person, device, workload, purpose and transaction, with a tested independent revocation path.
The decision for security leaders
Treat service restoration, financial replenishment and compromise containment as separate decisions. Binance has restored asset backing, but enterprise closure requires proof that every affected identity, device, deployment permission, AI-tool path and externalised transaction authorisation has been invalidated or rebuilt.
Reclassify internal AI tools, developer workstations and container deployment systems as privileged control-plane components when they can reach production identities or workloads. Require transaction-specific authorisation, workload identity, dual control, purpose limitation and an emergency revocation path that does not depend on the affected application remaining trusted.
Move hiring-related technical assessments and unsanctioned developer-tool installation into isolated environments with no production credentials. The relevant control is not another awareness reminder; it is preventing externally supplied code from executing in a context that contains production identity, role information or deployment authority.
Evidence of closure
- Credential ledger shows all affected engineer, container and AI-tool tokens revoked and reissued.
- Independent testing proves delegated authorisations can be identified and revoked during a simulated service suspension.
- Signing-policy evidence shows dual approval blocks unauthorised container-originated transaction requests.
The Security.io assessment
The incident is best understood as a control-plane compromise rather than a hot-wallet event. The attacker chain crossed human trust, software acquisition, endpoint identity, an internal collaboration or AI layer, deployment authority and transaction signing. That sequence should be modelled end to end because each locally reasonable control failed to prevent accumulated privilege from becoming an irreversible financial action.
The affected component was an internal Binance AI tool; the cited sources do not identify its product name or framework. No underlying AI model or version was identified in the cited sources. The cited sources do not describe the AI tool’s permissions, connectors, prompt configuration or operator settings. Binance says the attacker used Engineer B’s compromised computer and the internal AI tool to gain control over Engineers A and C; the exact mechanical actions performed by the tool were not published.
The cited sources did not publish the malware hash, malicious repository URL, attacker-controlled server, internal AI tool name or independent review findings. The financial figures and technical reconstruction are therefore detailed but still company-reported. Replenishing assets protects customers from direct loss; it does not prove the signing architecture, developer identity paths or AI-tool controls are independently safe.
Questions for the morning meeting
- Which internal AI tools can invoke or broker privileged production actions?
- Which developer-held tokens can deploy into signing, payment or custody systems?
- Can delegated transaction authority be revoked independently of the normal service path?
- Has an independent reviewer received enough evidence to challenge the company’s reconstruction?