Binance Hacked: October 2026 Hot Wallet Theft and EIP-7702

Binance is investigating a major security incident after suspicious transfers from its hot wallets on October 29 UTC, or October 30 in Beijing. The immediate security question is how a wallet was authorized to execute unfamiliar code. An exchange can have functioning login controls and audited contracts while its signing workflow still approves an operation that should never have reached a key.

Developing story, checked October 30, 2026. Binance’s official account says its teams are investigating and that user funds are safe. Its official news feed reports precautionary deposit and withdrawal suspensions, a commitment to cover incident-related losses, and approximately $3 billion in frozen assets. That frozen total is not a final theft figure, recovered cash, or net loss.

This analysis separates those statements from preliminary onchain research. It does not establish how the attacker first obtained signing authority, identify the attacker, or claim that Ethereum’s cryptography failed. The useful defensive lesson is to test the path from a business request to the exact operation a signing service approves.

What is confirmed and what remains open

Blockaid’s preliminary investigation describes 50 EIP-7702 authorizations targeting Binance 14, with one matching the account’s current nonce. It places delegation around 20:20 UTC on October 29 and the initial sweep around 20:24 UTC. Those times correspond to roughly 04:20 and 04:24 on October 30 in Beijing. The report is useful technical evidence, but its attribution and dollar estimates should not be substituted for Binance’s eventual postmortem.

Why delegation changes the signing boundary

EIP-7702 introduces type 0x04 transactions carrying signed authorizations. A valid authorization can set an account’s code to a delegation indicator, 0xef0100 followed by a target address. Calls then execute the target’s code in the authorizing account’s context. The change persists beyond the transaction; a later valid authorization can replace or clear it.

A signature therefore needs a semantic approval decision: what authority does this exact operation create? A transfer review that shows only a familiar destination or an outer transaction’s value may omit the permission change that matters. This is a general control-design concern, not a claim about Binance’s internal interface.

Valid signatures also leave an important investigative ambiguity. An attacker might extract a key, compromise an application that asks a signer to act, or manipulate the policy and approval path. An onchain signature does not by itself distinguish those routes. Hardware protection or a multiparty signing arrangement must be assessed together with the policy that decides which requests may be signed.

A safe first check for an owned wallet

Use a read-only code query at a recorded block when investigating an account you operate. Ethereum’s JSON-RPC documentation يحدد eth_getCode and its block parameter. The following request targets only a local node or isolated fork. Replace the synthetic address and block with your approved test fixture; it does not sign or submit a transaction.

curl -s http://127.0.0.1:8545 \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
           "params":["0x1111111111111111111111111111111111111111","0x1234"]}'

For offline triage, this small classifier recognizes the delegation-indicator shape. It consumes recorded bytes and has no network or signing capability.

def classify_account_code(code_hex):
    code = bytes.fromhex(code_hex.removeprefix("0x"))
    if not code:
        return {"kind": "empty_code"}
    if len(code) == 23 and code[:3] == bytes.fromhex("ef0100"):
        return {"kind": "delegation", "target": "0x" + code[3:].hex()}
    return {"kind": "other_code"}

assert classify_account_code("0x")["kind"] == "empty_code"
assert classify_account_code("0xef0100" + "11" * 20)["kind"] == "delegation"

A recognized indicator is not proof of maliciousness: legitimate delegated accounts exist. Empty code at one block is not a clean bill of health either. Retain the chain ID, block number and hash, query result, provider, and collection time. Compare the target with your approved deployment inventory and examine the historical transition, not just the latest state.

What exchange security teams should validate

The following is a proposed defensive test plan for an organization’s own environment. It is not a reconstruction of Binance’s systems. Run policy and workflow tests against synthetic accounts, isolated signers, and test assets before considering any production verification.

Rejecting an unfamiliar transaction in the front end is insufficient if an internal worker can call the signer directly. Test the same policy at every authorized entry point. Conversely, a rejected test should not be reported as a vulnerability merely because it reached a UI: the relevant question is whether a protected state transition or signature actually occurred.

Monitoring should distinguish ordinary transaction activity from changes to an account’s execution authority. Correlate wallet-state changes with approved maintenance, signer decisions, administrator access, deployment changes, and an external log store. An alert that only records a large outgoing amount may arrive after the more informative authorization change.

Containment needs more than a new key

Our recommended response model starts by quarantining uncertain wallet routes and preserving evidence. Have the incident commander coordinate deposit routing, signing access, provider contacts, and asset-specific containment. A confirmed freeze on an issuer-controlled token does not demonstrate recovery of unrelated assets or removal of the original access path.

Changing where future business is routed does not modify the state of an old address. Treat any existing delegated account, pending automation, previously signed material, and compromised signing dependencies as separate recovery tasks. Do not refill a wallet simply because a new key or service has been provisioned elsewhere. Recovery operations themselves need independent review, particularly when the old key’s confidentiality or signing environment is uncertain.

Close the incident only against explicit conditions: affected routes are contained, the initial access path has been addressed or bounded, wallet state has been independently verified, reconciliation is complete enough for the stated recovery decision, and monitoring has demonstrated that it can detect a recurrence. Record unresolved assumptions rather than converting them into a blanket “safe” status.

What this means for blockchain penetration testing

A blockchain security engagement should state whether it covers the web application, exchange API, withdrawal workflow, signing policy, wallet execution state, and smart contracts. Those are different evidence domains. The OWASP API Security Top 10 gives useful categories for testing authorization and sensitive business flows, but an API checklist alone does not assess a custody system.

For the application and API portion, Penligent can help organize an authorized investigation and its reproducible evidence. A claim about contract correctness, HSM or MPC assurance, or institutional custody policy needs separately scoped specialist work; it should not be inferred from an automated web pentest report. The next practical step is to define which business decision can create spending authority and demand evidence at that boundary.

Questions readers are asking

Was Binance hacked on October 30, 2026?

• Binance has acknowledged an active security investigation. The activity discussed here was reported on October 29 UTC, which is October 30 in Beijing. A final postmortem is needed for the full cause and impact.

Is the reported frozen amount the final loss?

• No. Gross transfers, traced funds, frozen assets, returned assets, and net losses require separate accounting. Avoid adding estimates from different chains or reporting times together.

Does EIP-7702 make every wallet compromised?

• No. Delegation is a protocol feature. The security review must determine which authorizations were signed, what code they designated, and whether the relevant controls approved them.

Should users connect a wallet to a recovery page?

• Do not follow unsolicited recovery links or disclose seed phrases, private keys, or account credentials. Use Binance’s own verified channels for incident instructions; a news article cannot authenticate a recovery service.

Can a smart contract audit replace exchange penetration testing?

• No. Contract review and offchain workflow testing answer different questions. Agree on the boundary and evidence for both before accepting a coverage claim.