EIP-7702 không phải là nguyên nhân chính khiến Binance bị đánh cắp 6,3 tỷ USD, làm thế nào để có được chữ ký mới là vấn đề then chốt.

04:24 ngày 30 tháng 10 năm 2026, giờ Bắc Kinh.

Trong bản ghi on-chain, tiền chảy ra từ 0x28C6…1d60. Địa chỉ này tên là Binance 14, một trong những ví nóng Ethereum lớn nhất của Binance, mỗi ngày phát ra hàng nghìn lệnh rút tiền. Giao dịch này chuyển đi 167.464 ETH, 1,615 tỷ USDT, cộng thêm hơn 60 loại token, theo giá lúc đó khoảng 2,5 tỷ USD. Cuối cùng trong ví chỉ còn lại 1 ETH.

Phí giao dịch 0,0004 ETH, chưa đến 1 USD.

Ba phút trước, 04:21, có người gửi đến nó một giao dịch loại EIP-7702, bên trong nhồi 50 bản ủy quyền, nonce xếp từ 18.914.775 đến 18.914.824. 49 bản vô hiệu, 1 bản trúng. Trúng nghĩa là: từ giây phút này, mọi lệnh gọi đến Binance 14 đều thực thi hợp đồng mà kẻ tấn công đã triển khai vào 23:59 đêm hôm trước — một bộ quét chưa được xác minh, chỉ có một hàm sweep.

Thế là Binance 14 không còn là một chiếc ví nữa. Nó trở thành một cái vỏ, bên trong chứa chương trình của người khác.

Đến 08:06 bản ủy quyền vẫn còn đó. 3 giờ 45 phút, không ai thu hồi nó.

Mà việc "thu hồi" chỉ cần cùng một chiếc chìa khóa ký thêm một lần. Sáng hôm đó 06:55, Binance vẫn dùng chiếc chìa khóa này để chuyển những token lẻ chưa bị quét về ví của mình.

EIP-7702 có phải là nguyên nhân chính của cuộc tấn công

Logic của EIP-7702 là thế này: cho phép một địa chỉ thông thường (EOA) thuê mã của một hợp đồng thông minh, địa chỉ, số dư, khóa riêng đều không đổi. Cách thuê là ghi 23 byte vào trường code của địa chỉ này — 0xef0100 cộng với địa chỉ hợp đồng. 23 byte này không phải mã có thể thực thi, mà là một con trỏ. Từ đó ai gọi đến địa chỉ này, EVM sẽ đi nạp mã mà con trỏ trỏ tới, thực thi trong ngữ cảnh của chính địa chỉ này: address(this) vẫn là nó, số dư vẫn là số dư của nó.

Nó không có lỗi. Derek Chiang, nhà sáng lập ZeroDev, người tham gia EIP-7702, phát biểu thẳng thắn ngay ngày xảy ra sự việc: bản thân EIP-7702 không có lỗ hổng, người dùng ví hỗ trợ tiêu chuẩn này không cần hoảng sợ. Ông còn nói thêm, kẻ tấn công muốn dùng 7702 thì hoặc phải kiểm soát khóa riêng, hoặc phải dụ Binance ký ra một bản ủy quyền 7702.

Đây cũng không phải lần đầu tiên nó bị dùng làm công cụ tấn công. Sau bản nâng cấp Pectra của Ethereum, chỉ trong vài tuần Wintermute đã phát hiện trên mainnet có hơn 97% các ủy quyền 7702 trỏ về gần như cùng một hợp đồng "quét coin"; một nghiên cứu đã thống kê khoảng 3,66 triệu giao dịch ủy quyền, trong đó khoảng 63% liên quan đến hợp đồng độc hại, xác nhận thiệt hại 2,3 triệu USD; Blockaid trong nửa đầu năm 2026 đã xác minh bốn sự kiện 7702, tổng cộng khoảng 1,08 triệu USD, và dự đoán trong năm sẽ xuất hiện vụ án bảy chữ số đầu tiên.

Kết quả đến lại là mười chữ số, cao hơn ước tính của họ ba bậc độ lớn.

Điều này cũng dẫn đến việc nhiều người sẽ quy nguyên nhân của vụ tấn công hacker lớn nhất trong lịch sử loài người trị giá 5,6 tỷ USD của Binance lần này cho EIP-7702. Nhưng thực sự có phải là vấn đề của 7702 không?

Chữ ký đã được lấy như thế nào

Trước khi đi tiếp, phải nói rõ một điều: 50 ủy quyền thì có 50 chữ ký, vậy 50 chữ ký đó rốt cuộc được tạo ra như thế nào?

Nếu kẻ tấn công lấy được khóa riêng tư đầy đủ, tại sao hắn lại phải mù quáng nhắm 50 nonce? Nếu chìa khóa luôn nằm trong tay Binance, thì tại sao trong 12 phút có 11 ví cùng lúc bị thất thủ? Hiện tại vẫn chưa có lời giải thích.

24 giây sau khi quét chính, Binance 16 chuyển ra 28.005,6 ETH, 55,7 triệu USDT, 25,9 triệu RLUSD, 84,5 WBTC, đích đến là cùng một địa chỉ nhận.

Trong vòng 12 phút, 10 ví nóng khác của Binance đã làm điều tương tự trên bốn chuỗi: Binance 55 trên Optimism chuyển ra 44,2 triệu OP; bốn ví trên Arbitrum chuyển ra 74,6 triệu ARB và 8.426 ETH; bốn ví trên Avalanche chuyển ra 1,81 triệu AVAX và 8,41 triệu USDT.

Những ví này không có ví nào chứa mã, mỗi giao dịch đều là chuyển khoản thông thường, được ký bởi khóa riêng tư của chính ví, xen giữa các lệnh rút tiền hàng ngày.

Một người cầm trong tay khóa riêng tư không cần phải mù quáng nhắm nonce. Chỉ cần tra eth_getTransactionCount, một giây là xong.

Người cần một lần构造 50 bản, bao phủ 50 nonce liên tiếp, là một kiểu người khác: có thể lấy được chữ ký, nhưng không lấy được trạng thái thời gian thực của ví này; hoặc, chỉ có thể một lần gửi đi một loạt ủy quyền đã được ghép sẵn từ trước, để hệ thống tự thử.

Đáng chú ý hơn là 50 ủy quyền này đã được phê duyệt một lần trong cùng một giao dịch.

Đánh giá của công ty bảo mật Blockaid về việc này là "khóa bị lạm dụng", chứ không phải khóa riêng tư bị trích xuất trực tiếp. Phó chủ tịch blockchain của Yuga Labs, Quit, cũng nghiêng về hướng này: kẻ tấn công nhận được là "chữ ký được ủy quyền", không phải khóa riêng tư, việc dùng relayer để gửi có thể chính là để che giấu nguồn gốc chữ ký.

Thần Ngư trong bản tổng kết buổi sáng có nhắc đến một chi tiết: cho đến 06:55, Binance vẫn đang dùng cùng một khóa riêng tư để ký, chuyển các token vụn chưa bị quét về ví của mình.

Điều này cho thấy chiếc chìa khóa này sáng hôm đó vẫn nằm trong sự kiểm soát của Binance.

Vừa lúc 10:26, Binance đưa ra tuyên bố sơ bộ của mình: có thể một kỹ sư DevOps đã bị xâm nhập laptop, kẻ tấn công lợi dụng điều này để vào container dịch vụ, gửi các giao dịch rút tiền trái phép; hiện chưa phát hiện bằng chứng về việc rò rỉ khóa riêng tư của ví.

Giây phút thất thủ, không nằm trên chuỗi

Vậy nên cốt lõi không nằm ở EIP-7702, mà là đoạn trước khi ký.

Ví nóng ký hàng nghìn giao dịch mỗi ngày, nên buộc phải tự động hóa; nó phải an toàn, nên phải có HSM, MPC, đa chữ ký, luồng phê duyệt. Thế là toàn bộ mô hình bảo mật bị nén lại thành một câu: quy trình này, có thể phán đoán được "giao dịch này không nên ký" trước khi ký hay không.

Vấn đề là, phần lớn căn cứ phán đoán chỉ có hai cột: số tiền, địa chỉ.

Ủy quyền 7702 không có cả hai cột này. Nó không có số tiền. Thứ nó thay đổi không phải là "chuyển bao nhiêu", mà là "địa chỉ này là gì".

Binance không phải là không phòng ngừa.

Ba ngày trước sự việc, tức ngày 27 tháng 10, đã chủ động tiết lộ một điều đáng ghi nhớ: trong tuần qua, đội ngũ bảo mật đã chặn được nhiều vụ tấn công liên quan đến Triều Tiên. Thủ đoạn gọi là Contagious Interview — đối phương giả danh nhà tuyển dụng, dùng phỏng vấn, kiểm tra mã, "cài công cụ phát triển trước đã" để lừa người ta chạy chương trình độc hại; một khi chương trình chạy, khóa, mạng nội bộ, và việc vận chuyển tiền sau đó đều có cửa vào.

Nhưng đã không phòng ngừa được "giao dịch này, có nên ký hay không".

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia