Khoảng 200.000 XRP đã bị rút khỏi Coreum Bridge trong vòng 97 phút do lỗ hổng trong cơ chế xác thực tiền nạp của chính bridge, không phải do lỗi của XRP Ledger (XRPL). Kẻ tấn công đã lợi dụng quy trình kiểm tra lỏng lẻo để tạo ra các giao dịch trông như hợp lệ dù không có tiền nạp thực, qua đó khiến bridge chi trả XRP thật.
Theo U.Today ngày 11/8 (giờ địa phương), vụ tấn công diễn ra trong khoảng 97 phút và khiến Coreum Bridge thất thoát khoảng 200.000 XRP.
Sau sự cố, trên mạng xã hội xuất hiện suy đoán cho rằng tính năng “Rippling” của XRPL đã bị lợi dụng. Tuy nhiên, kết quả phân tích từ xrpl.to, một trang chuyên theo dõi hệ sinh thái XRPL, cho thấy nguyên nhân thực sự nằm ở khâu xác minh giao dịch nạp của bridge.
Về mặt kỹ thuật, XRP gốc không có issuer hay Trust Line nên không thể bị khai thác theo cơ chế Rippling. Giao dịch rút tiền trong vụ việc này cũng không sử dụng bất kỳ chức năng bất thường nào của XRPL, mà vẫn được bridge phê duyệt thông qua quy trình ký multi-sig thông thường.
Coreum Bridge vận hành theo mô hình yêu cầu đủ 17 chữ ký trên tổng số 28 khóa relayer để phê duyệt giao dịch. Theo phân tích, kẻ tấn công không đánh cắp khóa nào mà nhắm vào điểm yếu trong quy trình xác minh: relayer không kiểm tra đầy đủ xem tài sản có thực sự được nạp vào bridge hay không.
Cách thức tấn công bắt đầu bằng việc chuyển token Wrapped-Core do bridge phát hành giữa các ví do chính kẻ tấn công kiểm soát. Trong quá trình này, chúng chèn thông tin chuyển token trên Coreum vào phần memo của giao dịch. Nếu chỉ nhìn dữ liệu on-chain, giao dịch này rất dễ bị hiểu nhầm là một khoản nạp hợp lệ liên quan đến hoạt động wrapping của bridge.
Lỗ hổng nằm ở cách relayer xác minh giao dịch. Các relayer có kiểm tra việc giao dịch đã diễn ra và nội dung trong trường memo, nhưng lại không đối chiếu địa chỉ nhận có đúng là ví nạp của bridge hay không. Nói cách khác, hệ thống chỉ xác nhận rằng có token được gửi đi, chứ không xác nhận số token đó đã thực sự vào bridge.
Phân tích của xrpl.to cho thấy ngay trong mã relayer đã thiếu bước kiểm tra dòng tiền thực có đi vào ví của bridge hay không. Tận dụng điểm yếu này, kẻ tấn công khiến hệ thống công nhận một khoản nạp không tồn tại là hợp lệ, từ đó nhận số dư tương ứng trên mạng Coreum dù chưa từng nạp tài sản thật.
Sau đó, khi thực hiện yêu cầu rút tiền theo quy trình bình thường, giao dịch tiếp tục được relayer đánh giá là hợp lệ. Khi đủ ngưỡng 17 chữ ký, khoảng 200.000 XRP đã được chuyển từ ví XRPL của bridge sang địa chỉ do kẻ tấn công kiểm soát.
Theo đánh giá của xrpl.to, đây là trường hợp bridge gần như chấp nhận dữ liệu giao dịch mà không kiểm chứng đầy đủ. XRPL không trực tiếp cấp tiền cho kẻ tấn công; chính hệ thống xác thực của bridge đã tin vào khoản nạp giả và chi trả XRP thật.
Sự cố được cho là sẽ làm gia tăng sức ép lên năng lực quản trị an ninh của TX, đơn vị vận hành bridge. Nhóm này trước đây phát triển Sologenic trên nền XRPL, sau đó ra mắt blockchain layer-1 Coreum và đến tháng 3/2026 đã hợp nhất hai hệ sinh thái dưới thương hiệu TX tại Mỹ.
TX hiện mở rộng hoạt động blockchain cho khách hàng tổ chức, với trọng tâm là tài sản gắn với thế giới thực (RWA). Tuy nhiên, việc thiếu một bước xác minh cơ bản đối với tiền nạp cross-chain có thể làm dấy lên thêm chỉ trích về quy trình kiểm thử và kiểm soát chất lượng bảo mật.
Đến nay, TX vẫn chưa công bố báo cáo phân tích sự cố chính thức. Coreum Bridge cũng đã tạm dừng hoàn toàn, khiến tranh luận không còn dừng ở phạm vi lỗi mã nguồn mà mở rộng sang quy trình phát triển và cơ chế rà soát bảo mật.
Danh tính kẻ tấn công hiện chưa được xác định. Dù vậy, dữ liệu on-chain cho thấy số XRP bị đánh cắp đã nhanh chóng được chuyển qua nhiều ví trung gian, cho thấy dấu hiệu che giấu dòng tiền. Theo phân tích, các ví này được tạo ra khoảng một tháng rưỡi trước thời điểm vụ tấn công xảy ra.
Thị trường hiện chờ báo cáo chính thức từ TX trong thời gian tới. Các vấn đề được quan tâm gồm lỗ hổng xác thực của bridge đã bị khai thác ra sao, liệu có thể chặn các đợt dịch chuyển tiếp theo của số XRP bị đánh cắp hay không, và khi nào dịch vụ bridge có thể hoạt động trở lại sau khi hoàn tất vá lỗi bảo mật.