Bạn chưa từng mua rsETH nhưng WETH của bạn đã bị đông cứng

Giới thiệu

Điểm chính:

• Trong khoảng thời gian từ ngày 13 đến 19 tháng 4 năm 2026, đã phát hiện bốn vụ tấn công liên quan đến nhiều chuỗi như Ethereum, Unichain, Arbitrum và NEAR, tổng thiệt hại ước tính khoảng 310 triệu đô la.
• Các phương thức tấn công bao gồm nhiễu RPC hạ tầng cho LayerZero DVN, giả mạo chứng minh MMR, lạm dụng số nguyên có dấu trong quỹ bảo hiểm, và khai thác vòng lặp trong giao thức giao dịch ký quỹ.
• Sự kiện KelpDAO (290 triệu đô la) cho thấy an toàn của cầu liên chuỗi đã vượt ra ngoài hợp đồng thông minh, mở rộng đến hạ tầng xác thực ngoài chuỗi. Việc WETH bị đóng băng liên tiếp trên năm chuỗi và việc chuyển đổi trạng thái bắt buộc của Arbitrum còn cho thấy khả năng phối hợp có thể làm tăng phạm vi điểm yếu đơn điểm, cũng như giới hạn thực sự của hệ thống “phi tập trung”.

Trong tuần qua (13/04/2026 - 19/04/2026), BlockSec đã phát hiện và phân tích bốn vụ tấn công, tổng thiệt hại ước tính khoảng 310 triệu đô la. Bảng dưới tóm tắt các vụ việc này, phần sau sẽ phân tích chi tiết từng vụ.

Bảng 1: Tổng quan về bốn vụ tấn công phát hiện trong tuần

Điểm nổi bật tuần này: KelpDAO

Sự kiện này được chọn làm điểm nổi bật của tuần vì các phương thức tấn công mới về hạ tầng (tấn công nhiễu RPC duy nhất cho DVN, thay vì khai thác lỗ hổng hợp đồng thông minh), ảnh hưởng chuỗi liên kết do khả năng phối hợp DeFi, và vấn đề quản trị phát sinh khi Arbitrum thực thi trạng thái bắt buộc để thu hồi tiền bị đánh cắp.

Vào ngày 18 tháng 4 năm 2026, cầu liên chuỗi rsETH LayerZero OFT của KelpDAO bị tấn công, thiệt hại khoảng 290 triệu đô la. LayerZero Labs quy nguyên nhân vụ tấn công này cho các tác nhân được nhà nước hậu thuẫn, có thể là nhóm Lazarus của Triều Tiên [1]. Nguyên nhân cốt lõi là cấu hình DVN 1-đến-1 của KelpDAO, khiến xác thực tin nhắn liên chuỗi bị giảm xuống còn điểm yếu đơn điểm. Kẻ tấn công đã nhiễu RPC tin cậy của LayerZero Labs, buộc họ phải ký chứng minh tin nhắn giả mạo để xác nhận một tin nhắn liên chuỗi giả mạo, dẫn đến 116.500 rsETH bị giải phóng trên Ethereum, trong khi trên chuỗi nguồn Unichain không có sự kiện gửi tương ứng.

Bối cảnh

LayerZero là một giao thức nhắn tin liên chuỗi dựa trên kiến trúc an toàn mô-đun. Tính toàn vẹn của tin nhắn liên chuỗi được đảm bảo bởi mạng xác thực phi tập trung (DVN), là các thực thể ngoài chuỗi chịu trách nhiệm xác thực độc lập các tin nhắn gửi từ chuỗi nguồn, chỉ cho phép thực thi trên chuỗi đích sau khi xác nhận thành công. Mỗi ứng dụng triển khai trên LayerZero tự cấu hình DVN, bao gồm các thiết lập như tin tưởng vào những DVN nào, số lượng DVN tham gia, và ngưỡng đồng thuận.

Kiến trúc mô-đun này cho phép ứng dụng kiểm soát hoàn toàn mô hình an ninh, nhưng cũng đặt trách nhiệm hoàn toàn vào tay chúng: cấu hình yếu sẽ không được bảo vệ bởi chính giao thức.

Trong trường hợp của KelpDAO, rsETH được triển khai như một OFT (Token có thể thay thế toàn chuỗi) trên LayerZero, cầu kết nối Unichain (chuỗi nguồn) và Ethereum Mainnet (chuỗi đích). Chuẩn OFT cho phép token bị tiêu hủy trên chuỗi nguồn và được phát hành từ khóa trong chuỗi đích, dựa trên tin nhắn liên chuỗi được phép phát hành duy nhất. Ở phía Ethereum, bộ chuyển đổi (0x85d456…e98ef3) chịu trách nhiệm phát hành rsETH sau khi tin nhắn liên chuỗi được xác thực và truyền đi.

Vấn đề then chốt là, KelpDAO cấu hình đường dẫn này thành cấu hình DVN 1-đến-1, chỉ định LayerZero Labs là duy nhất xác thực. Điều này có nghĩa là chỉ cần một chứng minh từ DVN duy nhất là đủ để cấp phép phát hành token, không cần xác nhận từ bên thứ hai.

Để thực thi nhiệm vụ xác thực, DVN của LayerZero Labs sẽ truy vấn nhiều nút RPC, xác nhận rằng sự kiện gửi liên chuỗi thực sự đã xảy ra trên chuỗi nguồn. Các nút RPC này gồm hạ tầng tự vận hành và nhà cung cấp bên thứ ba, dựa vào phản hồi tập thể của chúng để ký chứng minh. Tính toàn vẹn của quá trình này dựa trên giả định rằng đa số các nút được truy vấn trả về dữ liệu chính xác.

Phân tích lỗ hổng

Lỗ hổng này là thất bại hệ thống mang tính hệ thống của hạ tầng và cấu hình, gồm ba điểm yếu chồng chất:

1. Cấu hình DVN 1-đến-1 của KelpDAO loại bỏ tất cả các lớp dự phòng xác thực. Các khuyến nghị của LayerZero yêu cầu cấu hình nhiều DVN và sử dụng các xác thực viên độc lập để đảm bảo không một DVN đơn lẻ nào có thể tự ý cấp phép một tin nhắn. Việc chỉ dựa vào DVN của LayerZero Labs khiến bất kỳ kẻ tấn công nào phá vỡ được DVN này đều có thể cấp phép phát hành token tùy ý.

2. Cơ chế chuyển đổi lỗi của DVN cho phép định tuyến truy vấn xác thực tới bất kỳ nút RPC nào có thể truy cập được. Thiết kế này giả định rằng các nút không khả dụng là do sự cố chứ không phải cố ý. Tuy nhiên, điều này tạo điều kiện cho kẻ tấn công không cần phá vỡ tất cả các nguồn dữ liệu: bằng cách tấn công từ chối dịch vụ (DDoS) làm các nút khỏe mạnh bị tắt, và chuẩn bị các nút bị nhiễm độc làm điểm đến duy nhất, kẻ tấn công có thể kiểm soát hoàn toàn dữ liệu DVN nhận được.

3. Việc thay thế tệp thực thi op-geth trên các nút RPC đòi hỏi quyền truy cập OS của máy chủ nền tảng. Các vector truy cập ban đầu chính xác chưa được tiết lộ, nhưng việc tấn công hai nút nằm trong các cụm độc lập cho thấy có thể có điểm yếu chung trong kiểm soát truy cập của các máy chủ này.

Ba điểm yếu này tạo thành chuỗi tấn công hoàn chỉnh: điểm thứ nhất đảm bảo không DVN nào có thể xác thực tin nhắn một cách độc lập, điểm thứ hai đảm bảo kẻ tấn công có thể kiểm soát hoàn toàn dữ liệu nhận được bởi DVN duy nhất, và điểm thứ ba cung cấp điểm khởi đầu để thao túng dữ liệu. Không có điểm yếu nào đơn lẻ đủ để thành công. Nếu không cấu hình 1-đến-1, DVN thứ hai sẽ từ chối các tin nhắn giả mạo. Nếu không có chuyển đổi lỗi, các nút khỏe mạnh sẽ phủ nhận các phản hồi bị nhiễm độc. Nếu không tấn công máy chủ, kẻ tấn công không thể chèn dữ liệu giả.

Phân tích tấn công

Dưới đây dựa trên giao dịch 0x1ae232…4222 và tuyên bố chính thức của LayerZero Labs.

Bước 1: Kẻ tấn công lấy danh sách các nút RPC được LayerZero Labs tin cậy. Danh sách này là mục tiêu tình báo giá trị cao vì biết chính xác các nút giúp kẻ tấn công lên kế hoạch chính xác, không chỉ tấn công hạ tầng chung chung.

Bước 2: Kẻ tấn công có quyền ghi OS của hai nút RPC, thay thế tệp binary op-geth đang chạy bằng phiên bản độc hại. Hai nút này được mô tả là chạy trong các cụm độc lập không liên kết, cho thấy vector truy cập ban đầu có thể liên quan đến các phụ thuộc chung như chứng chỉ triển khai bị rò rỉ, pipeline CI/CD, hoặc tấn công xã hội vào nhân viên vận hành có quyền truy cập đồng thời. LayerZero Labs chưa tiết lộ cách truy cập ban đầu chính xác. Bước này là tiền đề cho các thao tác thao túng dữ liệu sau đó.

Bước 3: Binary độc hại này thực thi logic phản hồi có hướng: chỉ trả dữ liệu giao dịch giả mạo cho IP của DVN, trong khi cung cấp trạng thái blockchain thực cho các yêu cầu khác, bao gồm hạ tầng giám sát của LayerZero, trình duyệt blockchain, dịch vụ quét. Việc này giúp thao túng dữ liệu không bị phát hiện qua các hệ thống quan sát hiện có; từ góc nhìn bên ngoài, chuỗi nguồn vẫn hoạt động bình thường.

Bước 4: Các xác thực nội bộ của DVN yêu cầu các nút bị nhiễm độc và chưa bị tấn công đạt được đồng thuận. Để giải quyết mâu thuẫn này, kẻ tấn công thực hiện tấn công từ chối dịch vụ (DDoS) vào các nút còn lại trong khung thời gian (10:20-11:40 giờ Thái Bình Dương), kích hoạt cơ chế chuyển đổi lỗi của DVN, khiến nó hoàn toàn dựa vào hạ tầng bị nhiễm độc. Bước này là bắt buộc vì nếu không, các nút khỏe mạnh sẽ trả về dữ liệu đúng mâu thuẫn với phản hồi giả mạo.

Bước 5: Khi DVN chỉ còn nhận dữ liệu do kẻ tấn công kiểm soát, một tin nhắn liên chuỗi giả mạo của LayerZero được trình bày là hợp lệ. DVN chứng minh nonce 308 trên Ethereum, trong khi trên Unichain không có sự kiện gửi đi tương ứng (nonce tối đa trên nguồn vẫn là 307).

Bước 6: Bộ chuyển đổi rsETH trên Ethereum nhận tin nhắn đã chứng minh hợp lệ, phát hành 116.500 rsETH tới địa chỉ nhận của kẻ tấn công (0x8b1b6c…0d3b), đã được nạp tiền qua Tornado Cash vài giờ trước đó. Token bị đánh cắp sau đó phân tán qua bảy ví con, qua các vị thế thế chấp Aave, đổi trực tiếp sang ETH, và chuyển liên chuỗi sang Arbitrum để thanh lý, cuối cùng tập trung về các địa chỉ trên Ethereum (0x5d3919…7ccc) và Arbitrum.

Bước 7: Binary độc hại sau khi thực thi tự hủy, xóa tất cả nhật ký và cấu hình cục bộ, gây khó khăn cho việc điều tra sau này, thể hiện độ chín trong thao tác của kẻ tấn công.

Bước 8: Kẻ tấn công cố gắng tấn công lần nữa qua cùng đường dẫn để lấy thêm 40.000 rsETH (~95 triệu đô la), nhưng bị phát hiện và tạm dừng tất cả hợp đồng liên quan trên Ethereum và các Layer2 khác. [2]

Ảnh hưởng rộng hơn của ###

Tác hại không chỉ dừng lại ở lỗ hổng cầu liên chuỗi ban đầu. Kẻ tấn công đã gửi khoảng 89.567 rsETH (~221 triệu đô la) vào các thị trường Aave, cho vay WETH với tỷ lệ LTV 93%. Do Aave không phân biệt rõ ràng giữa rsETH hợp lệ và token phát hành giả mạo, các tài sản “độc hại” này được coi là hợp lệ hoàn toàn. Việc này dẫn đến đóng băng dự trữ WETH từ Ethereum sang Arbitrum, Base, Mantle và Linea, ảnh hưởng đến người dùng chưa từng tiếp xúc với rsETH. Chuỗi truyền tải này từ cấu hình cầu liên chuỗi thiếu sót đến gián đoạn thị trường cho vay đa chuỗi cho thấy khả năng phối hợp của DeFi có thể làm tăng phạm vi và chi phí của điểm yếu đơn điểm.

Sự kiện còn làm dấy lên vấn đề về thực tế vận hành phi tập trung. LayerZero Labs tuyên bố rằng DVN của họ sẽ không còn ký các ứng dụng cấu hình 1-đến-1, nghĩa là chỉ dựa vào phân quyền ở cấp giao thức không thể bù đắp cho cấu hình yếu ở cấp ứng dụng.

Trên chuỗi, Hội đồng An ninh Arbitrum thực hiện thao tác khẩn cấp, đóng băng 30.766 ETH của kẻ tấn công trên Arbitrum One. Theo phân tích của BlockSec, đây là một hành động chuyển đổi trạng thái bắt buộc trên chuỗi: Hội đồng tạm thời nâng cấp hợp đồng inbox của Ethereum, chèn một tin nhắn L1 không ký của kẻ tấn công, rồi khôi phục hợp đồng ban đầu, tất cả đều không cần chữ ký của chủ sở hữu $290M .

Hành động này là việc thực thi hợp pháp các quyền khẩn cấp theo khung quản trị, được thực hiện minh bạch sau khi phối hợp với cơ quan pháp luật. Tuy nhiên, nó cũng cho thấy rằng các chuỗi Layer2 có khả năng can thiệp trung ương trong các tình huống khẩn cấp: về nguyên tắc, tất cả tài sản trên Arbitrum One đều có thể bị Hội đồng di chuyển theo cơ chế này. Như mọi sự kiện trong từng lớp đã tiết lộ, mô hình tin cậy lý thuyết của hệ thống và giới hạn tin cậy thực tế của nó là điểm rủi ro then chốt.

Kết luận

Sự kiện này cho thấy an toàn của cầu liên chuỗi không thể chỉ dựa vào tính đúng đắn của giao thức. Giao thức LayerZero hoạt động theo thiết kế; lỗ hổng nằm hoàn toàn ở tầng vận hành phía trên. Bài học chính là hạ tầng xác thực ngoài chuỗi là một phần của giới hạn tin cậy, và trạng thái an toàn của nó phải phù hợp với giá trị mà nó bảo vệ.

Ba biện pháp giảm thiểu sau đây có thể đơn lẻ ngăn chặn sự kiện này:

• Cấu hình nhiều DVN: yêu cầu nhiều DVN độc lập đạt đồng thuận, làm cho một DVN bị tấn công không đủ để cấp phép một tin nhắn, dù DVN đó bị lừa đảo đến mức nào.
• Lựa chọn RPC có khả năng phát hiện lỗi: khi các nút xác thực hoạt động trong khung thời gian, giảm đột ngột, cần được xem là tín hiệu cảnh báo tấn công chứ không chỉ là vấn đề khả dụng. Các hệ thống DVN nên tạm dừng hoặc cảnh báo khi số lượng nút giảm, thay vì tiếp tục hoạt động dựa trên số còn lại.
• Củng cố hạ tầng RPC: khả năng thay thế tệp thực thi của các nút RPC trong môi trường sản xuất cho thấy kiểm soát truy cập của máy chủ nền tảng còn yếu. Các hạ tầng này, dùng để lấy trạng thái thực của chuỗi nguồn, cần có mức độ bảo mật tương đương với các chứng thực của DVN.

Nhìn rộng hơn, bất kỳ cầu liên chuỗi hoặc giao thức nào dựa vào chứng minh ngoài chuỗi cũng cần được kiểm tra không chỉ ở lớp hợp đồng thông minh, mà còn toàn bộ chuỗi dữ liệu từ sự kiện nguồn đến thực thi đích. Khi hàng trăm triệu đô la phụ thuộc vào hạ tầng RPC, giả định tin cậy vào độ tin cậy của chúng đã không còn hợp lý.

Tài liệu tham khảo:

[4] LayerZero Labs, “Tuyên bố về sự cố KelpDAO”, ngày 20/04/2026. https://x.com/LayerZero_Core/status/2046081551574983137

[1] KelpDAO, “Bối cảnh thêm về sự cố ngày 18/04”, ngày 21/04/2026. https://x.com/KelpDAO/status/2046332070277091807

[5] Arbitrum, “Hành động khẩn cấp của Hội đồng An ninh”, ngày 21/04/2026. https://x.com/arbitrum/status/2046435443680346189

[3] LlamaRisk, “Báo cáo sự cố rsETH”, ngày 20/04/2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[1] BlockSec, “Phân tích cơ chế đóng băng của Hội đồng An ninh Arbitrum”, ngày 21/04/2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Các sự kiện khác trong tuần

Hyperbridge

Ngày 13/04/2026, Hyperbridge, một cầu liên chuỗi dựa trên Ethereum, bị tấn công do thiếu kiểm tra đầu vào trong logic chứng minh MMR, thiệt hại khoảng 242.000 đô la. Hàm MerkleMountainRange.VerifyProof[2][3] không bắt buộc kiểm tra leaf_index < leafCount, cho phép kẻ tấn công giả mạo chứng minh liên chuỗi và thực thi các thao tác đặc quyền, bao gồm đúc 1 tỷ DOT.

[4] Bối cảnh

Hyperbridge sử dụng mô hình trình xác thực và bộ điều phối trên Ethereum để xử lý tin nhắn liên chuỗi. Trên Ethereum, hợp đồng HandlerV1 dựa trên overlayRoot để xác minh chứng minh, nếu hợp lệ, sẽ phân phối tin nhắn đến các module đích như TokenGateway.

TokenGateway là một module quản lý tài sản đặc quyền, ngoài chức năng cầu nối tài sản thông thường còn hỗ trợ các thao tác quản trị như tạo, hủy bỏ tài sản, quản trị viên. Đối với tài sản cầu nối theo chuẩn ERC6160Ext20, quản trị viên có thể chuyển quyền đúc qua hàm changeAdmin[5](, sau đó quản trị viên mới có thể đúc token theo hàm mint)###.

Điều này có nghĩa là, an toàn của toàn bộ cầu nối phụ thuộc vào quá trình xác minh chứng minh trong HandlerV1. Nếu chứng minh giả mạo được chấp nhận, các module phía dưới sẽ coi lệnh của kẻ tấn công là hợp lệ.

( Phân tích lỗ hổng

Vấn đề chính nằm trong quá trình xác minh chứng minh của HandlerV1 (0x6c84ed…6d64). Hàm handlePostRequests)( xây dựng leaf của MMR từ dữ liệu đầu vào của tấn công, rồi gọi VerifyProof)### để xác minh.

Tuy nhiên, VerifyProof( chỉ kiểm tra rằng root == CalculateRoot), leaves, mmrSize, mà không kiểm tra leaf.index có hợp lệ hay không (ví dụ, leaf.index < leafCount).

Bằng cách chọn leafCount = 1 và leaf_index = 1, kẻ tấn công khiến hàm CalculateRoot() bỏ qua việc xác thực các leaf giả mạo, dẫn đến kết quả xác minh hợp lệ trong khi thực tế không có trong cây Merkle. Điều này phá vỡ liên kết giữa tin nhắn và chứng minh, cho phép tải trọng giả mạo vượt qua xác thực dựa trên root cũ.

Hình: Mã đoạn VerifyProof thiếu kiểm tra leaf_index trong biên giới

( Phân tích tấn công

Dựa trên giao dịch 0x240aeb…1109 ), các bước như sau:

Bước 1: Kẻ tấn công EOA 0xC513…F8E7 triển khai hai hợp đồng phụ 0x518A…8f26 và 0x31a1…ca9AB trong cùng một giao dịch.

Bước 2: Hợp đồng phụ 0x31a1…ca9AB gửi yêu cầu giả mạo qua HandlerV1, do VerifyProof() không từ chối leaf vượt quá leafCount, yêu cầu giả mạo này bị bỏ qua trong tính toán root, nhưng vẫn phù hợp với root lịch sử.

Bước 3: Tin nhắn giả mạo được chấp nhận, HandlerV1 gửi đến TokenGateway, thực hiện thao tác ChangeAssetAdmin, chuyển quyền đúc DOT sang hợp đồng phụ 0x31a1…ca9AB.

Bước 4: Hợp đồng phụ đúc 1 tỷ DOT.

Bước 5: Hợp đồng phụ đổi số DOT mới đúc thành ETH qua Odos Router V3.

Bước 6: Kẻ tấn công chuyển ETH ra khỏi hợp đồng phụ về tài khoản EOA của mình.

( Kết luận

Sự kiện này do logic xác minh chứng minh của Hyperbridge trong hàm verify_token_out)( không kiểm tra biên giới leaf_index. Do đó, kẻ tấn công có thể tạo ra một yêu cầu giả mạo không thực sự có trong cây Merkle, nhưng vẫn vượt qua xác minh dựa trên root cũ, dẫn đến việc hợp đồng chấp nhận yêu cầu này và thực thi các thao tác trái phép.

Các biện pháp giảm thiểu bao gồm:

• Trong quá trình xác minh chứng minh, bắt buộc kiểm tra leaf_index < leafCount để loại bỏ các yêu cầu giả mạo vượt quá biên giới.
• Đặt giới hạn rõ ràng về số lượng và nội dung các bước trong chuỗi đổi chỗ, tránh cho phép vòng lặp hoặc các đường đi vòng trong quá trình xác minh.
• Sử dụng các giá trị dựa trên dữ liệu từ oracle hoặc các nguồn bên ngoài để xác định giới hạn hợp lý cho các yêu cầu, tránh bị thao túng bằng dữ liệu giả mạo.