Reading Binance's initial report: the intrusion path and the EIP-7702 authorisations

Binance published its initial report on X at 14:33 UTC on 3 November 2026. Binance’s article has the full account.

The report adds Binance’s account of the intrusion path. Etherscan fields for two Ethereum transactions help compare the delegation and clearing times, but cannot verify the internal steps. Why a deployment token was on an engineer’s computer remains unexplained. The investigation continues, with some details still withheld.

What the report says happened

Binance says the attacker reached its internal wallet signing service through compromised work computers, using deployment credentials stolen from Engineer A. The login window between 17:15 and 19:56 on 29 October has no timezone, so it cannot establish an interval before the later UTC events. Outflows across chains began at 20:05 UTC on 29 October, and the attacker obtained EIP-7702 authorisations through the signing service to establish a hot-wallet delegation. Pausing withdrawals and stopping services could not clear it; the report places Binance 14’s zero-address clearing at 00:10 UTC on 30 October.

The response node distinguishes stopping services from revoking on-chain permissions. Dashed links compare transaction fields; they do not verify the internal signing process.

Why a withdrawal pause could not revoke the EIP-7702 authorisations

Delegation lets an account execute a chosen contract’s code, as described in Valid signatures, wrong transaction: the Bybit and Safe signing supply chain. In EIP-7702 (Final), an authorisation tuple is [chain_id, address, nonce, y_parity, r, s]. A valid authorisation writes 0xef0100 || address into the authority’s code; tuples that fail nonce or other checks are skipped. The specification defines no permission level called “partial execution rights”; that is Binance’s wording.

Clearing the delegation requires the account’s signing mechanism to produce another valid authorisation, this time pointing to the zero address. Step 8 clears the code and resets its hash to 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Binance says its hot wallet used MPC and had no single private key that could revoke the delegation at the time, so the team built a specialised procedure and spent extra time on it. This is Binance’s explanation for the delay; it does not establish that MPC systems in general cannot revoke promptly.

The report says the attacker submitted “50 signing transactions” to manipulate the nonce and establish malicious delegations. Etherscan lists one successful type-4 transaction at 20:20:59 UTC on 29 October 2026, in block 26,300,753. It was sent by the external address 0x7c8601d4645b93cea45f71e118a729332e6b5ca0 to the account labelled Binance 14. It contains 50 tuples pointing to 0x63e842b054bd624a465454d533c33f573e9c6fae, with authorisation nonces from 18,914,775 to 18,914,824.

Etherscan marks only nonce 18914809 as True under Validity; the others are False. Without an independent replay here, those markings do not establish that 50 tuples produced 50 effective delegations. Binance has not published the internal signing records needed to map its reported 50 signing transactions to these tuples.

The other transaction succeeded at 00:10:35 UTC on 30 October 2026, in block 26,301,896. It is a type-4 self-transaction from Binance 14, containing one zero-address tuple with chain id 1 and authorisation nonce 18,914,904, marked valid by Etherscan. Its time matches the report’s 00:10 UTC to the minute. The historical code hash after the transaction was not checked here. The two transactions are about three hours and fifty minutes apart, and the 20:05 UTC XRP outflows were earlier. Those timestamps alone do not measure the whole response.

What the report adds to the earlier posts

The Bybit post records the compromise of a Safe developer’s workstation before the front end was altered. Binance now describes a path from work computers to its signing service. Comparing the front end with the signing service alone cannot establish that the initial entry points differed.

Once the key is safe, who gets to ask for a signature? Custody lessons from Binance in 2019 considers a compromised upstream system while the key remains at the signer. The initial report’s account of the signing service and MPC fits that scenario, but does not prove a key was never exported. It also does not restate Security Incident Update #2, which said there was no evidence of leaked wallet private keys at that stage. The omission settles neither possibility.

Why multisig can still fail at one point: how Ronin’s 5 of 9 came together used Binance’s signed authorisations as a comparison still to be investigated. The initial report describes access to an internal signing service, but does not establish that one private key served several chains or explain how MPC shares were isolated. Recommendation 7 calls for a separate policy and cap for each chain sharing a signer; it remains a design check.

The initial report says that 98% of the impacted token assets had been replenished as of 31 October, with less liquid assets still being purchased. Binance says this is verifiable on its PoR page, but supplies no denominator that can be compared with earlier updates. This post did not re-read PoR or run the verifier. Earlier replenishment and funding claims are covered in Exchanges say the assets are back. What can users actually verify?, and the limits of PoR checks in What should an exchange publish so outsiders can keep checking assets, liabilities and delivery?.

The report also puts frozen or intercepted assets at about US$2.85 billion, subject to reconciliation and market price volatility, without an itemised account of funds returned. Earlier freeze figures and the powers available at each layer are covered in Who can press the stop button? Freezes, chain halts and hard forks act at different layers.

What the report leaves open

Why the deployment token was on the engineer’s computer

The report says the attacker found a container deployment permission token on Engineer A’s computer on 20 October, then used credentials stolen from A to deploy a container from the computer of another engineer, C, on 29 October. Why was the deployment token stored on A’s computer, where could it deploy, and what restricted its use? The report gives neither its permission scope nor its lifetime. It also does not explicitly identify the later credentials as that same token.

The June device replacement and credential rotation do not establish when the token found in October was issued, or whether it was covered by that rotation. The report also leaves the approval controls between container deployment and access to the signing service unexplained.

Binance’s listed remedies include decommissioning the affected credentials and tokens, and tightening device controls. They do not say how deployment permissions will be held after that. The report says the internal AI tool has been rebuilt, but not how it gave the attacker control over A and C. Elliptic’s laundering article discusses a lack of evidence of AI in laundering automation, which does not answer the question about that internal tool.

The report says independent security firms are being engaged, but it names none and gives no timetable.

The series ends here.

Updates

If Binance or an independent reviewer publishes more information, this post will be updated with dated entries.

2026-11-04: Post published, summarising the initial report and checking two transactions.

Notes

The intrusion path is Binance’s account. How the internal AI tool and deployment credentials led to signing-service access still requires independent review.
A withdrawal pause does not clear an EIP-7702 delegation. A valid zero-address authorisation is the specification’s clearing mechanism.
Binance reports 50 signing transactions. Etherscan lists one transaction with 50 tuples and marks only nonce 18914809 valid.
The report’s 98% replenishment claim still lacks a per-token comparison. Frozen or intercepted funds have no itemised account of amounts returned.
The report states that a deployment token was on Engineer A’s computer. It does not explain the token’s permissions or how it was stored.

Source	Use and limits
Binance’s initial report, 14:33 UTC on 3 November 2026	The company’s account of the intrusion and response, awaiting independent review
Security Incident Update #2, 30 October 2026; Update #5, displayed as 12:45 on 2 November 2026, without a timezone	The private-key statement and an earlier replenishment update; recovery background is covered in the preceding posts
Diana’s reply, 12:42 UTC on 3 November 2026	The funding statement discussed in the preceding posts
Etherscan: the transaction containing 50 tuples; the zero-address authorisation	Public transaction fields and explorer validity markings, not an independent replay
EIP-7702: Set Code for EOAs (Final)	Authorisation checks, persistent delegation, code clearing
FBI notice, 31 October 2026	The attribution to North Korea cited by Binance
Elliptic’s incident analysis	Earlier freeze figures covered in the preceding posts; around 05:50 UTC on 1 November 2026 is the data timestamp
Elliptic’s laundering analysis, last updated 08:40 UTC on 3 November 2026	Its AI assessment concerns laundering automation
pyenv v2.8.0, 13 July 2026	Confirms the release exists, not the files on the affected device