Binance’s preliminary findings point to compromised operational infrastructure rather than a confirmed leak of wallet private keys. Blockaid identified a successful EIP-7702 delegation among
A compromised employee laptop may have been enough to expose billions of dollars in cryptocurrency without the attacker directly stealing Binance’s hot-wallet private keys.
That is the central security question emerging from the October 29 incident, which Binance now estimates had an impact of approximately $6.3 billion. In its official statement, the exchange said its initial investigation pointed to a compromised DevOps engineer’s laptop, unauthorized access to a service container and fraudulent withdrawal transactions.
Binance’s initial investigation suggests that the security incident may involve a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions. We have found no evidence of any wallet private key leak. We will share a detailed technical post-mortem once the investigation is complete and the facts are fully verified.
The estimated total impact sits at around $6.3B. We have worked with blockchain partners to freeze affected assets, with ~$3 billion frozen on-chain so far. Binance will cover all losses from the SAFU fund and the company’s funds. User funds are safe. We will also publish an updated Proof of Reserves once the remediation is complete.
As an immediate precaution, Binance has:
– temporarily suspended deposits and withdrawals while security checks are completed; – revoked the affected address authorisation; – engaged law enforcement and blockchain intelligence partners to trace and recover funds.
Our teams are working around the clock to resolve this issue safely and thoroughly. We are working closely with our law enforcement partners to confirm the identity of these criminals and bring them to justice.
Please rely only on official Binance channels for updates. Please feel free to contact Binance Customer Support if you have any further questions.
https://t.co/ywB2mKFy0p
— Binance (@binance) October 30, 2026
Binance reported no evidence of a private-key leak. It temporarily suspended deposits and withdrawals, revoked the affected authorization and committed SAFU reserves and corporate funds to cover customer losses.
The exchange’s preliminary explanation and independent blockchain findings describe different parts of the suspected attack. Together, they raise a question that extends beyond Binance: whether exchanges’ operational controls adequately protect the increasingly complex permissions attached to Ethereum accounts.
Blockchain security firm Blockaid identified an unusual sequence involving Binance 14, an Ethereum hot wallet at 0x28C6c06298d514Db089934071355E5743bf21d60.
According to Blockaid, the attacker submitted 50 EIP-7702 authorizations in a single Type-4 transaction, covering account nonces from 18,914,775 to 18,914,824. Only one authorization matched the wallet’s active nonce when the transaction executed.
A nonce is a sequence number used to order transactions and prevent replay. Binance’s hot wallet was processing transactions continuously, making its nonce difficult for an attacker to predict precisely.
Submitting authorizations across a range of values allowed the attacker to account for that uncertainty.
Ethereum’s EIP-7702 permits an externally owned account to delegate execution to smart-contract code through a signed authorization. Once the matching authorization took effect, Binance 14 reportedly delegated execution to a malicious implementation.
Blockaid described a contract containing a restricted sweep() function that could transfer ETH and ERC-20 assets while retaining 1 ETH for transaction fees.
The resulting activity included approximately 167,464 ETH and dozens of tokens transferred from the wallet at 20:24 UTC.
The successful nonce match explains how the delegation was activated. It does not establish how the attacker obtained the valid signatures in the first place. That remains a critical gap between the on-chain evidence and Binance’s preliminary account of the infrastructure compromise.
The malicious delegation reportedly pointed to contract 0x63e842B054Bd624a465454D533C33F573e9c6fAe, with an operator address at 0x7C8601d4645b93cea45F71e118A729332e6B5CA0. Blockaid traced the operator’s funding to Tornado Cash withdrawals and identified earlier tests of the delegation-and-sweep sequence.
Those preparations indicate a planned attack rather than an accidental authorization. Yet they do not establish that EIP-7702 itself contained a software vulnerability.
The protocol accepts correctly signed authorizations whose nonces match the account’s state. The security failure under examination is how an unauthorized party obtained signatures capable of granting such extensive control.
This matters for institutional wallets because a delegated contract can introduce permissions that traditional transaction-monitoring systems may not expect. An exchange could protect its private keys while still exposing funds if its signing infrastructure approves a malicious authorization.
A more effective defense would therefore include explicit restrictions on EIP-7702 authorization signing, verification of delegated contract addresses and monitoring for unexpected changes to account code.
Binance’s preliminary assessment places the incident’s total impact at approximately $6.3 billion, with around $3 billion frozen on-chain. The exchange has committed SAFU and company funds to covering losses, but has not disclosed the precise contribution expected from either source.
Binance Security Incident Financial Exposure and Containment October 30, 2026 | Preliminary figures Estimated total impact $6.3B Assets frozen on-chain ~$3.0B Difference between estimates ~$3.3B Reported containment ratio ~47.6% Note: The $3.3B difference is arithmetic, not a verified unrecovered loss. Frozen assets are not necessarily returned assets. Figures are based on Binance’s preliminary statement.The calculation highlights an important limitation: issuer freezes restrict transfers but do not automatically restore ownership or liquidity.
Binance must still reconcile affected wallets, identify the amounts recoverable from each issuer and determine its remaining reimbursement obligation.
The suspected attacker also used decentralized lending markets before restrictions took effect.
In its incident assessment, Aave risk service provider LlamaRisk identified a wallet that deposited approximately $60 million USDT into Aave V3 Ethereum Core and borrowed 19,762 WETH, valued at roughly $44.6 million.
The resulting position remained overcollateralized, with $59.9 million in collateral against $43.8 million in debt. LlamaRisk said the position did not put suppliers at risk.
Aave nevertheless froze 175 V3 reserves across 16 networks and 117 V4 reserves across four networks. The action prevented new deposits and borrowing while preserving withdrawals, repayments and liquidations.
This response created a separate operational cost for legitimate borrowers. When deposits are frozen but withdrawals continue, reserve utilization can rise, increasing variable borrowing rates.
LlamaRisk subsequently recommended temporary adjustments to interest-rate parameters to limit borrowing costs in heavily utilized markets.
The incident therefore demonstrates a mechanism through which stolen exchange assets can disrupt lending conditions without exploiting the lending protocol itself.
Binance’s reimbursement commitment and its withdrawal restrictions address different risks. The former concerns eventual customer losses; the latter determines whether customers can access assets immediately.
Customers with pending withdrawals should retain their withdrawal IDs and check whether the exchange has published an on-chain transaction hash. A pending internal request does not establish that funds have left Binance.
Those holding assets on the exchange should monitor official service announcements rather than follow unsolicited recovery instructions. A compromised exchange hot wallet does not, by itself, mean that an unrelated self-custodied wallet has been breached.
Binance has promised an updated Proof of Reserves after remediation. That information can help assess customer-asset backing, although it cannot independently establish the exchange’s unrestricted corporate liquidity.
The decisive issue for Binance’s technical post-mortem is how the attacker obtained valid authorization signatures despite the reported absence of a private-key leak. Establishing that sequence would provide a clearer basis for improving exchange wallet security than the headline loss figure alone.
The post Binance’s $6.3B Hack Exposes a New Hot-Wallet Security Risk appeared first on ETHNews.
