EIP-7702 не является главной причиной хищения $6,3 млрд с Binance; ключевое — как была получена подпись.

Пекинское время, 30 октября 2026 г., 04:24.

Данные блокчейна показывают, что средства выведены с адреса 0x28C6…1d60. Этот адрес называется Binance 14 — один из крупнейших горячих Ethereum-кошельков Binance, ежедневно отправляющий тысячи выводов. В этой транзакции переведено 167 464 ETH, $1,615 млрд USDT и более 60 типов токенов общей стоимостью ~$2,5 млрд на тот момент. На кошельке остался 1 ETH.

Комиссия за газ составила 0,0004 ETH — менее $1.

За три минуты до этого, в 04:21, кто-то отправил транзакцию типа EIP-7702 на этот адрес, содержащую 50 авторизаций с Nonce от 18 914 775 до 18 914 824. 49 оказались недействительными, одна сработала. «Срабатывание» означает: с этого момента любой вызов Binance 14 выполняет контракт, развернутый злоумышленником накануне в 23:59 — непроверенный «очиститель» с единственной функцией очистки.

Таким образом, Binance 14 перестал быть кошельком. Он превратился в оболочку, содержащую чужую программу.

К 08:06 делегация всё ещё действовала. Прошло 3 часа 45 минут, но никто не отозвал её.

А «отзыв» этой делегации требует лишь одного дополнительного подписания тем же приватным ключом. В 06:55 утра Binance всё ещё использовала этот ключ для перевода рассеянных токенов, не захваченных «очистителем», обратно в собственный кошелёк.

Является ли EIP-7702 главной причиной атаки?

Логика EIP-7702 такова: обычный адрес (EOA) может временно использовать код смарт-контракта, сохранив при этом свой адрес, баланс и приватный ключ. Для этого в поле кода адреса записываются 23 байта: 0xef0100 + адрес контракта. Эти 23 байта — не исполняемый код, а указатель. После этого любой вызов этого адреса заставляет EVM загружать и выполнять код по указанному указателю в контексте этого адреса: address(this) остаётся прежним, баланс — тоже.

Уязвимостей в нём нет. Дерек Цзян, основатель ZeroDev и участник разработки EIP-7702, прямо заявил в день инцидента: сам EIP-7702 не содержит уязвимостей, и пользователи кошельков, поддерживающие этот стандарт, могут не беспокоиться. Он добавил: чтобы злоумышленник применил 7702, он должен либо контролировать приватный ключ, либо обманом заставить Binance подписать авторизацию 7702.

Это уже не первый случай его использования в атаках. После апгрейда Pectra на Ethereum Wintermute уже через несколько недель обнаружила, что более 97 % всех делегаций 7702 в основной сети указывают почти на один и тот же контракт-«очиститель». Исследования насчитали около 3,66 млн транзакций авторизации, из которых ~63 % связаны со злонамеренными контрактами, с подтверждёнными потерями $2,3 млн; Blockaid подтвердила четыре инцидента с 7702 в первой половине 2026 г. на общую сумму ~$1,08 млн и предсказала, что первый случай на семь цифр произойдёт в течение года.

Результат превысил оценку на три порядка — десятизначная сумма.

Это заставило многих считать EIP-7702 причиной взлома Binance на $5,6 млрд — крупнейшего в истории. Но действительно ли это проблема 7702?

Как были получены подписи

Прежде чем продолжить, следует уточнить: 50 авторизаций = 50 подписей — но как именно они были получены?

Если бы злоумышленник получил полные приватные ключи, зачем ему слепо перебирать 50 Nonce? Если ключи всегда были у Binance, почему за 12 минут пострадали одновременно 11 кошельков? Объяснения по-прежнему нет.

Через 24 секунды после основного вывода Binance 16 перевела 28 005,6 ETH, 55,7 млн USDT, 25,9 млн RLUSD и 84,5 WBTC на один и тот же адрес получателя.

В течение 12 минут ещё 10 горячих кошельков Binance повторили это на четырёх блокчейнах: Binance 55 на Optimism вывела 44,2 млн OP; четыре кошелька на Arbitrum — 74,6 млн ARB и 8426 ETH; четыре кошелька на Avalanche — 1,81 млн AVAX и 8,41 млн USDT.

Ни один из этих кошельков не содержал кода. Все транзакции были обычными переводами, подписанными приватным ключом кошелька, и встраивались между рутинными выводами.

Тому, кто владеет приватными ключами, не нужно «слепо» подбирать nonce. Запрос eth_getTransactionCount занимает одну секунду.

Человеку, которому приходится сразу генерировать 50 авторизаций под 50 последовательных nonce, присущ иной тип угрозы: либо он может получать подписи, но не имеет доступа к актуальным данным кошелька, либо может отправлять только заранее подготовленную пачку авторизаций, полагаясь на систему для их последовательного выполнения.

Примечательно, что все 50 авторизаций были одобрены единовременно в одной транзакции.

Аналитики Blockaid считают, что «ключ был использован ненадлежащим образом», а не скомпрометирован напрямую. Вице-президент Yuga Labs по блокчейну также склоняется к этой версии: злоумышленник получил «авторизованные подписи», а не приватный ключ; использование релеера могло служить именно для маскировки источника подписей.

Шэнью упомянул деталь в утреннем обзоре: до 06:55 Binance продолжала использовать тот же приватный ключ для подписи, переводя фрагментарные токены обратно на собственный кошелёк.

Это указывает, что ключ оставался под контролем Binance утром того дня.

Сейчас, в 10:26, Binance опубликовала предварительное сообщение: возможно, был скомпрометирован ноутбук инженера DevOps, через который злоумышленник получил доступ к сервисным контейнерам и инициировал несанкционированные выводы; прямых доказательств утечки приватного ключа кошелька пока нет.

Потеря произошла не в блокчейне

Следовательно, ключевая проблема — не EIP-7702, а этап перед подписью.

Горячий кошелёк подписывает тысячи транзакций в день, поэтому процесс должен быть автоматизирован; он должен быть безопасным, следовательно, требуются HSM, MPC, мультиподпись и цепочки одобрений. Всю модель безопасности можно свести к одному вопросу: «может ли система до подписи определить, что «эту транзакцию подписывать нельзя»?»

Проблема в том, что большинство критериев проверки имеют всего два параметра: сумму и адрес.

Авторизация по EIP-7702 не содержит ни того, ни другого: суммы нет, а изменяется не «сколько перевести», а «кем является этот адрес».

Речь не идёт о том, что Binance не защищалась.

За три дня до инцидента, 27 октября, компания добровольно сообщила о важном факте: за прошедшую неделю команда безопасности заблокировала несколько атак, связанных с Северной Кореей. Метод называется «Контагиозное интервью»: злоумышленники выдают себя за рекрутеров, проводят собеседования и тесты по программированию, предлагая «сначала установить инструмент разработчика» — так жертвы запускают вредоносные программы; после этого у злоумышленников появляются ключи, доступ к внутренней сети и возможность перемещать средства.

Однако система не смогла предотвратить ситуацию «должна ли эта транзакция быть подписана».