On Thursday, a Binance wallet authorized a permission that allowed a hacker-controlled contract to take command of it. Approximately four minutes later, roughly $2.5 billion worth of ether and digital tokens had vanished.
This accounted for just a portion of the estimated $6.3 billion that Binance reported stolen across multiple blockchain networks. On Ethereum, the culprit leveraged a mechanism known as EIP-7702, derived from its Ethereum Improvement Proposal identifier. This capability launched in May 2025 as part of the Pectra upgrade.
To comprehend its significance on Thursday, we must first examine how a standard Ethereum wallet functions.
Wallet goes rogue
The majority of Ethereum accounts—ranging from an individual’s browser wallet to an exchange hot wallet—rely on a private key for administration. The key generates signatures for transactions, and the wallet transmits them. A standard wallet cannot enforce autonomous constraints, such as a maximum daily disbursement threshold or a whitelist of approved destinations.
Wallets capable of enforcing rules are built as smart contracts, which represent a distinct category of account capable of executing programming code.
EIP-7702 enables a traditional wallet to temporarily utilize that code. The account signs a brief message termed an authorization, which points toward a smart contract. Once the network validates this authorization, the wallet executes the contract instruction set as though it were native code.
Any network participant can submit the signed authorization, and it remains valid on-chain until an update or revocation is recorded.
The function was originally designed to let everyday wallets batch transactions and permit external entities to cover gas fees. Within weeks of its release, market maker Wintermute observed that the majority of EIP-7702 delegations directed funds toward duplicated sweeper scripts. Such programs automatically transfer a wallet balance to an operator once its private credentials are compromised.
The threat actor on Thursday utilized this exact functionality to compel a multi-billion-dollar Binance wallet to execute their personal sweeper script.
Blockchain trail
The primary perpetrator address, 0x7C86…5CA0, received funding through fractional withdrawals from the Tornado Cash mixing service beginning Wednesday, based on a blockchain reconstruction.
During Thursday afternoon UTC, the assailant tested the methodology using their own personal wallets. Around 16:00 UTC, they deployed a sweeper contract designated as 0x63e8…6fAe, containing logic that restricted control exclusively to the hacker’s address.
At 20:20:59 UTC, the attacker broadcast a single transaction containing 50 distinct authorizations. Each one bore the signature of the address identified on Etherscan as “Binance 14”—one of numerous accounts linked to Binance—and all pointed Binance 14 toward the sweeper contract.
Binance 14 maintains an incremental transaction counter known as a nonce, which advances every time an outbound transfer occurs. Every signed authorization must precisely correspond with this counter value when the network processes the message.
However, Binance 14 was processing withdrawals so rapidly that its nonce kept shifting upward. To account for this, the operator prepared 50 sequential permissions covering consecutive nonces ranging from 18,914,775 to 18,914,824, ensuring the malicious payload would succeed while normal operations continued.
Data from Etherscan evaluated by CoinDesk indicates the network processed the specific authorization numbered 18,914,809 while disregarding the other 49. Five operations earlier within that identical Ethereum block, Binance 14 had submitted transaction number 18,914,808, making 18,914,809 the exact next valid counter.
This indicates an entity successfully acquired 50 valid signatures granting Binance 14 permission to run the malicious script, with each authorization bound to a unique nonce value.
At 20:24:23 UTC, the attacker triggered the sweeper logic via Binance 14. In one solitary transaction, approximately 167,464 ETH alongside 63 separate tokens—including roughly 1.6 billion USDT—were transferred to the attacker.
The breach did not conclude at that moment. Internal Binance infrastructure continued funneling user deposits directly into Binance 14, and the hacker swept those inflows out again at 21:04 and 21:44 UTC.
Furthermore, the attacker utilized the hijacked functionality of Binance 14 to issue instructions to a separate smart account called Hot Wallet 34, draining 823 million USDC from it, according to analysis by TRM Labs.
Binance 14 remained subjugated under the unauthorized delegation framework for nearly four hours. At 00:10:35 UTC on Friday, the wallet nullified the permission, eliminating the hostile script.
The signatures’ origins
The on-chain Ethereum records deliver detailed insight into a single facet of a much broader scale theft. The adversary also removed 18,270 bitcoin, alongside hundreds of millions of XRP and assets across Solana, Tron, and additional networks.
Those alternative ledgers do not implement EIP-7702, meaning those stolen capitals exited exchange reserves through standard signed transfers, as reported by TRM Labs.
The common element across these vectors is that all transactions contained legitimate signatures originating from Binance-managed accounts. The mechanism by which the perpetrator acquired the capability to generate those cryptographic approvals across disparate networks remains under active inquiry.
Binance Co-CEO Richard Teng stated on Friday that initial findings pointed toward a compromised developer laptop, which potentially granted the assailant entry to a service container to broadcast unauthorized withdrawals.
“The attacker did not simply use one engineer’s permissions, and this was not a single ‘one-click’ action,” Teng noted on X. “It involved a more complex attack process.”
He emphasized that the inquiry had not assigned blame to any individual and uncovered no proof that private keys had leaked.
Binance later reported via X that security experts identified extra compromise vectors extending beyond the initially suspected workstation. The platform omitted details regarding those entry vectors or how the attacker secured the signatures necessary to authorize transfers across institutional reserves.
One viable hypothesis suggests the intruder manipulated Binance internal signing mechanisms to issue the needed authorizations. Binance has not yet released the comprehensive attack methodology.
An EIP-7702 authorization defines the operational code an account will execute, independent of specifying a beneficiary address or transfer volume. Consequently, authorizing malicious code can immediately compromise existing balances as well as any subsequent deposits.
Binance values the overall impact at $6.3 billion and has committed to absorbing all deficits utilizing its SAFU emergency reserves alongside corporate funds. The firm indicated on Friday that roughly $3 billion of the impacted tokens have been successfully frozen.
Originally published at https://www.coindesk.com/tech/2026/10/30/here-s-how-one-ethereum-permission-let-an-attacker-drain-usd2-5-billion-from-binance.
